Condividi tramite

Come aggiornare cluster Big Data di SQL Server

  • Articolo

Si applica a: SQL Server 2019 (15.x)

Importante

Il componente aggiuntivo per i cluster Big Data di Microsoft SQL Server 2019 verrà ritirato. Il supporto per i cluster Big Data di SQL Server 2019 terminerà il 28 febbraio 2025. Tutti gli utenti esistenti di SQL Server 2019 con Software Assurance saranno completamente supportati nella piattaforma e fino a quel momento il software continuerà a ricevere aggiornamenti cumulativi di SQL Server. Per altre informazioni, vedere il post di blog relativo all'annuncio e Opzioni per i Big Data nella piattaforma Microsoft SQL Server.

Il percorso di aggiornamento dipende dalla versione corrente del cluster Big Data di SQL Server. L'aggiornamento da una versione supportata, tra cui l'aggiornamento pubblico (GDR), l'aggiornamento cumulativo (CU) o l'aggiornamento QFE (Quick Fix Engineering), può essere eseguito sul posto. L'aggiornamento sul posto da una versione CTP (Community Technology Preview) o dalla versione finale candidata del cluster Big Data non è supportato. È necessario rimuovere e ricreare il cluster. Le sezioni seguenti descrivono i passaggi per ogni scenario:

Nota

La versione meno recente attualmente supportata dei cluster Big Data è SQL Server 2019 CU8.

Note sulla versione dell'aggiornamento

Prima di procedere, consultare le note sulla versione dell'aggiornamento per verificare la presenza di problemi noti.

Avviso

Il parametro imagePullPolicy deve essere impostato come "Always" nel file control.json del profilo di distribuzione durante la distribuzione iniziale del cluster. Questo parametro non può essere modificato dopo la distribuzione. Nel caso in cui sia impostato con un valore diverso, il processo di aggiornamento potrebbe restituire risultati imprevisti che richiedono una ridistribuzione del cluster.

Aggiornamento dalla versione supportata

In questa sezione viene illustrato come aggiornare BDC per SQL Server da una versione supportata (a partire da SQL Server 2019 GDR1) a una versione supportata più recente.

  1. Verificare che non vi siano sessioni attive di Livy.

    Assicurarsi che non siano in esecuzione sessioni attive di Livy o processi batch in Azure Data Studio. Un modo semplice per effettuare questa verifica è usare il comando curl o un browser per richiedere questi URL:

    • <your-gateway-endpoint>/gateway/default/livy/v1/sessions
    • <your-gateway-endpoint>/gateway/default/livy/v1/batches

  2. Eseguire un backup dell'istanza master di SQL Server.

  3. Eseguire un backup di HDFS.

    azdata bdc hdfs cp --from-path <path> --to-path <path>

    Ad esempio:

    azdata bdc hdfs cp --from-path hdfs://user/hive/warehouse/%%D --to-path ./%%D

  4. Aggiornare l'interfaccia della riga di comando Azure Data (azdata).

    Seguire le istruzioni per l'installazione dell'interfaccia della riga di comando Azure Data (azdata).

    Nota

    Se l'interfaccia della riga di comando Azure Data (azdata) è stata installata con pip, è necessario rimuoverla manualmente prima di eseguire l'installazione con Windows Installer o la gestione pacchetti di Linux.

  5. Aggiornare il cluster Big Data.

    azdata bdc upgrade -n <clusterName> -t <imageTag> -r <containerRegistry>/<containerRepository>

    Ad esempio, lo script seguente il tag immagine 2019-CU19-ubuntu-20.04:

    azdata bdc upgrade -n bdc -t 2019-CU19-ubuntu-20.04 -r mcr.microsoft.com/mssql/bdc

Nota

I tag immagine più recenti sono disponibili nelle note sulla versione dei cluster Big Data di SQL Server 2019.

Importante

Se si usa un repository privato per eseguire preventivamente il pull delle immagini per la distribuzione o l'aggiornamento dei cluster Big Data, verificare che le immagini di compilazione correnti e le >immagini di compilazione di destinazione si trovino nel repository privato. Questo consente di ripristinare correttamente lo stato precedente, se necessario. Inoltre, se dopo la distribuzione originale sono state modificate le >credenziali del repository privato, aggiornare le variabili di ambiente DOCKER_PASSWORD e >DOCKER_USERNAME corrispondenti. L'aggiornamento con diversi repository privati per le compilazioni correnti e di destinazione non è supportato.

Aumentare il timeout per l'aggiornamento

È possibile che si verifichi un timeout se alcuni componenti non vengono aggiornati nel tempo allocato. Il codice seguente illustra il possibile aspetto dell'errore:

>azdata.EXE bdc upgrade --name <mssql-cluster>
Upgrading cluster to version 15.0.4003

NOTE: Cluster upgrade can take a significant amount of time depending on
configuration, network speed, and the number of nodes in the cluster.

Upgrading Control Plane.
Control plane upgrade failed. Failed to upgrade controller.

Per aumentare i timeout per un aggiornamento, usare i parametri --controller-timeout e --component-timeout per specificare valori più elevati quando si esegue l'aggiornamento. Questa opzione è disponibile solo a partire da SQL Server 2019 CU2. Ad esempio:

azdata bdc upgrade -t 2019-CU19-ubuntu-20.04 --controller-timeout=40 --component-timeout=40 --stability-threshold=3

