Upgrade von Verfügbarkeitsgruppenreplikaten

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ährend dieser Zeit wird es für keine dieser Datenbanken lesbare Replikate geben. Ausfallzeiten nach dem anfänglichen Failover hängen von der Anzahl der Datenbanken in der AG ab. Wenn Sie ein Failback auf die ursprüngliche primäre Instanz planen, 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 Sie, ob für Datenbanken in der AG die Datenerfassung für Änderungsdaten (CDC) oder Replikation verwendet werden: Wenn Datenbanken in der AG für die Datenerfassung für Änderungsdaten (CDC) aktiviert sind, befolgen Sie diese Anweisungen.

Grundlagen für rollierende Upgrades von Verfügbarkeitsgruppen

Beachten Sie die folgenden Richtlinien, wenn Sie Serverupgrades oder -updates durchführen, um Ausfallzeiten und Datenverlust für Ihre Verfügbarkeitsgruppen zu minimieren:

• Bevor Sie das parallele Upgrade starten:

  • Führen Sie für mindestens eine Ihrer Replikatinstanzen mit synchronem Commit testweise ein manuelles Failover durch.

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

  • Führen Sie DBCC CHECKDB für jede Verfügbarkeitsdatenbank aus.

• 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 nach dem Upgrade des lesbaren sekundären Replikats und bevor entweder ein Failover des primären Replikats auf ein aktualisiertes sekundäres Replikat erfolgt ist oder das primäre Replikat aktualisiert wurde, nicht gelesen werden.

• Um zu verhindern, dass die AG während des Upgradevorgangs unbeabsichtigte Failovervorgänge ausführt, entfernen Sie vor Beginn das automatische Failover von allen Replikaten mit synchronem Commit.

• Führen Sie kein Upgrade der primären Replikatinstanz durch, bevor Sie für die Verfügbarkeitsgruppe ein Failover auf eine aktualisierte Instanz mit sekundärem Replikat durchgeführt haben. Andernfalls kann es bei Clientanwendungen während eines Upgrades der primären Replikatinstanz zu längeren Ausfallzeiten kommen.

• Schalten Sie die AG immer auf eine sekundäre Replikatinstanz mit synchronem Commit um. 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 die Datenübertragung zu einem sekundären Replikat angehalten ist, kann für dieses Replikat kein automatisches Failover erfolgen, und Ihre Verfügbarkeitsdatenbanken sind für Datenverlust anfällig. Dies gilt auch während eines Rolling-Upgrades, bei dem Sie manuell ein Failover vom alten Primärknoten auf den neuen Primärknoten durchführen. 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 AG durchführen, vergewissern Sie sich, dass der Synchronisierungsstatus des Failoverziels SYNCHRONIZED ist.

  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. Dies führt zu einer vorübergehenden Unterbrechung Ihrer vorhandenen Verfügbarkeitsgruppen in der primären Rolle auf dem Server. 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 Rolling Upgrades

In der Praxis hängen die genauen Schritte 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. Aktualisieren Sie alle Instanzen sekundärer Replikate mit asynchronem Commit.
3. Alle Remoteinstanzen sekundärer Replikate mit synchronem Commit aktualisieren.
4. Aktualisieren Sie alle lokalen sekundären Replikatinstanzen mit synchronem Commit.
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 AG in ihre ursprüngliche Konfiguration zurückzuversetzen.

Durch das Upgrade eines synchronen Commit-Replikats und das Herunterfahren werden Transaktionen auf dem Primärserver nicht verzögert. Sobald die Verbindung mit dem sekundären Replikat unterbrochen ist, werden Transaktionen auf dem primären Replikat bestätigt, ohne darauf zu warten, dass die Protokolleinträge auf dem sekundären Replikat auf den Datenträger geschrieben 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. Eine aktualisierte primäre Replik kann keine Protokolle mehr an sekundäre Replikate mit niedrigerer Version senden, die Datenbewegung wird beendet, für diese Replik kann kein automatisches Failover erfolgen, und Ihre Verfügbarkeitsdatenbanken sind anfällig für Datenverlust. Nachdem Sie das alte Primäre aktualisiert haben, müssen Sie möglicherweise die Synchronisierung fortsetzen. Wir empfehlen, alle sekundären Replikate zu aktualisieren, bevor ein Failover auf ein Replikat mit der neuen Version durchgeführt wird. Auf diese Weise haben Sie die Möglichkeit, ein Failover durchzuführen, nachdem die Datenbank(n) auf das neue Format aktualisiert wurde.

