Upgrade von Replikaten von Verfügbarkeitsgruppen

Gilt für:SQL Server

Wenn eine SQL Server-Instanz, die eine Always On-Verfügbarkeitsgruppe (AG) hostet, auf eine neue SQL Server-Version, ein neues SQL Server-Service Pack oder ein kumulatives Update upgegradet wird, oder wenn Sie ein neues Windows Service Pack oder ein kumulatives Update installieren, können Sie die Downtime des primären Replikats auf ein einziges manuelles Failover reduzieren, indem Sie ein paralleles Upgrade (oder zwei manuelle Failovers, falls Sie ein Failback auf das ursprüngliche primäre Replikat durchführen) durchführen.

Während des Upgradevorgangs steht ein sekundäres Replikat nicht für Failover- oder schreibgeschützte Vorgänge zur Verfügung, und nach dem Upgrade kann es einige Zeit dauern, bis das sekundäre Replikat den primären Replikatknoten in Abhängigkeit vom Aktivitätsvolumen des primären Replikatknotens aufholen kann (sodass hoher Netzwerkdatenverkehr erwartet wird).

Beachten Sie außerdem, dass die Datenbanken in dieser Verfügbarkeitsgruppe nach dem ersten Failover auf ein sekundäres Replikat, auf dem eine neuere Version von SQL Server ausgeführt wird, einen Upgradeprozess durchlaufen, um sie auf die neueste Version zu aktualisieren. Währenddessen gibt es keine Lesereplikate für diese Datenbanken. Ausfallzeiten nach dem anfänglichen Failover hängen von der Anzahl der Datenbanken in der AG ab. Wenn Sie ein Failback auf das ursprüngliche Replikat durchführen möchten, wird dieser Schritt beim Failback nicht wiederholt.

Voraussetzungen

Lesen Sie die folgenden wichtigen Informationen, bevor Sie beginnen:

• Unterstützte Versions- und Editionsupgrades: Überprüfen Sie, ob Sie von Ihrer Version des Windows-Betriebssystems und Ihrer Version von SQL Server auf die aktuelle Version von SQL Server upgraden können. Wenn Sie beispielsweise ein direktes Upgrade von einer SQL Server 2005-Instanz durchführen, wird die Datenbankkompatibilitätsstufe aktualisiert.

• Auswählen einer Methode zum Upgraden der Datenbank-Engine: Wählen Sie die passende Upgrademethode und die passenden Schritte aus, die auf Ihrer Überprüfung der unterstützten Versions- und Editionsupgrades sowie auf den anderen Komponenten basieren, die in Ihrer Umgebung installiert sind, um das Upgrade in der richtigen Reihenfolge durchzuführen.

• Planen und testen Sie den Upgradeplan des Datenbankmoduls: Überprüfen Sie die Versionshinweise und bekannte Upgradeprobleme, die Checkliste für das Preupgrade und entwickeln und testen Sie den Upgradeplan.

• Hardware- und Softwareanforderungen für die Installation von SQL Server: Überprüfen Sie die Softwareanforderungen für die Installation von SQL Server. Falls zusätzliche Software erforderlich ist, installieren Sie diese auf jedem Knoten, bevor Sie mit dem Upgradevorgang beginnen, um die Downtime zu minimieren.

• Überprüfen, ob Change Data Capture oder die Replikation für Datenbanken in Verfügbarkeitsgruppen verwendet wird: Wenn Datenbanken in der Verfügbarkeitsgruppe für Change Data Capture (CDC) aktiviert sind, folgen Sie diesen Anweisungen.

Grundlagen zu parallelen Upgrades für Verfügbarkeitsgruppen

Beachten Sie folgende Richtlinien, wenn Sie Serverupgrades oder -updates durchführen, um die Downtime und den Datenverlust Ihrer Verfügbarkeitsgruppen zu minimieren:

• Bevor Sie das parallele Upgrade starten:

  • Führen Sie ein manuelles Failover für mindestens eine Ihrer synchronen Commit-Replikatinstanzen durch.

  • Schützen Sie Ihre Daten, indem Sie eine vollständige Datenbanksicherung für jede Verfügbarkeitsdatenbank durchführen.

  • Wird für jede Verfügbarkeitsdatenbank ausgeführt DBCC CHECKDB .

• Führen Sie das Upgrade zuerst immer für die sekundären Remotereplikatinstanzen und dann für die lokalen sekundären Replikatinstanzen und zuletzt für die primäre Replikatinstanz durch.

