Upgrade und Aktualisierung von Verfügbarkeitsgruppenservern mit minimaler Ausfallzeit und Datenverlust

Beim Aktualisieren oder Upgraden von Serverinstanzen von SQL Server 2012 zu einem Service Pack oder einer neueren Version können Sie die Ausfallzeiten für eine Verfügbarkeitsgruppe auf nur ein manuelles Failover reduzieren, indem Sie eine schrittweise Aktualisierung oder ein Upgrade durchführen. Für das Upgrade von SQL Server-Versionen wird es als rollierendes Upgrade bezeichnet. zum Aktualisieren der aktuellen SQL Server-Version mit Hotfixes oder Service Packs wird sie als rollierendes Update bezeichnet.

In diesem Thema wird die Diskussion nur auf SQL Server-Upgrades/-Updates beschränkt. Weitere Informationen zu betriebssystembezogenen Upgrades/Updates, die auf hochverfügbaren SQL Server-Instanzen laufen, finden Sie unter Clustermigration von AlwaysOn-Verfügbarkeitsgruppen für Betriebssystemupgrades.

Bewährte Methoden für das Rollupgrade/Update für AlwaysOn-Verfügbarkeitsgruppen

Die folgenden bewährten Methoden sollten beim Ausführen von Serverupgrades/Updates beachtet werden, um Ausfallzeiten und Datenverluste für Ihre Verfügbarkeitsgruppen zu minimieren:

• Bevor Sie das rollierende Upgrade/Update starten,

  • Führen Sie eine Übungsanweisung für ein manuelles Failover an mindestens einem Ihrer synchronen Commit-Replikate durch.

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

  • Ausführen von DBCC CHECKDB für jede Verfügbarkeitsdatenbank

• Aktualisieren Sie immer zuerst die sekundären Remotereplikaknoten, anschließend die lokalen sekundären Replikaknoten und zuletzt den primären Replikaknoten.

• Sicherungen können nicht in einer Datenbank ausgeführt werden, die gerade aktualisiert wird. 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. Ändern Sie diese Einstellung vor dem Upgrade des primären Replikats so, dass Sicherungen nur auf den sekundären Replikaten ausgeführt werden.

• Um zu verhindern, dass die Verfügbarkeitsgruppe während des Upgrade- oder Updateprozesses unbeabsichtigte Failovers erleidet, entfernen Sie das Verfügbarkeitsfailover aus allen synchronen Commit-Replikaten, bevor Sie beginnen.

• Aktualisieren Sie den primären Replikatknoten nicht, bevor Sie die Verfügbarkeitsgruppe zuerst auf einen aktualisierten Knoten mit einem sekundären Replikat umschalten. Andernfalls können Clientanwendungen während des Upgrades/Updates des primären Replikats längere Ausfallzeiten erleiden.

• Führen Sie immer einen Failover der Verfügbarkeitsgruppe zu einem Replikatknoten mit synchronem Commit durch. Wenn Sie zu einem asynchronen Commit-sekundären Replikat übergehen, kommt es zu Datenverlust bei den Datenbanken, und die Datenbewegung wird automatisch angehalten, bis Sie die Datenbewegung manuell fortsetzen.

• Aktualisieren oder upgraden Sie den primären Replikatknoten nicht, bevor Sie andere sekundäre Replikatknoten aktualisieren oder upgraden. Ein aktualisiertes primäres Replikat kann keine Protokolle mehr an jedes sekundäre Replikat senden, das noch nicht auf dieselbe 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.

• Bevor Sie zu einer anderen Verfügbarkeitsgruppe wechseln, überprüfen Sie, dass der Synchronisierungsstatus des Failoverziels SYNCHRONISIERT ist.

Rollender Upgrade-/Update-Prozess

In der Praxis hängt der genaue Prozess von Faktoren wie der Bereitstellungstopologie Ihrer Verfügbarkeitsgruppen und dem Commit-Modus der einzelnen Replikate ab. Im einfachsten Szenario ist ein rollierendes Upgrade/Update 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 oder Aufrüsten aller Remoteserverinstanzen mit sekundären Replikas, die asynchrones Commit verwenden.

3. Aktualisieren/Upgraden aller lokalen Serverinstanzen, die derzeit nicht das primäre Replikat ausführen

4. Manuelles Übernehmen der Verfügbarkeitsgruppe auf ein sekundäres Replikat mit synchronem Commit

5. Aktualisieren oder Ausführen eines Upgrades der Serverinstanz, die zuvor die primäre Replikatsinstanz gehostet hat.

6. Konfigurieren von automatischen Failoverpartnern nach Bedarf

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