--controller-timeout indica il numero di minuti di attesa del completamento dell'aggiornamento del controller o del database del controller. --component-timeout definisce la quantità di tempo disponibile per il completamento di ogni fase successiva dell'aggiornamento.

Per aumentare i timeout per un aggiornamento prima della versione SQL Server 2019 CU19, modificare il mapping di configurazione dell'aggiornamento. Per modificare la mappa di configurazione dell'aggiornamento:

Esegui questo comando:

kubectl edit configmap controller-upgrade-configmap

Modificare i campi seguenti:

controllerUpgradeTimeoutInMinutes Indica il numero di minuti di attesa del completamento dell'aggiornamento del controller o del database del controller. Il valore predefinito è 5. Per l'aggiornamento impostare almeno il valore 20. totalUpgradeTimeoutInMinutes: definisce la combinazione del tempo impiegato dal controller e il tempo impiegato dal database del controller per completare l'aggiornamento (aggiornamento controller + database del controller). Il valore predefinito è 10. Per l'aggiornamento impostare almeno il valore 40. componentUpgradeTimeoutInMinutes: definisce la quantità di tempo disponibile per il completamento di ogni fase successiva dell'aggiornamento. L'impostazione predefinita è 30. Per l'aggiornamento impostare su 45.

Salvare e uscire.

Aggiornamento di una distribuzione BDC da una versione CTP o una versione finale candidata

L'aggiornamento sul posto da una compilazione CTP o di una versione finale candidata dei cluster Big Data di SQL Server non è supportato. Nella sezione seguente viene illustrato come rimuovere manualmente il cluster e ricrearlo.

Eseguire il backup del cluster ed eliminarlo

Non è disponibile alcun aggiornamento sul posto per i cluster Big Data distribuiti prima del rilascio di SQL Server 2019 GDR1. L'unico modo per eseguire l'aggiornamento a una nuova versione è rimuovere manualmente il cluster e ricrearlo. In ogni versione è presente una versione univoca dell'interfaccia della riga di comando Azure Data (azdata) che non è compatibile con la versione precedente. Inoltre, se un'immagine del contenitore più recente viene scaricata in un cluster distribuito con un'altra versione precedente, l'immagine più recente potrebbe non essere compatibile con quelle meno recenti nel cluster. Il pull dell'immagine più recente viene eseguito se si usa il tag di immagine latest nel file di configurazione della distribuzione per le impostazioni del contenitore. Per impostazione predefinita, ogni versione include un tag di immagine specifico corrispondente alla versione di SQL Server. Per eseguire l'aggiornamento alla versione più recente, seguire questa procedura:

  1. Prima di eliminare il cluster precedente, eseguire il backup dei dati nell'istanza master di SQL Server e in HDFS. Per l'istanza master di SQL Server è possibile usare Backup e ripristino di SQL Server. Per HDFS, è possibile copiare i dati con curl.

  2. Eliminare il cluster precedente con il comando azdata delete cluster.

     azdata bdc delete --name <old-cluster-name>

    Importante

    Usare la versione dell'interfaccia della riga di comando Azure Data (azdata) corrispondente al cluster in uso. Non eliminare un cluster meno recente con la versione più aggiornata dell'interfaccia della riga di comando Azure Data (azdata).

    Nota

    L'invio di un comando azdata bdc delete comporterà l'eliminazione di tutti gli oggetti creati all'interno dello spazio dei nomi identificato con il nome del cluster Big Data, ma non lo spazio dei nomi stesso. È possibile riutilizzare lo spazio dei nomi per le distribuzioni successive, purché sia vuoto e non siano state create altre applicazioni al suo interno.

  3. Disinstallare la versione precedente dell'interfaccia della riga di comando Azure Data (azdata).

    pip3 uninstall -r https://azdatacli.blob.core.windows.net/python/azdata/2019-rc1/requirements.txt

  4. Installare la versione più recente dell'interfaccia della riga di comando Azure Data (azdata). I comandi seguenti installano l'interfaccia della riga di comando Azure Data (azdata) dalla versione più recente:

    Windows:

    pip3 install -r https://aka.ms/azdata

    Linux:

    pip3 install -r https://aka.ms/azdata --user

    Importante

    Il percorso della versione n-1 dell'interfaccia della riga di comando Azure Data (azdata) cambia per ogni versione. Anche se l'interfaccia della riga di comando Azure Data (azdata) è già stata installata in precedenza, è necessario reinstallarla dal percorso più recente prima di creare il nuovo cluster.

Verificare la versione di azdata

Prima di distribuire un nuovo cluster Big Data, assicurarsi di usare la versione più recente dell'interfaccia della riga di comando Azure Data (azdata) con il parametro --version:

azdata --version

Installare la nuova versione

Dopo aver rimosso il cluster Big Data precedente e aver installato la versione più recente dell'interfaccia della riga di comando Azure Data (azdata), distribuire il nuovo cluster Big Data usando le istruzioni di distribuzione correnti. Per altre informazioni, vedere Come distribuire cluster Big Data di SQL Server in Kubernetes. Ripristinare quindi gli eventuali file o database necessari.

Passaggi successivi

Per altre informazioni sui cluster Big Data, vedere Informazioni sui cluster Big Data di SQL Server.