• Von einer Datenbank, für die gerade ein Upgrade ausgeführt wird, kann keine Sicherung erstellt werden. Vor dem Aktualisieren der sekundären Replikate konfigurieren Sie die Voreinstellung für die automatisierte Sicherung, um Sicherungen nur auf dem primären Replikat auszuführen. Während eines Versionsupgrades sind Replikate nicht lesbar oder für Sicherungen verfügbar. Während eines Nichtversionsupgrades können Sie automatisierte Sicherungen so konfigurieren, dass sie auf sekundären Replikaten ausgeführt werden, bevor Sie das primäre Replikat aktualisieren.

• Während eines Versionsupgrades können lesbare sekundäre Replikate zwischenzeitlich nicht gelesen werden. Dieser Zeitraum der Nicht-Lesbarkeit beginnt, nachdem das Upgrade auf das sekundäre Replikat durchgeführt wurde, und hält an, bis für das primäre Replikat ein Failover auf ein upgegradetes sekundäres Replikat durchgeführt wurde oder das primäre Replikat selbst upgegradet wurde.

• Damit für die Verfügbarkeitsgruppe während des Upgrades kein unbeabsichtigtes Failover ausgeführt wird, entfernen Sie das Verfügbarkeitsfailover zunächst von allen Replikaten mit synchronem Commit.

• Führen Sie für die primäre Replikatinstanz kein Upgrade aus, bevor Sie für die Verfügbarkeitsgruppe ein Failover auf eine upgegradete Instanz mit einem sekundären Replikat ausgeführt haben. Andernfalls können Clientanwendungen während des Upgrades auf der primären Replikatinstanz zu längeren Ausfallzeiten führen.

• Führen Sie für die Verfügbarkeitsgruppe immer ein Failover auf eine sekundäre Replikatinstanz mit synchronem Commit aus. Falls Sie ein Failover auf eine sekundäre Replikatinstanz mit asynchronem Commit ausführen, werden die Datenbanken anfällig für Datenverluste, und die Datenverschiebung wird automatisch so lange angehalten, bis Sie den Vorgang manuell fortsetzen.

• Führen Sie für die primäre Replikatinstanz kein Upgrade durch, bevor Sie nicht eine der anderen sekundären Replikatinstanzen upgegradet oder aktualisiert haben. Ein primäres Replikat, für das ein Upgrade ausgeführt wurde, kann keine Protokolle mehr an sekundäre Replikate versenden, deren SQL Server-Instanz noch nicht auf die gleiche Version aktualisiert wurde. Wenn eine Datenverschiebung zu einem sekundären Replikat angehalten wurde, kann für dieses Replikat kein automatisches Failover ausgeführt werden, und die Verfügbarkeitsdatenbanken sind anfällig für Datenverluste. Dies gilt auch bei einem rollierenden Upgrade, bei dem Sie manuell von einer alten Primären auf eine neue Primäre fehlschlagen. Nachdem Sie das Upgrade des alten Primärservers durchgeführt haben, müssen Sie möglicherweise die Synchronisierung wieder aufnehmen.

• Bevor Sie ein Failover für eine Verfügbarkeitsgruppe ausführen, sollten Sie überprüfen, ob der Synchronisierungsstatus des Failoverziels SYNCHRONIZED lautet.

  Warnung

  Wenn Sie eine neue Instanz oder eine neue Version von SQL Server auf einem Server installieren, auf dem eine ältere Version von SQL Server installiert ist, kann versehentlich ein Ausfall für jede Verfügbarkeitsgruppe verursacht werden, die von der älteren Version von SQL Server gehostet wird. Dies liegt daran, dass während der Installation der Instanz oder Version von SQL Server das SQL Server-Modul für hohe Verfügbarkeit (RHS.EXE) aktualisiert wird. Dadurch werden Ihre vorhandenen Verfügbarkeitsgruppen in der primären Rolle auf dem Server vorübergehend unterbrochen. Daher wird dringend empfohlen, eine der folgenden Aktionen auszuführen, wenn Sie eine neuere Version von SQL Server auf einem System installieren, das bereits eine ältere Version von SQL Server mit einer Verfügbarkeitsgruppe hostt:

  • Installieren der neuen Version von SQL Server während eines Wartungsfensters.

  • Führen Sie einen Failover der Verfügbarkeitsgruppe zum sekundären Replikat durch, sodass sie während der Installation der neuen SQL Server-Instanz nicht primär ist.

Prozess des parallelen Upgrades

Die genauen Schritte hängen von Faktoren wie der Bereitstellungstopologie Ihrer Verfügbarkeitsgruppen und dem Commitmodus der einzelnen Replikate ab. Im einfachsten Szenario ist ein rollierendes Upgrade jedoch ein mehrstufiger Prozess, der in seiner einfachsten Form die folgenden Schritte umfasst:

