Guide pratique pour effectuer la mise à niveau de Clusters Big Data SQL Server

Article
03/13/2023

S’applique à : SQL Server 2019 (15.x)

Important

Le module complémentaire Clusters Big Data Microsoft SQL Server 2019 sera mis hors service. La prise en charge de la plateforme Clusters Big Data Microsoft SQL Server 2019 se terminera le 28 février 2025. Tous les utilisateurs existants de SQL Server 2019 avec Software Assurance seront entièrement pris en charge sur la plateforme, et le logiciel continuera à être maintenu par les mises à jour cumulatives SQL Server jusqu’à ce moment-là. Pour plus d’informations, consultez le billet de blog d’annonce et les Options Big Data sur la plateforme Microsoft SQL Server.

Le chemin de mise à niveau dépend de la version actuelle de SQL Server Big Data cluster. Pour effectuer une mise à niveau à partir d’une version prise en charge, comme une mise à jour à disponibilité générale (GDR), une mise à jour cumulative (CU) ou une mise à jour QFE (Quick Fix Engineering), vous pouvez mettre à niveau sur place. La mise à niveau sur place à partir d’une version CTP (Community Technology Preview) ou d’une version RC (Release Candidate) de BDC n’est pas prise en charge. Vous devez supprimer et recréer le cluster. Les sections suivantes décrivent les étapes pour chaque scénario :

Mise à niveau à partir d’une version prise en charge
Mettre à jour un déploiement BDC à partir d’une version CTP ou Release Candidate

Notes

La version la plus ancienne actuellement prise en charge de Clusters Big Data est SQL Server 2019 CU8.

Notes de publication de mise à niveau

Avant de continuer, consultez les notes de mise à niveau pour connaître les problèmes connus.

Avertissement

Le paramètre imagePullPolicy doit être défini comme "Always" dans le fichier de profil de déploiement control.json lors du déploiement initial du cluster. Ce paramètre ne peut pas être modifié après le déploiement. Dans le cas où il est défini sur une valeur différente, des résultats inattendus peuvent se produire pendant le processus de mise à niveau et un redéploiement du cluster est nécessaire.

Mise à niveau à partir d’une version prise en charge

Cette section explique comment mettre à niveau une version de SQL Server BDC prise en charge (à compter de SQL Server 2019 GDR1) vers une version prise en charge plus récente.

Vérifiez l’absence de sessions Livy actives.

Assurez-vous qu’aucune session Livy n’est active et qu’aucun travail de traitement par lots n’est en cours d’exécution dans Azure Data Studio. Pour ce faire, vous pouvez utiliser la commande curl ou un navigateur pour demander ces URL :
- <your-gateway-endpoint>/gateway/default/livy/v1/sessions
- <your-gateway-endpoint>/gateway/default/livy/v1/batches
Sauvegardez l’instance maître SQL Server.

Sauvegardez HDFS.

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

Exemple :

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

Mettez à jour Azure Data CLI (azdata).

Suivez les instructions d’installation de Azure Data CLI (azdata).
Notes

Si Azure Data CLI (azdata) a été installé avec pip vous devez le supprimer manuellement avant de procéder à l’installation avec Windows Installer ou le gestionnaire de package Linux.

Mettez à jour le cluster Big Data.

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

Par exemple, le script suivant utilise la balise d’image 2019-CU19-ubuntu-20.04 :

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

Notes

Les balises d’image les plus récentes sont disponibles dans les notes de publication des clusters Big Data SQL Server 2019.

Important

Si vous utilisez un dépôt privé pour pré-extraire les images pour le déploiement ou la mise à niveau de BDC, vérifiez que les images de build actuelles ainsi que >les images de build cibles se trouvent dans le dépôt privé. Cela permet une restauration réussie, si nécessaire. En outre, si vous avez modifié les >informations d’identification du dépôt privé depuis le déploiement d’origine, mettez à jour les variables d’environnement correspondantes DOCKER_PASSWORD et >DOCKER_USERNAME. La mise à niveau avec des dépôts privés différents pour les builds actuelles et cibles n’est pas prise en charge.

Augmentez le délai d’expiration de la mise à niveau

Un délai d’expiration peut se produire si certains composants ne sont pas mis à niveau dans le temps imparti. Le code suivant montre à quoi peut ressembler l’échec :

>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.

Pour augmenter les délais d’expiration d’une mise à niveau, utilisez les paramètres --controller-timeout et --component-timeout afin de spécifier des valeurs plus élevées quand vous effectuez la mise à niveau. Cette option est disponible à compter de SQL Server 2019 CU2 uniquement. Exemple :

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

