Upgraden von Big Data-Cluster für SQL Server

Gilt für: SQL Server 2019 (15.x)

Wichtig

Das Microsoft SQL Server 2019-Big Data-Cluster-Add-On wird eingestellt. Der Support für SQL Server 2019-Big Data-Clusters endet am 28. Februar 2025. Alle vorhandenen Benutzer*innen von SQL Server 2019 mit Software Assurance werden auf der Plattform vollständig unterstützt, und die Software wird bis zu diesem Zeitpunkt weiterhin über kumulative SQL Server-Updates verwaltet. Weitere Informationen finden Sie im Ankündigungsblogbeitrag und unter Big Data-Optionen auf der Microsoft SQL Server-Plattform.

Der Upgradepfad richtet sich nach der aktuellen Version von SQL Server-Big Data-Cluster. Für ein Upgrade von einem unterstützten Release, einschließlich allgemeine Vertriebsversion, kumulatives Update oder Quick Fix Engineering (QFE), kann ein direktes Upgrade durchgeführt werden. Ein direktes Upgrade von einer CTP- (Community Technology Preview) oder Release Candidate-Version des BDC wird nicht unterstützt. Sie müssen den Cluster entfernen und neu erstellen. In den folgenden Abschnitten werden die jeweils erforderlichen Schritte beschrieben:

• Upgrade von einem unterstützten Release
• Aktualisieren einer BDC-Bereitstellung von einer CTP- oder Release Candidate-Version

Hinweis

Die älteste derzeit unterstützte Version von Big Data-Clustern ist SQL Server 2019 CU8.

Upgrade-Versionshinweise

Bevor Sie fortfahren, sollten Sie die Upgrade-Versionshinweise auf bekannte Probleme prüfen.

Warnung

Der Parameter imagePullPolicy musste bei der ursprünglichen Bereitstellung des Clusters in der Datei „control.json“ des Bereitstellungsprofils auf "Always" festgelegt werden. Dieser Parameter kann nach der Bereitstellung nicht mehr geändert werden. Falls ein anderer Wert festgelegt wurde, kann es während des Upgradevorgangs zu unerwarteten Ergebnissen kommen, und der Cluster muss möglicherweise erneut bereitgestellt werden.

Upgrade von einem unterstützten Release

In diesem Abschnitt wird erläutert, wie ein BDC für SQL Server von einem unterstützten Release (ab SQL Server 2019 GDR1) auf ein neueres unterstütztes Release aktualisiert wird.

1. Prüfen Sie auf aktive Livy-Sitzungen.

   Vergewissern Sie sich, dass in Azure Data Studio keine aktiven Livy-Sitzungen oder Batchaufträge ausgeführt werden. Eine einfache Möglichkeit, dies zu bestätigen, ist entweder über den Befehl curl oder über einen Browser, um diese URLs anzufordern:

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

2. Sichern Sie die SQL Server-Masterinstanz.

3. Sichern Sie das HDFS (Hadoop Distributed File System).

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

   Beispiel:

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

4. Aktualisieren Sie Azure Data CLI (azdata).

   Befolgen Sie die Anweisungen zur Installation von Azure Data CLI (azdata).

   • Windows Installer
   • Linux mit apt
   • Linux mit yum
   • Linux mit zypper

   Hinweis

   Wenn Azure Data CLI (azdata) mit pip installiert wurde, müssen Sie es vor der Installation mit Windows Installer oder mit dem Linux-Paket-Manager manuell entfernen.

5. Aktualisieren Sie den Big Data-Cluster.

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

   Das folgende Skript verwendet beispielsweise das Imagetag 2019-CU19-ubuntu-20.04:

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

Hinweis

Die neuesten Imagetags finden Sie in den Versionshinweisen zu Big Data-Clustern in SQL Server 2019.

Wichtig

Wenn Sie ein privates Repository verwenden, um die Images für die Bereitstellung oder das Upgrade eines BDC vorab abzurufen, stellen Sie sicher, dass sich die aktuellen Buildimages sowie die >Zielbuildimages im privaten Repository befinden. Dadurch kann bei Bedarf ein Rollback durchgeführt werden. Wenn Sie die >Anmeldeinformationen des privaten Repositorys seit der ursprünglichen Bereitstellung geändert haben, müssen Sie zudem die entsprechenden Umgebungsvariablen DOCKER_PASSWORD und >DOCKER_USERNAME aktualisieren. Ein Upgrade unter Verwendung unterschiedlicher privater Repositorys für den aktuellen Build und den Zielbuild wird nicht unterstützt.

Erhöhen des Timeoutwerts für das Upgrade

Ein Timeout kann auftreten, wenn bestimmte Komponenten nicht in der zugewiesenen Zeit aktualisiert werden. Der folgende Code zeigt, wie der Fehler aussehen könnte:

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

Sie können die Timeouts für ein Upgrade erhöhen, indem Sie die Parameter --controller-timeout und --component-timeout nutzen, um höhere Werte festzulegen, wenn Sie das Upgrade initiieren. Diese Option ist nur ab SQL Server 2019 CU2 verfügbar. Beispiel:

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

--controller-timeout gibt die Wartezeit in Minuten an, bis der Controller oder die Controllerdatenbank das Upgrade abgeschlossen hat. --component-timeout gibt die Zeitdauer an, in der jede nachfolgende Phase des Upgrades abgeschlossen sein muss.