1. Deaktivieren des automatischen Failovers für alle Replikate mit synchronem Commit
2. Durchführen von Upgrades für alle Instanzen von sekundären Replikaten mit asynchronem Commit
3. Durchführen von Upgrades für alle Remoteinstanzen von sekundären Replikaten mit synchronem Commits
4. Durchführen von Upgrades für alle lokalen Instanzen von sekundären Replikaten mit synchronem Commits
5. Ausführen eines manuellen Failovers der Verfügbarkeitsgruppe auf ein (neu aktualisiertes) lokales sekundäres Replikat mit synchronem Commit
6. Durchführen eines Upgrades oder Updates der lokalen Replikatinstanz, in der zuvor das primäre Replikat gehostet wurde
7. Konfigurieren automatischer Failoverpartner nach Bedarf

Bei Bedarf können Sie ein zusätzliches manuelles Failover ausführen, um die ursprüngliche Konfiguration der Verfügbarkeitsgruppe wiederherzustellen.

Durch das Upgrade eines synchronen Commit-Replikats und das Herunterfahren werden Transaktionen auf dem Primärserver nicht verzögert. Sobald die Verbindung des sekundären Replikats getrennt wurde, werden die Transaktionen des primären Replikats committet, ohne dass darauf gewartet wird, dass die Protokolle des sekundären Replikats festgeschrieben werden. Wenn REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT auf entweder 1 oder 2 festgelegt ist, ist das Primärreplikat möglicherweise für Lese-/Schreibvorgänge nicht verfügbar, wenn eine entsprechende Anzahl von sekundären Synchronisierungsreplikaten während des Aktualisierungsprozesses nicht verfügbar ist.

Wenn Sie ein direktes Upgrade einer sekundären Replik auf eine neuere Version von SQL Server durchführen, verbleibt die Datenbank innerhalb der Verfügbarkeitsgruppe im Status Synchronisieren/In Wiederherstellung oder Synchronisiert/In Wiederherstellung, bis für die Verfügbarkeitsgruppe manuell ein Failover ausgeführt wird, wodurch die Wiederherstellung abgeschlossen ist und die Datenbank aktualisiert wird. Ein aktualisiertes primäres Replikat kann keine Protokolle mehr an sekundäre Replikate der niedrigeren Version senden, und datenverschiebungsstopps, kein automatisches Failover kann für dieses Replikat auftreten, und Ihre Verfügbarkeitsdatenbanken sind anfällig für Datenverluste. Nachdem Sie das alte Primäre aktualisiert haben, müssen Sie möglicherweise die Synchronisierung fortsetzen. Es wird empfohlen, alle sekundären Replikate zu aktualisieren, bevor ein Replikat mit der neuen Version fehlschlägt. Auf diese Weise haben Sie die Möglichkeit, ein Failover durchzuführen, nachdem die Datenbank(n) auf das neue Format aktualisiert wurde.

Verfügbarkeitsgruppe mit einem sekundären Remotereplikat

Wenn Sie eine AG nur für die Notfallwiederherstellung bereitgestellt haben, müssen Sie möglicherweise auf ein sekundäres Replikat mit asynchronem Commit umschalten. Die folgende Abbildung zeigt eine solche Konfiguration:

In diesem Fall müssen Sie für die Verfügbarkeitsgruppe während des parallelen Upgrades ein Failover auf das sekundäre Replikat mit asynchronem Commit ausführen. Um Datenverluste zu verhindern, ändern Sie den Commit-Modus in synchronen Commit, und warten Sie, bis das sekundäre Replikat synchronisiert wird, bevor Sie die AG fehlschlagen. Daher kann der rollierende Upgradeprozess wie folgt aussehen:

1. Aktualisieren Sie die sekundäre Replikatinstanz auf der Remotewebsite.
2. Ändern Sie den Commitmodus in synchronen Commit.
3. Warten Sie, bis der Synchronisierungsstatus lautet SYNCHRONIZED.
4. Fail over the AG to the secondary replica on the remote site.
5. Aktualisieren oder Aktualisieren der lokalen Replikatinstanz (primäre Website).
6. Fail over the AG back to the primary site.
7. Ändern Sie den Commitmodus in asynchronen Commit.

