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.
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
curloder über einen Browser, um diese URLs anzufordern:<your-gateway-endpoint>/gateway/default/livy/v1/sessions<your-gateway-endpoint>/gateway/default/livy/v1/batches
Sichern Sie die SQL Server-Masterinstanz.
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 ./%%DAktualisieren Sie Azure Data CLI (
azdata).Befolgen Sie die Anweisungen zur Installation von Azure Data CLI (
azdata).Hinweis
Wenn Azure Data CLI (
azdata) mitpipinstalliert wurde, müssen Sie es vor der Installation mit Windows Installer oder mit dem Linux-Paket-Manager manuell entfernen.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:
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
curlherauskopieren.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.Deinstallieren Sie die alte Version von Azure Data CLI (
azdata).pip3 uninstall -r https://azdatacli.blob.core.windows.net/python/azdata/2019-rc1/requirements.txtInstallieren 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/azdataLinux:
pip3 install -r https://aka.ms/azdata --userWichtig
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?.
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für