AG 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 dieser Situation müssen Sie die AG während des rollierenden Upgrades auf das sekundäre Replikat mit asynchronem Commit umschalten. Um Datenverlust zu verhindern, ändern Sie den Commitmodus in den synchronen Commitmodus, und warten Sie, bis das sekundäre Replikat synchronisiert ist, bevor Sie ein Failover für die AG durchführen. Daher kann der rollierende Upgradeprozess wie folgt aussehen:

1. Aktualisieren Sie die sekundäre Replikatinstanz am Remotestandort.
2. Ändern Sie den Commit-Modus auf synchrones Commit.
3. Warten Sie, bis der Synchronisierungsstatus lautet SYNCHRONIZED.
4. Führen Sie ein Failover der AG auf das sekundäre Replikat am Remotestandort durch.
5. Führen Sie ein Upgrade oder eine Aktualisierung der lokalen (primärer Standort) Replikatinstanz durch.
6. Führen Sie ein Failover der AG zurück zum Primärstandort durch.
7. Ändern Sie den Commitmodus auf 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 Logmeldungen kann aufgrund der hohen Netzwerklatenz zwischen den beiden Standorten erheblich sein, wodurch bei Clients eine hohe Anzahl von Transaktionsfehlern auftritt. Sie können die Auswirkungen auf die Clientanwendungen mithilfe der folgenden Maßnahmen minimieren:

• Wählen Sie das Wartungsfenster sorgfältig so, dass es in eine Zeit mit geringem Client-Datenverkehr fällt.

• Wenn Sie SQL Server am primären Standort aktualisieren oder ein Upgrade durchführen, ändern Sie den Verfügbarkeitsmodus wieder in asynchrones Commit, und setzen Sie ihn dann wieder auf synchrones Commit zurück, wenn Sie bereit sind, erneut ein Failover zum primären Standort durchzuführen.

Verfügbarkeitsgruppe mit Knoten einer Failoverclusterinstanz

Wenn eine AG Knoten einer Failoverclusterinstanz (Failover Cluster Instance, FCI) enthält, sollten Sie die inaktiven Knoten aktualisieren, bevor Sie die aktiven Knoten aktualisieren. Die folgende Abbildung veranschaulicht ein gängiges Szenario für Verfügbarkeitsgruppen mit FCIs für lokale Hochverfügbarkeit und asynchronem Commit zwischen den FCIs für die standortübergreifende Notfallwiederherstellung sowie die Upgradeabfolge.

1. Upgrade oder Update REMOTE2
2. FCI2 auf REMOTE2 umschalten
3. Aktualisieren oder upgraden REMOTE1
4. Upgrade oder Aktualisierung PRIMARY2
5. FCI1 auf PRIMARY2 umschalten
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 AG2 auf Node3 (um Node2 freizugeben)
2. Upgraden oder Aktualisieren von Node2
3. Failover für AG1 auf Node2 ausführen (um Node1 freizugeben)
4. Upgraden oder Aktualisieren von Node1
5. Sowohl AG2 als auch AG3 auf Node1 umschalten (um Node3 freizugeben)
6. Upgraden oder Aktualisieren von Node3
7. Failover von AG3 auf Node3 durchführen

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 ein Failover für den Weiterleitungsserver aus, und aktualisieren Sie die letzte verbleibende Instanz der zweiten Verfügbarkeitsgruppe. Sobald alle anderen Replikate aktualisiert wurden, führen Sie ein Failover der globalen primären Datenbank durch und aktualisieren Sie die letzte verbleibende Instanz der ersten Verfügbarkeitsgruppe. 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 bei allen sekundären Replikaten der zweiten Verfügbarkeitsgruppe (die nachgelagerte) ein Upgrade durch, und starten Sie sie neu.
3. Aktualisieren Sie alle sekundären Replikate der ersten Verfügbarkeitsgruppe (der Upstreamgruppe), und starten Sie alle sekundären Replikate neu.
4. Führen Sie ein Failover des primären Weiterleitungsreplikats 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 dem Weiterleitungsserver 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 des globalen primären Replikats auf ein aktualisiertes sekundäres Replikat der ersten 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.

Beispiel für ein Diagramm zu einem fortlaufenden Upgrade einer verteilten Verfügbarkeitsgruppe

Die Schritte zum Upgrade der Instanzen in diesem Diagramm:

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. Aktualisieren Sie NODE2\SQLAG (Sekundärreplikat 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. Schalten Sie AG2 von NODE4\SQLAG zurück auf NODE3\SQLAG um.
   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 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