Come aggiornare i cluster Big Data di SQL Server

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

Important

I cluster Big Data di Microsoft SQL Server 2019 sono stati ritirati. Il supporto per i cluster Big Data di SQL Server 2019 è terminato a partire dal 28 febbraio 2025. Per altre informazioni, vedere il post di blog sull'annuncio e le opzioni per Big Data nella piattaforma Microsoft SQL Server.

Il percorso di aggiornamento dipende dalla versione corrente del cluster Big Data di SQL Server. Per eseguire l'aggiornamento da una versione supportata, inclusa la versione di distribuzione generale (GDR), l'aggiornamento cumulativo (CU) o l'aggiornamento QFE (Quick Fix Engineering), è possibile eseguire l'aggiornamento sul posto. L'aggiornamento in loco da una versione CTP (Community Technology Preview) o versione candidata al rilascio di BDC non è supportato. È necessario rimuovere e ricreare il cluster. Le sezioni seguenti descrivono i passaggi per ogni scenario:

Eseguire l'aggiornamento dalla versione supportata
Aggiornare una distribuzione BDC da CTP o versione candidata

Note

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

Note sulla versione di aggiornamento

Prima di procedere, controllare le note sulla versione dell'aggiornamento per i problemi noti.

Warning

È stato necessario impostare il parametro imagePullPolicy come "Always" nel profilo di distribuzione control.json file al momento della distribuzione iniziale del cluster. Questo parametro non può essere modificato dopo la distribuzione. Nel caso in cui sia impostato con un valore diverso, i risultati imprevisti possono verificarsi durante il processo di aggiornamento e sarà necessaria una ridistribuzione del cluster.

Eseguire l'aggiornamento dalla versione supportata

Questa sezione illustra come aggiornare un cluster big data di SQL Server da una versione supportata (a partire da SQL Server 2019 GDR1) a una versione supportata più recente.

Verificare che non siano attive sessioni Livy.

Assicurarsi che non siano in esecuzione sessioni Livy o processi batch attivi in Azure Data Studio. Un modo semplice per confermare questa operazione è tramite curl il comando o un browser per richiedere questi URL:
- <your-gateway-endpoint>/gateway/default/livy/v1/sessions
- <your-gateway-endpoint>/gateway/default/livy/v1/batches
Eseguire il backup dell'istanza master di SQL Server.

Eseguire il backup di HDFS.

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

For example:

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

Aggiornare Azure Data CLI (azdata).

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

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

Aggiornare il cluster Big Data.

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

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

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

Note

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

Important

Se si utilizza un repository privato per eseguire il pre-pull delle immagini per distribuire o aggiornare BDC, garantire che le immagini di build attuali e le immagini di build di destinazione siano presenti nel repository privato. In questo modo è possibile eseguire correttamente il rollback, se necessario. Inoltre, se sono state modificate le >credenziali del repository privato dopo la distribuzione originale, aggiornare le variabili di ambiente corrispondenti DOCKER_PASSWORD e >DOCKER_USERNAME. L'aggiornamento con repository privati diversi per la build corrente e quella di destinazione non è supportato.

Aumentare il timeout per l'aggiornamento

Un timeout può verificarsi se alcuni componenti non vengono aggiornati nel tempo allocato. Il codice seguente mostra l'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 dalla versione DI SQL Server 2019 CU2. For example:

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 per il completamento dell'aggiornamento del controller o del database del controller. --component-timeout definisce la quantità di tempo necessario per il completamento di ogni fase successiva dell'aggiornamento.

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

Eseguire il comando seguente:

kubectl edit configmap controller-upgrade-configmap

Modificare i campi seguenti:

controllerUpgradeTimeoutInMinutes Definisce il numero di minuti di attesa per il completamento dell'aggiornamento del controller o del database del controller. Il valore predefinito è 5. Aggiorna ad almeno 20. totalUpgradeTimeoutInMinutes: definisce la quantità combinata di tempo per il completamento dell'aggiornamento del controller e del database del controller (aggiornamento del controller e del database controller). Il valore predefinito è 10. Aggiornare ad almeno 40. componentUpgradeTimeoutInMinutes: indica la quantità di tempo necessario per il completamento di ogni fase successiva dell'aggiornamento. Il valore predefinito è 30. Aggiornamento alla versione 45.

Salvare ed uscire.

Aggiornare una distribuzione BDC da CTP o versione candidata

L'aggiornamento diretto da una build CTP o release candidate di cluster Big Data di SQL Server non è supportato. La sezione seguente illustra come rimuovere e ricreare manualmente il cluster.

Eseguire il backup ed eliminare il cluster precedente

Non è disponibile alcun aggiornamento sul posto per i cluster Big Data distribuiti prima della versione GDR1 di SQL Server 2019. L'unico modo per eseguire l'aggiornamento a una nuova versione consiste nel rimuovere e ricreare manualmente il cluster. Ogni versione ha una versione univoca dell'interfaccia della riga di comando dei dati di Azure (azdata) non compatibile con la versione precedente. Inoltre, se un'immagine del contenitore più recente viene scaricata nel cluster distribuito con una versione precedente diversa, l'immagine più recente potrebbe non essere compatibile con le immagini precedenti nel cluster. L'immagine più recente viene estratta se si usa il tag immagine latest nel file di configurazione della distribuzione per le impostazioni del contenitore. Per impostazione predefinita, ogni versione ha un tag di immagine specifico corrispondente alla versione di SQL Server. Per eseguire l'aggiornamento alla versione più recente, seguire questa procedura:

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 il backup e il ripristino di SQL Server. Per HDFS, è possibile copiare i dati con curl.
Eliminare il cluster precedente con il azdata delete cluster comando .
```
 azdata bdc delete --name <old-cluster-name>
```
Important

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

Note

L'esecuzione di un azdata bdc delete comando 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. Lo spazio dei nomi può essere riutilizzato per le distribuzioni successive, purché sia vuoto e non siano state create altre applicazioni all'interno.

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

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

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

Windows:
```
pip3 install -r https://aka.ms/azdata
```
Linux:
```
pip3 install -r https://aka.ms/azdata --user
```
Important

Per ogni rilascio, cambia il percorso della versione di Azure Data CLI (n-1azdata). Anche se in precedenza è stata installata l'interfaccia della riga di comando dati di Azure (azdata), è necessario reinstallare dal percorso più recente prima di creare il nuovo cluster.

Verificare la versione azdata

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

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 di 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 tutti i database o i file necessari.

Next steps

Per altre informazioni sui cluster Big Data, vedere Che cosa sono i cluster Big Data di SQL Server.

Last updated on 2023-03-07

Condividi tramite