Da der Synchron-Commit-Modus keine empfohlene Einstellung für die Datensynchronisierung mit einem Remotestandort ist, bemerken Clientanwendungen möglicherweise eine sofortige Erhöhung der Datenbanklatenz nach der Einstellungsänderung. Darüber hinaus führt ein Failover dazu, dass alle unbestätigten Protokollmeldungen verworfen werden. Die Anzahl der verworfenen Protokollnachrichten kann aufgrund der hohen Netzwerklatenz zwischen den beiden Standorten erheblich sein, was dazu führt, dass Clients ein hohes Transaktionsvolumen verursachen. Sie können die Auswirkungen auf die Clientanwendungen mithilfe der folgenden Maßnahmen minimieren:

• Wählen Sie sorgfältig ein Wartungsfenster während des niedrigen Clientdatenverkehrs aus.

• Wenn Sie SQL Server auf dem primären Standort aktualisieren oder aktualisieren, ändern Sie den Verfügbarkeitsmodus wieder in asynchronen Commit, und kehren Sie dann zum synchronen Commit zurück, wenn Sie bereit sind, den primären Standort erneut zu übernehmen.

Verfügbarkeitsgruppe mit Failoverclusterinstanz-Knoten

Falls eine Verfügbarkeitsgruppe Failoverclusterinstanz-Knoten (Failover Cluster Instance, FCI) enthält, sollten Sie die inaktiven Knoten vor den aktiven Knoten upgraden. In der folgenden Abbildung ist ein gängiges Szenario für Verfügbarkeitsgruppen mit FCIs dargestellt. Es basiert auf FCIs, die auf lokale Hochverfügbarkeit und asynchrone Commits zur Remotenotfallwiederherstellung ausgelegt sind, und veranschaulicht die Schritte zum Ausführen des Upgrades.

1. Upgraden oder Aktualisieren von REMOTE2
2. Failover von FCI2 auf REMOTE2
3. Upgraden oder Aktualisieren von REMOTE1
4. Upgraden oder Aktualisieren von PRIMARY2
5. Failover von FCI1 auf PRIMARY2
6. Upgraden oder Aktualisieren von PRIMARY1

Upgraden oder Aktualisieren von SQL Server-Instanzen mit mehreren Verfügbarkeitsgruppen

Wenn Sie mehrere AGs mit primären Replikaten auf separaten Serverknoten (eine Active/Active-Konfiguration) ausführen, umfasst der Upgradepfad weitere Failoverschritte, um hohe Verfügbarkeit im Prozess zu erhalten. Angenommen, Sie führen drei AGs auf drei Serverknoten mit allen Replikaten im synchronen Commit-Modus aus, wie in der folgenden Tabelle gezeigt:

Es kann in Ihrer Situation sinnvoll sein, ein Rollupgrade mit Lastenausgleich in der folgenden Reihenfolge durchzuführen:

1. Failover von VG2 auf Node3 (um Node2 freizugeben)
2. Upgraden oder Aktualisieren von Node2
3. Failover von VG1 auf Node2 (um Node1 freizugeben)
4. Upgraden oder Aktualisieren von Node1
5. Failover sowohl von VG2 als auch von VG3 auf Node1 (um Node3 freizugeben)
6. Upgraden oder Aktualisieren von Node3
7. Failover von VG3 auf Node3

Bei dieser Art von Upgrade beträgt die durchschnittliche Downtime weniger als zwei Failovers pro Verfügbarkeitsgruppe. Die daraus resultierende Konfiguration ist in der folgenden Tabelle dargestellt.

Basierend auf Ihrer spezifischen Implementierung kann ihr Upgradepfad variieren, und die Ausfallzeiten, die die Clientanwendungen erleben, können ebenfalls variieren.

Paralleles Upgrade einer verteilten Verfügbarkeitsgruppe

Wenn Sie ein paralleles Upgrade für eine verteilte Verfügbarkeitsgruppe durchführen möchten, müssen Sie zunächst alle sekundären Replikate upgraden. Führen Sie als Nächstes einen Failover über die Weiterleitung durch, und führen Sie ein Upgrade der letzten verbleibenden Instanz der zweiten Verfügbarkeitsgruppe durch. Sobald alle anderen Replikate aktualisiert wurden, schlagen Sie die globale primäre Primäre fehl, und führen Sie ein Upgrade der letzten verbleibenden Instanz der ersten Verfügbarkeitsgruppe durch. Ein detailliertes Diagramm mit Schritten wird in einem späteren Abschnitt bereitgestellt.

Basierend auf Ihrer spezifischen Implementierung kann ihr Upgradepfad variieren, und die Ausfallzeiten, die die Clientanwendungen erleben, können ebenfalls variieren.

Allgemeine Schritte für das Upgrade einer verteilten Verfügbarkeitsgruppe