Verfügbarkeitsgruppe mit einem einzelnen sekundären Remotereplikat

Wenn Sie eine Verfügbarkeitsgruppe nur für die Notfallwiederherstellung bereitgestellt haben, müssen Sie möglicherweise auf eine sekundäre Replik im asynchronen Commit-Modus umschalten. Diese Konfiguration wird in der folgenden Abbildung dargestellt:

In diesem Fall müssen Sie die Verfügbarkeitsgruppe während des rollierenden Upgrades/Updates auf das sekundäre Replikat mit asynchronem Commit umschalten. Um Datenverluste zu verhindern, ändern Sie den Commitmodus in synchronen Commit, und warten Sie, bis das sekundäre Replikat synchronisiert wird, bevor Sie die Verfügbarkeitsgruppe übergehen. Daher kann der rollierende Upgrade-/Updateprozess wie folgt aussehen:

1. Upgrade/Aktualisieren des Remoteservers

2. Ändern des Commitmodus in den synchronen Commitmodus

3. Warten Sie, bis der Synchronisierungszustand auf SYNCHRONISIERT steht.

4. Übernahme der Verfügbarkeitsgruppe an den Remotestandort

5. Aktualisierung/Upgrade des lokalen Servers (primärer Standort)

6. Verfügbarkeitsgruppe an den primären Standort wechseln.

7. Ändern des Commitmodus in den asynchronen Commitmodus

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 bewirkt das Ausführen eines Failovers, dass alle nicht bekannten Protokollnachrichten verworfen werden. Die Menge der verworfenen Protokollnachrichten kann aufgrund der hohen Netzwerklatenz zwischen den beiden Standorten ziemlich groß sein, was dazu führt, dass Clients ein hohes Volumen von Transaktionsfehlern verursachen. Sie können die Auswirkungen auf Clientanwendungen minimieren, indem Sie die folgenden Schritte ausführen:

• Festlegen des Wartungsfensters auf Zeiten mit geringem Clientdatenverkehr

• Ändern Sie beim Upgrade/Aktualisieren von SQL Server am primären Standort den Verfügbarkeitsmodus auf asynchronen Commit und wechseln Sie wieder auf synchronen Commit, wenn Sie bereit sind, zum primären Standort zurückzukehren.

Verfügbarkeitsgruppe mit Failoverclusterinstanzknoten

Wenn eine Verfügbarkeitsgruppe Failoverclusterinstanz (FCI)-Knoten enthält, sollten Sie die inaktiven Knoten aktualisieren, bevor Sie die aktiven Knoten aktualisieren. Die folgende Abbildung veranschaulicht ein typisches Szenario für Verfügbarkeitsgruppen mit FCIs für lokale Hochverfügbarkeit und den asynchronen Commit zwischen den FCIs für die Remote-Notfallwiederherstellung sowie die Upgradesequenz.

1. REMOTE2 aktualisieren

2. Umschalten von FCI2 auf REMOTE2

3. Upgrade/Update-REMOTE1

4. Upgrade/Update-PRIMARY2

5. FCI1 auf PRIMARY2 umschalten.

6. Upgrade bzw. Update PRIMARY1

Upgrade/Aktualisieren von SQL Server-Instanzen mit mehreren Verfügbarkeitsgruppen

Wenn Sie mehrere Verfügbarkeitsgruppen mit primären Replikaten auf separaten Serverknoten (eine Active/Active-Konfiguration) ausführen, umfasst der Upgrade-/Updatepfad weitere Failoverschritte, um hohe Verfügbarkeit im Prozess beizubehalten. Angenommen, Sie führen drei Verfügbarkeitsgruppen auf drei Serverknoten aus, wie in der folgenden Tabelle dargestellt, und alle sekundären Replikate werden im synchronen Commit-Modus ausgeführt.

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

1. Schalte AG2 auf Node3 um (um Node2 freizugeben)

2. Upgrade/update Node2

3. Fail over AG1 to Node2 (to free up Node1)

4. Aktualisierung/Upgrade von Node1

5. Schalten Sie sowohl AG2 als auch AG3 auf Node1 um, um Node3 freizugeben.

6. Upgrade/Aktualisierung von Node3

7. Failover von AG3 zu Node3

Diese Upgrade-/Updatesequenz hat eine durchschnittliche Ausfallzeit von weniger als zwei Failovern pro Verfügbarkeitsgruppe. Die resultierende Konfiguration wird in der folgenden Tabelle angezeigt.

Basierend auf Ihrer spezifischen Implementierung kann ihr Upgrade-/Updatepfad variieren, und die Ausfallzeiten, die die Clientanwendungen erleben, können ebenfalls variieren.