Bearbeiten Sie in Releases vor SQL Server 2019 CU19 die ConfigMap für Upgrades, um die Timeoutwerte für Upgrades zu erhöhen. So bearbeiten Sie die Konfigurationszuordnung für Upgrades:

Führen Sie den folgenden Befehl aus:

kubectl edit configmap controller-upgrade-configmap

Bearbeiten Sie die unten aufgeführten Felder:

controllerUpgradeTimeoutInMinutes Gibt die Wartezeit in Minuten an, bis der Controller oder die Controllerdatenbank das Upgrade abgeschlossen hat. Der Standardwert ist 5. Aktualisieren Sie diesen Wert auf mindestens 20. totalUpgradeTimeoutInMinutes: Gibt die kombinierte Zeitdauer an, bis der Controller und die Controllerdatenbank das Upgrade abgeschlossen haben (Upgrade von Controller und Controllerdatenbank). Der Standardwert ist 10. Aktualisieren Sie diesen Wert auf mindestens 40. componentUpgradeTimeoutInMinutes: Gibt die Zeitdauer an, in der jede nachfolgende Phase des Upgrades abgeschlossen sein muss. Der Standardwert ist 30. Aktualisieren Sie diesen Wert auf 45.

Speichern Sie Ihre Änderungen, und schließen Sie die Anwendung.

Aktualisieren einer BDC-Bereitstellung von einer CTP- oder Release Candidate-Version

Ein direktes Upgrade von einem CTP- oder Release Candidate-Build von SQL Server-Big Data-Clustern wird nicht unterstützt. Im folgenden Abschnitt wird erläutert, wie der Cluster manuell entfernt und neu erstellt wird.

Sichern und Löschen des alten Clusters

Für Big Data-Cluster, die vor SQL Server 2019 GDR1 bereitgestellt wurden, ist kein direktes Upgrade möglich. Um ein Upgrade auf ein neues Release durchzuführen, muss der Cluster manuell entfernt und neu erstellt werden. Jedes Release verfügt über eine eindeutige Version von Azure Data CLI (azdata), die mit der vorherigen Version nicht kompatibel ist. Auch wenn ein neueres Containerimage auf einem Cluster herunterladen wird, der mit einer älteren Version bereitgestellt wurde, ist das aktuelle Image möglicherweise nicht mit den älteren Images auf dem Cluster kompatibel. Das neuere Image wird abgerufen, wenn Sie das Imagetag latest in der Bereitstellungskonfigurationsdatei für die Containereinstellungen verwenden. Standardmäßig verfügt jedes Release über ein bestimmtes Imagetag, das der Releaseversion von SQL Server entspricht. Führen Sie die folgenden Schritte aus, um ein Upgrade auf das neueste Release durchzuführen:

1. Sichern Sie vor dem Löschen des alten Clusters die Daten auf der SQL Server-Masterinstanz und auf HDFS. Für die SQL Server-Masterinstanz können Sie SQL Server-Sicherung und -Wiederherstellung verwenden. Für HDFS können Sie die Daten mit curl herauskopieren.

2. Löschen Sie den alten Cluster mit dem azdata delete cluster-Befehl.

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

   Wichtig

   Verwenden Sie die Version von Azure Data CLI (azdata), die Ihrem Cluster entspricht. Löschen Sie keinen älteren Cluster mit der neueren Version von Azure Data CLI (azdata).

   Hinweis

   Wenn Sie einen azdata bdc delete-Befehl ausführen, werden alle innerhalb des Namespace erstellten Objekte mit dem Namen des Big Data-Clusters gelöscht, der Namespace jedoch nicht. Der Namespace kann für nachfolgende Bereitstellungen wiederverwendet werden, solange er leer ist und keine anderen Anwendungen in ihm erstellt wurden.

3. Deinstallieren Sie die alte Version von Azure Data CLI (azdata).

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

4. Installieren Sie die neueste Version von Azure Data CLI (azdata). Mit den folgenden Befehlen wird Azure Data CLI (azdata) aus dem neuesten Release installiert:

   Windows:

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

   Linux:

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

   Wichtig

   Für jedes Release ändert sich der Pfad zur n-1-Version von Azure Data CLI (azdata). Auch wenn Sie zuvor Azure Data CLI (azdata) installiert haben, müssen Sie vor dem Erstellen des neuen Clusters vom aktuellen Pfad aus neu installieren.

Überprüfen der azdata-Version

Vergewissern Sie sich vor dem Bereitstellen eines neuen Big Data-Clusters, dass Sie die neueste Version von Azure Data CLI (azdata) mit dem --version-Parameter verwenden:

azdata --version

Installieren des neuen Releases

Nachdem Sie den vorherigen Big Data-Cluster entfernt und die neueste Azure Data CLI (azdata)-Version installiert haben, stellen Sie den neuen Big Data-Cluster mithilfe der aktuellen Bereitstellungsanweisungen bereit. Weitere Informationen finden Sie unter Vorgehensweise: Bereitstellen von Big Data-Cluster für SQL Server auf Kubernetes. Stellen Sie anschließend alle erforderlichen Datenbanken oder Dateien wieder her.

Nächste Schritte

Weitere Informationen zu Big Data-Clustern finden Sie unter Was sind Big Data-Cluster für SQL Server?.