1. Sichern Sie alle Datenbanken, einschließlich Systemdatenbanken und derjenigen, die an der Verfügbarkeitsgruppe teilnehmen.
2. Führen Sie ein Upgrade für alle sekundären Replikate der sekundären Verfügbarkeitsgruppe durch (der Downstream), und starten Sie sämtliche sekundären Replikate neu.
3. Führen Sie ein Upgrade für alle sekundären Replikate der primären Verfügbarkeitsgruppe durch (der Upstream), und starten Sie sämtliche sekundären Replikate neu.
4. Führen Sie ein Failover für das primäre Replikat der Weiterleitung auf ein aktualisiertes sekundäres Replikat der sekundären Verfügbarkeitsgruppe durch.
5. Warten Sie, bis die Daten synchronisiert wurden. Die Datenbanken sollten auf allen Replikaten mit synchronem Commit als synchronisiert angezeigt werden, und das globale primäre Replikat sollte mit der Weiterleitung synchronisiert sein.
6. Upgraden Sie die letzte verbleibende Instanz der sekundäre Verfügbarkeitsgruppe, und starten Sie diese Instanz neu.
7. Führen Sie ein Failover für das globale primäre Replikat auf eine aktualisiertes sekundäre Replikat der primären Verfügbarkeitsgruppe durch.
8. Upgraden Sie die letzte verbleibende Instanz der primären Verfügbarkeitsgruppe.
9. Starten Sie den Server, für den das Upgrade gerade durchgeführt wurde.
10. (optional) Führen Sie ein Failover für beide Verfügbarkeitsgruppen zu deren ursprünglichen primären Replikaten zurück durch.

Beispieltabelle für ein paralleles Upgrade einer verteilten Verfügbarkeitsgruppe

Folgende Schritte für das Upgrade der Instanzen sind in dieser Tabelle enthalten:

1. Sichern Sie alle Datenbanken, einschließlich Systemdatenbanken und der Datenbanken, die an der Verfügbarkeitsgruppe beteiligt sind.
2. Upgraden Sie NODE4\SQLAG (sekundäres Replikat von AG2), und starten Sie den Server neu.
3. Upgraden Sie NODE2\SQLAG (sekundäres Replikat von AG1), und starten Sie den Server neu.
4. Führen Sie ein Failover für AG2 von NODE3\SQLAG auf NODE4\SQLAG durch.
5. Upgraden Sie NODE3\SQLAG, und starten Sie den Server neu.
6. Führen Sie ein Failover für AG1 von NODE1\SQLAG auf NODE2\SQLAG durch.
7. Upgraden Sie NODE1\SQLAG, und starten Sie den Server neu.
8. (optional) Führen Sie ein Failback auf die ursprünglichen primären Replikate durch.
   1. Führen Sie ein Failover für AG2 von NODE4\SQLAG zurück auf NODE3\SQLAG durch.
   2. Führen Sie ein Failover für AG1 von NODE2\SQLAG zurück auf NODE1\SQLAG durch.

Wenn in jeder Verfügbarkeitsgruppe ein drittes Replikat vorhanden ist, würden Sie es vor NODE3\SQLAG und nach NODE1\SQLAGaktualisieren.

Spezielle Schritte für Change Data Capture oder die Replikation

Je nach angewendeter Aktualisierung sind möglicherweise zusätzliche Schritte für AG-Replikatdatenbanken erforderlich, die für die Änderungsdatenerfassung oder Replikation aktiviert sind. Lesen Sie die Anmerkungen zu dieser Version des Updates, um zu bestimmen, ob folgende Schritte erforderlich sind:

1. Upgraden Sie jedes sekundäre Replikat.

2. Führen Sie ein Failover der Verfügbarkeitsgruppe auf eine upgegradete Instanz durch, nachdem alle sekundären Replikate upgegradet wurden.

3. Führen Sie folgenden Transact-SQL-Befehl auf der Instanz aus, die das primäre Replikat hostet:

   EXECUTE [master].[sys].[sp_vupgrade_replication];
   

   Hinweis

   Dieser Befehl kann mehrere Minuten dauern, bis er ausgeführt wird. Überspringen Sie diesen Schritt, wenn Sie mit SQL Server 2019 CU1 oder höher arbeiten. Weitere Informationen finden Sie unter KB4530283.

4. Führen Sie ein Upgrade für die Instanz aus, bei der es sich um das ursprüngliche primäre Replikat handelt.

Hintergrundinformationen finden Sie unter CDC-Funktionalität könnte nach einem Upgrade auf die neueste CU-Version beeinträchtigt sein.

Verwandte Inhalte

• Upgrade von SQL Server mithilfe des Installations-Assistenten (Setup)
• Installieren und Konfigurieren von SQL Server unter Windows über die Eingabeaufforderung