--controller-timeout spécifie le nombre de minutes à attendre avant la fin de la mise à niveau du contrôleur ou de la base de données du contrôleur. --component-timeout spécifie le délai d’exécution de chaque phase suivante de la mise à niveau.

Pour augmenter les délais d’expiration d’une mise à niveau antérieure à la version SQL Server 2019 CU19, modifiez le mappage de configuration de mise à niveau. Pour modifier le mappage de configuration de mise à niveau :

Exécutez la commande suivante :

kubectl edit configmap controller-upgrade-configmap

Modifiez les champs suivants :

controllerUpgradeTimeoutInMinutes Spécifie le nombre de minutes à attendre avant la fin de la mise à niveau du contrôleur ou de la base de données du contrôleur. La valeur par défaut est 5. Mettez à jour vers au moins 20. totalUpgradeTimeoutInMinutes : Spécifie le délai combiné du contrôleur et de la base de données du contrôleur pour terminer la mise à niveau (contrôleur + base de données contrôleur). La valeur par défaut est 10. Mettez à jour vers au moins 40. componentUpgradeTimeoutInMinutes : Désigne la durée d’exécution de chaque phase suivante de la mise à niveau. La valeur par défaut est 30. Mettez à jour vers 45.

Enregistrez et quittez.

Mettre à jour un déploiement BDC à partir d’une version CTP ou Release Candidate

La mise à niveau sur place à partir d’une version CTP ou Release Candidate des clusters Big Data SQL Server n’est pas prise en charge. La section suivante explique comment supprimer et recréer manuellement le cluster.

Sauvegarder et supprimer l’ancien cluster

Il n’existe aucune mise à niveau sur place pour les clusters Big Data déployés avant la version SQL Server 2019 GDR1. La seule façon de mettre à niveau vers une nouvelle version consiste à supprimer le cluster et à le recréer manuellement. Chaque version release comporte une version unique d’Azure Data CLI (azdata), qui n’est pas compatible avec la version précédente. En outre, si une nouvelle image de conteneur est téléchargée sur un cluster déployé avec une version antérieure différente, l’image la plus récente peut ne pas être compatible avec les anciennes images sur le cluster. L’image la plus récente est tirée (pull) si vous utilisez l’étiquette d’image latest dans le fichier config de déploiement pour les paramètres de conteneur. Par défaut, chaque version release a une étiquette d’image spécifique qui correspond à la version release de SQL Server. Pour effectuer une mise à niveau vers la dernière version, procédez comme suit :

Avant de supprimer l’ancien cluster, sauvegardez les données sur l’instance maître SQL Server et sur HDFS. Pour l’instance maître SQL Server, vous pouvez utiliser Sauvegarde et restauration d’une base de données SQL Server. Pour HDFS, vous pouvez copier les données avec curl.
Supprimez l’ancien cluster à l’aide de la commande azdata delete cluster.
```
 azdata bdc delete --name <old-cluster-name>
```
Important

Utilisez la version d’Azure Data CLI (azdata) qui correspond à votre cluster. Ne supprimez pas un ancien cluster avec la version la plus récente d’Azure Data CLI (azdata).

Notes

Si vous exécutez une commande azdata bdc delete, tous les objets créés dans l’espace de noms identifié par le nom du cluster Big Data sont supprimés, mais pas l’espace de noms lui-même. Vous pouvez réutiliser l’espace de noms pour d’autres déploiements, à condition qu’il soit vide et qu’aucune autre application n’y ait été créée.

Désinstallez l’ancienne version d’Azure Data CLI (azdata).

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

Installez la dernière version de Azure Data CLI (azdata). Les commandes suivantes permettent d’installer Azure Data CLI (azdata) à partir de la dernière version release :

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

Pour chaque version, le chemin de la version n-1 d’Azure Data CLI (azdata) change. Même si vous avez déjà installé Azure Data CLI (azdata), vous devez le réinstaller à partir du chemin le plus récent avant de créer le cluster.

Vérifier la version d’azdata

Avant de déployer un nouveau cluster Big Data, vérifiez que vous utilisez la dernière version de Azure Data CLI (azdata) avec le paramètre --version :

azdata --version

Installer la nouvelle version

Après avoir supprimé le cluster Big Data précédent et installé la dernière version d’Azure Data CLI (azdata), déployez le nouveau cluster Big Data à l’aide des instructions de déploiement actuelles. Pour plus d’informations, consultez Guide pratique pour déployer Clusters Big Data SQL Server sur Kubernetes. Ensuite, restaurez les bases de données ou les fichiers requis.

Étapes suivantes

Pour plus d’informations sur les clusters Big Data, consultez Que sont les Clusters Big Data SQL Server ?.