Microsoft SQL Server für die multiregionale Notfallwiederherstellung bereitstellen

Informationen zur Notfallwiederherstellung

Bei Google Cloud ist die Notfallwiederherstellung darauf ausgerichtet, die Kontinuität der Verarbeitung zu gewährleisten, insbesondere wenn eine Region ausfällt bzw. unzugänglich wird. Systeme wie ein Datenbankverwaltungssystem werden in mindestens zwei Regionen bereitstellt, um die Notfallwiederherstellung zu implementieren. Bei dieser Einrichtung funktioniert das System weiterhin, wenn eine der Regionen ausfällt.

Notfallwiederherstellung von Datenbanksystemen

Das Verfügbarmachen einer sekundären Datenbank bei einem Ausfall der primären Datenbankinstanz wird als Datenbank-Notfallwiederherstellung (oder Datenbank-DR) bezeichnet. Weitere Informationen zu diesem Konzept finden Sie unter Notfallwiederherstellung für Microsoft SQL Server. Wenn die primäre Datenbank ausfällt, sollte der Zustand der sekundären Datenbank idealerweise dem Zustand der primären Datenbank entsprechen, oder der sekundären Datenbank sollte nur ein kleiner Satz der letzten Transaktionen aus der primären Datenbank fehlen.

Notfallwiederherstellungsarchitektur

Das folgende Diagramm zeigt für Microsoft SQL Server eine minimale Architektur, die die Datenbank-DR unterstützt.

Abbildung 1. Standardarchitektur für die Notfallwiederherstellung mit Microsoft SQL Server.

Diese Architektur funktioniert folgendermaßen:

• Zwei Instanzen von Microsoft SQL Server (eine primäre Instanz und eine Standby-Instanz) befinden sich in derselben Region (R1), aber in verschiedenen Zonen (Zonen A und B). Die beiden Instanzen in R1 koordinieren ihren Zustand mit dem synchronen Commit-Modus. Der synchrone Modus wird verwendet, da er Hochverfügbarkeit unterstützt und einen konsistenten Datenzustand beibehält.
• Eine Instanz von Microsoft SQL Server (die sekundäre oder die Notfallwiederherstellungsinstanz) befindet sich in einer zweiten Region (R2). Für die Notfallwiederherstellung wird die sekundäre Instanz in R2 mit der primären Instanz in R1 synchronisiert. Dazu wird der asynchrone Commit-Modus verwendet. Der asynchrone Modus wird aufgrund seiner Leistung verwendet. Die Commit-Verarbeitung in der primären Instanz wird dadurch nicht verlangsamt.

Im gezeigten Diagramm stellt die Architektur eine Verfügbarkeitsgruppe dar. Bei Verwendung mit einem Listener stellt die Verfügbarkeitsgruppe den Clients denselben Verbindungsstring bereit, wenn die Clients durch Folgendes bereitgestellt werden:

• Primäre Instanz
• Standby-Instanz (nach einem Zonenausfall)
• Sekundäre Instanz (nach einem Ausfall der Region und nachdem die sekundäre Instanz zur neuen primären Instanz geworden ist)

In einer Variante der obigen Architektur stellen Sie die beiden Instanzen in der ersten Region (R1) in derselben Zone bereit. Dieser Ansatz kann die Leistung verbessern, ist aber nicht hochverfügbar. Ein einzelner Zonenausfall ist möglicherweise erforderlich, um den DR-Prozess zu initiieren.

Grundlegender Notfallwiederherstellungsprozess

Der DR-Prozess wird gestartet, wenn eine Region ausfällt und die primäre Datenbank den Vorgang in einer anderen Betriebsregion fortsetzt. Der DR-Prozess schreibt die erforderlichen Betriebsschritte vor, die entweder manuell oder automatisch ausgeführt werden müssen, um dem Ausfall einer Region entgegenzuwirken und eine ausgeführte primäre Instanz in einer verfügbaren Region einzurichten.

Ein grundlegender DR-Prozess für die Datenbank besteht aus den folgenden Schritten:

1. Die erste Region (R1), die die primäre Datenbankinstanz ausführt, fällt aus.
2. Das operative Team erkennt und bestätigt offiziell den Notfall und entscheidet, ob ein Failover erforderlich ist.
3. Wenn ein Failover erforderlich ist, wird die sekundäre Datenbankinstanz in der zweiten Region (R2) zur neuen primären Instanz.
4. Clients setzen die Verarbeitung in der neuen primären Datenbank fort und greifen auf die primäre Instanz in R2 zu.

Dieser grundlegende Prozess richtet zwar eine funktionierende primäre Datenbank neu ein, doch wird keine vollständige DR-Architektur aufgebaut, in der die neue primäre Datenbank eine Standby- und eine sekundäre Datenbankinstanz hat.

Vollständiger Notfallwiederherstellungsprozess

Ein vollständiger DR-Prozess ergänzt den grundlegenden DR-Prozess durch Schritte, mit denen eine vollständige DR-Architektur nach einem Failover eingerichtet wird. Das folgende Diagramm zeigt eine vollständige Datenbank-DR-Architektur.

Abbildung 2. Notfallwiederherstellung bei dem Ausfall einer primären Region (R1).

Diese vollständige Datenbank-DR-Architektur funktioniert so:

1. Die erste Region (R1), die die primäre Datenbankinstanz ausführt, fällt aus.
2. Das operative Team erkennt und bestätigt offiziell den Notfall und entscheidet, ob ein Failover erforderlich ist.
3. Wenn ein Failover erforderlich ist, wird die sekundäre Datenbankinstanz in der zweiten Region (R2) als primäre Instanz festgelegt.
4. Eine weitere sekundäre Instanz, die neue Standby-Instanz, wird in R2 erstellt und gestartet und zur primären Instanz hinzugefügt. Die Standby-Instanz befindet sich in einer anderen Zone als die primäre Instanz. Die primäre Datenbank besteht nun aus zwei hochverfügbaren Instanzen (primäre Instanz und Standby-Instanz).
5. In einer dritten Region (R3) wird eine neue sekundäre (Standby-Datenbankinstanz) erstellt und gestartet. Diese sekundäre Instanz ist asynchron mit der neuen primären Instanz in R2 verbunden. Die ursprüngliche Notfallwiederherstellungsarchitektur wird an diesem Punkt neu erstellt und ist verwendungsbereit.

Fallback zu einer wiederhergestellten Region

Sobald die erste Region (R1) wieder online ist, kann sie die neue sekundäre Datenbank hosten. Wenn R1 früh genug verfügbar ist, können Sie Schritt 5 im vollständigen Wiederherstellungsprozess in R1 statt in R3 (die dritte Region) implementieren. In diesem Fall ist keine dritte Region erforderlich.

Das folgende Diagramm zeigt die Architektur, wenn R1 rechtzeitig verfügbar wird.

Abbildung 3. Die Notfallwiederherstellung wird nach einem Ausfall der Region R1 wieder verfügbar.

In dieser Architektur sind die Wiederherstellungsschritte identisch mit denen, die weiter oben unter Vollständiger Notfallwiederherstellungsprozess beschrieben sind. Der einzige Unterschied besteht darin, dass R1 statt R3 zum Standort für die sekundären Instanzen wird.

SQL Server-Version auswählen

In dieser Anleitung werden die folgenden Versionen von Microsoft SQL Server unterstützt:

• SQL Server 2016 Enterprise Edition
• SQL Server 2017 Enterprise Edition
• SQL Server 2019 Enterprise Edition
• SQL Server Enterprise Edition 2022

In dieser Anleitung wird die Option "AlwaysOn Verfügbarkeitsgruppen" in SQL Server verwendet.

Wenn Sie keine primäre Microsoft SQL Server-Datenbank mit Hochverfügbarkeit (High Availability, HA) benötigen und eine einzelne Datenbankinstanz als primäre Datenbankdatenbank erforderlich ist, können Sie die folgenden SQL Server-Versionen verwenden:

• SQL Server 2016 Standard Edition
• SQL Server 2017 Standard Edition
• SQL Server 2019 Standard Edition
• SQL Server Standard Edition 2022

Bei den Versionen 2016, 2017 und 2019 und 2022 von SQL Server ist Microsoft SQL Server Management Studio im Image installiert. Sie müssen das Programm nicht separat installieren. In einer Produktionsumgebung empfehlen wir jedoch, in jeder Region eine Instanz von Microsoft SQL Server Management Studio auf einer separaten VM zu installieren. Wenn Sie eine HA-Umgebung einrichten, sollten Sie Microsoft SQL Server Management Studio für jede Zone einmal installieren. So ist sichergestellt, dass die Instanz auch dann verfügbar bleibt, wenn eine andere Zone ausfällt.

Microsoft SQL Server für multiregionale Notfallwiederherstellung einrichten

In diesem Abschnitt werden die folgenden Images für Microsoft SQL Server verwendet:

• sql-ent-2016-win-2016 für Microsoft SQL Server 2016 Enterprise Edition
• sql-ent-2017-win-2016 für Microsoft SQL Server 2017 Enterprise Edition
• sql-ent-2019-win-2019 für Microsoft SQL Server 2019 Enterprise Edition
• sql-ent-2022-win-2022 für Microsoft SQL Server 2022 Enterprise Edition

Eine vollständige Liste der Images finden Sie unter Images.

Hochverfügbarkeits-Cluster mit zwei Instanzen einrichten

Um eine multiregionale Datenbank-DR-Architektur für SQL Server einzurichten, müssen Sie zuerst einen HA-Cluster mit zwei Instanzen in einer Region erstellen. Eine Instanz dient als primäre und die andere als sekundäre Instanz. Folgen Sie der Anleitung unter Always On-Verfügbarkeitsgruppen von SQL Server konfigurieren, um diesen Schritt auszuführen. In dieser Anleitung wird us-central1 für die primäre Region (mit der Bezeichnung R1) verwendet. Lesen Sie zuerst die folgenden Hinweise:

• Wenn Sie die Schritte unter SQL Server Always On-Verfügbarkeitsgruppen konfigurieren ausgeführt haben, haben Sie zwei SQL Server-Instanzen in derselben Region (us-central1) erstellt. Sie haben die primäre SQL Server-Instanz (node-1) in us-central1-a und eine Standby-Instanz (node-2) in us-central1-b bereitgestellt.

• Obwohl Sie die Architektur in Abbildung 4 für diese Anleitung implementieren, gilt es als Best Practice, einen Domaincontroller in mehreren Zonen einzurichten. Dieser Ansatz gewährleistet, dass eine HA- und DR-fähige Datenbankarchitektur eingerichtet wird. Wenn z. B. ein Ausfall in einer bestimmt Zone auftritt, wird diese Zone nicht als Single Point of Failure für die bereitgestellte Architektur angelegt.

Abbildung 4. In dieser Anleitung implementierte Standardarchitektur zur Notfallwiederherstellung.

Sekundäre Instanz für die Notfallwiederherstellung hinzufügen

Als Nächstes richten Sie eine dritte SQL Server-Instanz (eine sekundäre Instanz mit dem Namen node-3) ein und konfigurieren das Netzwerk so:

1. Erstellen Sie ein Spezialisierungsskript für die Windows Server-Failover-Clusterknoten. Das Skript installiert das erforderliche Windows-Feature und erstellt Firewallregeln für WSFC und SQL Server. Außerdem formatiert er das Datenlaufwerk und erstellt Daten- und Protokollordner für SQL Server:

   cat << "EOF" > specialize-node.ps1
   
   $ErrorActionPreference = "stop"
   
   # Install required Windows features
   Install-WindowsFeature Failover-Clustering -IncludeManagementTools
   Install-WindowsFeature RSAT-AD-PowerShell
   
   # Open firewall for WSFC
   netsh advfirewall firewall add rule name="Allow SQL Server health check" dir=in action=allow protocol=TCP localport=59997
   
   # Open firewall for SQL Server
   netsh advfirewall firewall add rule name="Allow SQL Server" dir=in action=allow protocol=TCP localport=1433
   
   # Open firewall for SQL Server replication
   netsh advfirewall firewall add rule name="Allow SQL Server replication" dir=in action=allow protocol=TCP localport=5022
   
   # Format data disk
   Get-Disk |
    Where partitionstyle -eq 'RAW' |
    Initialize-Disk -PartitionStyle MBR -PassThru |
    New-Partition -AssignDriveLetter -UseMaximumSize |
    Format-Volume -FileSystem NTFS -NewFileSystemLabel 'Data' -Confirm:$false
   
   # Create data and log folders for SQL Server
   md d:\Data
   md d:\Logs
   EOF
   

2. Initialisieren Sie die folgenden Variablen:

   VPC_NAME=VPC_NAME
   SUBNET_NAME=SUBNET_NAME
   REGION=us-east1
   PD_SIZE=200
   MACHINE_TYPE=n2-standard-8
   

   Dabei gilt:

   • VPC_NAME: Der Name Ihrer VPC
   • SUBNET_NAME: Name Ihres Subnetzes für die Region us-east1

3. Erstellen Sie eine SQL Server-Instanz:

   gcloud compute instances create node-3 \
   --zone $REGION-b \
   --machine-type $MACHINE_TYPE \
   --subnet $SUBNET_NAME \
   --image-family sql-ent-2022-win-2022 \
   --image-project windows-sql-cloud \
   --tags wsfc,wsfc-node \
   --boot-disk-size 50 \
   --boot-disk-type pd-ssd \
   --boot-disk-device-name "node-3" \
   --create-disk=name=node-3-datadisk,size=$PD_SIZE,type=pd-ssd,auto-delete=no \
   --metadata enable-wsfc=true \
   --metadata-from-file=sysprep-specialize-script-ps1=specialize-node.ps1
   

4. Legen Sie ein Windows-Passwort für die neue SQL Server-Instanz fest:

   1. Rufen Sie in der Google Cloud Console die Seite „Compute Engine“ auf.

      Zu Compute Engine

   2. Wählen Sie in der Spalte Verbinden für den Compute Engine-Cluster node-3 die Drop-down-Liste Windows-Passwort festlegen aus.

   3. Legen Sie den Nutzernamen und das Passwort fest. Notieren Sie sie zur späteren Verwendung.

5. Klicken Sie auf RDP, um eine Verbindung zur Instanz node-3 herzustellen.

6. Geben Sie den Nutzernamen und das Passwort aus dem vorherigen Schritt ein und klicken Sie auf OK.

7. Fügen Sie die Instanz der Windows-Domain hinzu:

   1. Klicken Sie mit der rechten Maustaste auf Start (oder drücken Sie Win + X) und klicken Sie anschließend auf Windows PowerShell (Administrator).

   2. Bestätigen Sie die Eingabeaufforderung für erhöhte Rechte durch Klicken auf Ja.

   3. Verbinden Sie den Computer mit Ihrer Active Directory-Domain und starten Sie ihn neu:

      Add-Computer -Domain DOMAIN -Restart
      

      Ersetzen Sie DOMAIN durch den DNS-Namen Ihrer Active Directory-Domain.

      Warten Sie etwa eine Minute, bis der Neustart abgeschlossen ist.

Sekundäre Instanz zum Failover-Cluster hinzufügen

Als Nächstes fügen Sie die sekundäre Instanz (node-3) dem Windows-Failovercluster hinzu:

1. Stellen Sie die Verbindung zu den Instanzen node-1 oder node-2 über RDP her und melden Sie sich als Administrator an.

2. Öffnen Sie ein PowerShell-Fenster als Administrator und legen Sie Variablen für die Clusterumgebung in dieser Anleitung fest:

   $node3 = "node-3"
   $nameWSFC = "SQLSRV_CLUSTER" # Name of cluster 
   

   Ersetzen Sie SQLSRV_CLUSTER durch den Namen des SQL Server-Clusters.

3. Fügen Sie dem Cluster die sekundäre Instanz hinzu:

   Get-Cluster | WHERE Name -EQ $nameWSFC | Add-ClusterNode -NoStorage -Name $node3
   

   Die Ausführung dieses Befehls kann eine Weile dauern. Da es vorkommen kann, dass der Prozess nicht mehr automatisch antwortet und nicht automatisch zurückgegeben werden kann, drücken Sie gelegentlich Enter.

4. Aktivieren Sie im Knoten die Option "AlwaysOn Hochverfügbarkeit":

   Enable-SqlAlwaysOn -ServerInstance $node3 -Force
   

Der Knoten ist jetzt Teil des Failover-Clusters.

Sekundäre Instanz zur vorhandenen Verfügbarkeitsgruppe hinzufügen

Als Nächstes fügen Sie der Verfügbarkeitsgruppe die SQL Server-Instanz (die sekundäre Instanz) und die Datenbank hinzu:

1. Stellen Sie mithilfe von Remote Desktop eine Verbindung zu node-3 her. Melden Sie sich mit Ihrem Domainnutzerkonto an.

2. Öffnen Sie den SQL Server-Konfigurations-Manager.

3. Wählen Sie im Navigationsbereich die Option SQL Server-Dienste aus.

4. Klicken Sie in der Liste der Dienste mit der rechten Maustaste auf SQL Server (MSSQLSERVER) und wählen Sie Eigenschaften.

5. Ändern Sie unter Anmeldung als das Konto:

   • Kontoname: DOMAIN\sql_server, wobei DOMAIN der NetBIOS-Name Ihrer Active Directory-Domain ist.
   • Passwort: Geben Sie das Passwort ein, das Sie zuvor für das Domainkonto „sql_server“ ausgewählt haben.

6. Klicken Sie auf OK.

7. Wenn Sie aufgefordert werden, SQL Server neu zu starten, wählen Sie Ja.

8. Öffnen Sie in einem der drei Instanzknoten (node-1, node-2 oder node-3) Microsoft SQL Server Management Studio und stellen Sie eine Verbindung zur primären Instanz (node-1) her.

   1. Wechseln Sie zum Object Explorer.
   2. Wählen Sie die Drop-down-Liste Verbinden aus.
   3. Wählen Sie Datenbank-Engine aus.
   4. Wählen Sie in der Drop-down-Liste Servername die Option node-1 aus. Wenn der Cluster nicht aufgeführt ist, geben Sie ihn in das Feld ein.

9. Klicken Sie auf Neue Abfrage.

10. Fügen Sie den folgenden Befehl ein, um dem Listener, der für den Knoten verwendet wird, eine IP-Adresse hinzuzufügen. Klicken Sie dann auf Ausführen:

    ALTER AVAILABILITY GROUP [bookshelf-ag] MODIFY LISTENER 'bookshelf' (ADD IP ('LOAD_BALANCER_IP_ADDRESS', '255.255.255.0'))
    

    Ersetzen Sie LOAD_BALANCER_IP_ADDRESS durch die IP-Adresse des Load Balancers in der Region us-east1.

11. Erweitern Sie im Object Explorer den Knoten AlwaysOn Hohe Verfügbarkeit und maximieren Sie den Knoten Verfügbarkeitsgruppen.

12. Klicken Sie mit der rechten Maustaste auf die Verfügbarkeitsgruppe bookshelf-ag und wählen Sie Replikat hinzufügen aus.

13. Klicken Sie auf der Seite Einführung auf den Knoten AlwaysOn Hohe Verfügbarkeit und dann auf den Knoten Verfügbarkeitsgruppen.

14. Klicken Sie auf der Seite Mit Replikaten verbinden auf Verbinden, um eine Verbindung zum vorhandenen sekundären Replikat node-2 herzustellen.

15. Klicken Sie auf der Seite Replikate angeben auf Replikat hinzufügen und fügen Sie dann den neuen Knoten node-3 hinzu. Wählen Sie Automatisches Failover nicht aus, da automatisches Failover zu einem synchronen Commit führt. Eine solche Einrichtung erstreckt sich über regionale Grenzen, die wir nicht empfehlen.

16. Wählen Sie auf der Seite Datensynchronisierung auswählen die Option Automatisches Seeding aus.

    Da es keinen Listener gibt, wird auf der Seite Validierung eine Warnung angezeigt, die Sie ignorieren können.

17. Führen Sie die Schritte des Assistenten aus.

Der Failover-Modus für node-1 und node-2 ist automatisch, für node-3 jedoch manuell. Hierin unterscheidet sich die Hochverfügbarkeit von der Notfallwiederherstellung.

Die Verfügbarkeitsgruppe ist jetzt bereit. Sie haben zwei Knoten für Hochverfügbarkeit und einen dritten Knoten für die Notfallwiederherstellung konfiguriert.

Eine Notfallwiederherstellung simulieren

In diesem Abschnitt testen Sie die DR-Architektur für diese Anleitung und ziehen optionale Implementierungen in Betracht.

Ausfall simulieren und ein DR-Failover ausführen

1. Simulieren Sie einen Fehler oder Ausfall in der primären Region:

   1. Stellen Sie in Microsoft SQL Server Management Studio auf node-1 eine Verbindung zu node-1 her.

   2. Eine Tabelle erstellen Nachdem Sie in späteren Schritten Replikate hinzugefügt haben, prüfen Sie, ob das Replikat funktioniert. Dafür muss diese Tabelle vorhanden sein.

      USE bookshelf
      GO
      CREATE TABLE dbo.TestTable_Before_DR (ID INT NOT NULL)
      GO
      

   3. Fahren Sie in Cloud Shell beide Server in der primären Region us-central1 herunter:

      gcloud compute instances stop node-2 --zone us-central1-b --quiet
      gcloud compute instances stop node-1 --zone us-central1-a --quiet
      

2. Stellen Sie in Microsoft SQL Server Management Studio auf node-3 eine Verbindung zu node-3 her.

3. Führen Sie ein Failover aus und legen Sie für den Verfügbarkeitsmodus ein synchrones Commit fest. Das Erzwingen eines Failovers ist erforderlich, da sich der Knoten im asynchronen Commit-Modus befindet.

   ALTER AVAILABILITY GROUP [bookshelf-ag] FORCE_FAILOVER_ALLOW_DATA_LOSS
   GO
   ALTER AVAILABILITY GROUP [bookshelf-ag]
   MODIFY REPLICA ON 'node-3' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
   GO
   

   Sie können die Verarbeitung fortsetzen, node-3 ist jetzt die primäre Instanz.

4. (Optional) Erstellen Sie eine neue Tabelle in node-3. Nachdem Sie die Replikate mit der neuen primären Instanz synchronisiert haben, prüfen Sie, ob diese Tabelle auf die Replikate repliziert wird.

   USE bookshelf
   GO
   CREATE TABLE dbo.TestTable_After_DR (ID INT NOT NULL)
   GO
   

Obwohl node-3 an diesem Punkt die primäre Instanz ist, sollten Sie ein Fallback auf die ursprüngliche Region ausführen oder eine neue sekundäre Instanz und eine Standby-Instanz einrichten, um eine vollständige DR-Architektur neu zu erstellen. Im nächsten Abschnitt werden diese Optionen erläutert.

(Optional) DR-Architektur neu erstellen, die Transaktionen vollständig repliziert

In diesem Anwendungsfall wird ein Ausfall beschrieben, bei dem alle Transaktionen von der primären in die sekundäre Datenbank repliziert werden, bevor die primäre Datenbank ausfällt. In diesem idealen Szenario gehen keine Daten verloren. Der Zustand der sekundären Datenbank ist zum Zeitpunkt des Ausfalls mit der primären Datenbank konsistent.

In diesem Szenario haben Sie zwei Möglichkeiten, eine vollständige DR-Architektur neu zu erstellen:

• Fallback auf die ursprüngliche primäre und die ursprüngliche Standby-Instanz (sofern diese verfügbar sind) ausführen.
• Neue Standby- und sekundäre Instanz für node-3 erstellen, falls die ursprüngliche primäre und die Standby-Instanz nicht verfügbar sind.

Ansatz 1: Fallback auf die ursprüngliche primäre und die Standby-Instanz ausführen

1. Starten Sie in Cloud Shell die ursprüngliche (alte) primäre Instanz und die Standby-Instanz:

   gcloud compute instances start node-1 --zone us-central1-a --quiet
   gcloud compute instances start node-2 --zone us-central1-b --quiet
   

2. Fügen Sie in Microsoft SQL Server Management Studio node-1 und node-2 wieder als sekundäre Replikate hinzu:

   1. Fügen Sie unter node-3 die beiden Server im asynchronen Commit-Modus hinzu:

      USE [master]
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-1' WITH (FAILOVER_MODE = MANUAL)
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-1' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-2' WITH (FAILOVER_MODE = MANUAL)
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-2' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      

   2. Starten Sie die Synchronisierung der Datenbanken unter node-1 noch einmal:

      USE [master]
      GO
      ALTER DATABASE [bookshelf] SET HADR RESUME;
      GO
      

   3. Starten Sie die Synchronisierung der Datenbanken unter node-2 noch einmal:

      USE [master]
      GO
      ALTER DATABASE [bookshelf] SET HADR RESUME;
      GO
      

3. Machen Sie node-1 wieder zur primären Version:

   1. Ändern Sie in node-3 den Verfügbarkeitsmodus von node-1 zu einem synchronen Commit. Die Instanz node-1 wird wieder zur primären Instanz.

      USE [master]
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-1' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
      GO
      

   2. Machen Sie node-1 in node-1 zur primären Instanz und die beiden anderen Knoten zu sekundären Instanzen:

      USE [master]
      GO
      -- Node 1 becomes primary
      ALTER AVAILABILITY GROUP [bookshelf-ag] FORCE_FAILOVER_ALLOW_DATA_LOSS;
      GO
      
      -- Node 2 has synchronous commit
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-2' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
      GO
      
      -- Node 3 has asynchronous commit
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-3' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      

Nachdem alle Befehle erfolgreich waren, ist node-1 die primäre Instanz und die anderen Knoten sind sekundäre Instanzen, wie das folgende Diagramm zeigt.

Ansatz 2: Neue primäre und Standby-Instanz einrichten

Es ist möglich, dass Sie die ursprünglichen primären und Standby-Instanzen nach dem Ausfall nicht wiederherstellen können, die Wiederherstellung zu lange dauert oder die Region nicht zugänglich ist. Ein möglicher Ansatz besteht darin, die primäre Datenbank node-3 beizubehalten und dann ein neues Standby und eine neue sekundäre Instanz zu erstellen, wie im folgenden Diagramm dargestellt.

Abbildung 5. Notfallwiederherstellung ohne verfügbare ursprüngliche primäre Region R1

Diese Implementierung erfordert folgende Schritte:

• Behalten Sie node-3 als primäre Domain in us-east1 bei.

• Fügen Sie eine neue Standby-Instanz (node-4) zu einer anderen Zone in us-east1 hinzu. Dadurch wird die neue Bereitstellung hochverfügbar.

• Erstellen Sie eine neue sekundäre Instanz (node-5) in einer separaten Region, z. B. us-west2. Mit diesem Schritt wird die neue Bereitstellung für die Notfallwiederherstellung eingerichtet. Die allgemeine Bereitstellung ist nun abgeschlossen. Die Datenbankarchitektur unterstützt HA und DR vollständig.

Optional: Fallback ausführen, wenn Transaktionen fehlen

Ein weniger ideales Szenario ist, wenn eine oder mehrere auf der primären Instanz zugesicherten Transaktionen nicht zum Zeitpunkt des Ausfalls auf die sekundäre Instanz repliziert werden. Dieser Vorgang wird auch als harter Ausfall bezeichnet. Bei einem Failover gehen alle zugesicherten Transaktionen verloren, die nicht repliziert werden.

Um die Failover-Schritte für dieses Szenario zu testen, müssen Sie einen harten Ausfall erzeugen. Der beste Ansatz zum Erzeugen eines harten Ausfalls lautet:

• Ändern Sie das Netzwerk so, dass keine Verbindung zwischen der primären Instanz und den sekundären Instanzen besteht.
• Ändern Sie die primäre Instanz auf irgendeine Weise, z. B. durch Hinzufügen von Daten oder einer Tabelle.
• Führen Sie den Failover-Prozess wie zuvor beschrieben aus, damit die sekundäre Instanz zur neuen primären Instanz wird.

Die Schritte für den Failover-Prozess sind mit dem idealen Szenario identisch. Der einzige Unterschied besteht darin, dass die Tabelle, die der primären Datenbank hinzugefügt wird, nachdem die Netzwerkverbindung unterbrochen wurde, in der sekundären Instanz nicht sichtbar ist.

Ihre einzige Option für einen harten Ausfall ist das Entfernen der Replikate (node-1 und node-2) aus der Verfügbarkeitsgruppe und das erneute Synchronisieren der Replikate. Mit der Synchronisierung wird der Zustand entsprechend der sekundären Instanz geändert. Jede Transaktion, die vor dem Ausfall nicht repliziert wurde, geht verloren.

Wenn Sie node-1 als sekundäre Instanz hinzufügen möchten, können Sie dieselben Schritte befolgen, die Sie oben zum Hinzufügen von node-3 ausgeführt haben (siehe Sekundäre Instanz zum Failover-Cluster hinzufügen). Es gibt jedoch folgenden Unterschied: node-3 ist jetzt die primäre Instanz, nicht node-1. Ersetzen Sie alle Instanzen von node-3 durch den Namen des Servers, den Sie der Verfügbarkeitsgruppe hinzufügen. Wenn Sie dieselbe VM (node-1 und node-2) wiederverwenden, müssen Sie den Server nicht zum Windows Server-Failover-Cluster hinzufügen. Fügen Sie lediglich die SQL Server-Instanz wieder zur Verfügbarkeitsgruppe hinzu.

An diesem Punkt ist node-3 die primäre Instanz und node-1 und node-2 sind sekundäre Instanzen. Es ist jetzt möglich, ein Fallback auf node-1 auszuführen, um node-2 zur Standby-Instanz und node-3 zur sekundären Instanz zu machen. Das System hat jetzt denselben Zustand wie vor dem Fehler.

Automatische Ausfallsicherung

Ein automatisches Failover auf eine sekundäre Instanz ist nicht möglich, da die primäre Instanz zu Problemen führen kann. Sobald die ursprüngliche primäre Datenbank wieder verfügbar ist, kann eine Split-Brain-Situation auftreten, wenn einige Clients auf die sekundäre Instanz zugreifen, während andere in die wiederhergestellte primäre Instanz schreiben. In diesem Fall könnten die primäre und die sekundäre Instanz gleichzeitig aktualisiert werden, wodurch ihr Zustand voneinander abweichen würde. Um dies zu vermeiden, finden Sie in dieser Anleitung Schritte für ein manuelles Failover, bei dem Sie entscheiden, ob (oder wann) ein Failover erfolgt.

Wenn Sie ein automatisches Failover implementieren, müssen Sie dafür sorgen, dass nur eine der konfigurierten Instanzen die primäre Instanz ist und geändert werden kann. Eine Standby- oder sekundäre Instanz darf keinem Client (außer der primären Instanz für die Zustandsreplikation) Schreibzugriff gewähren. Darüber hinaus müssen Sie eine schnelle Kette von aufeinander folgenden Failovers vermeiden. Beispielsweise wäre ein Failover alle fünf Minuten keine zuverlässige Strategie zur Notfallwiederherstellung. Bei automatisierten Failover-Prozessen können Sie Maßnahmen gegen problematische Szenarien wie diese treffen. Sie können bei Bedarf auch einen Datenbankadministrator für komplexe Entscheidungen einbeziehen.

Alternative Bereitstellungsarchitektur

In dieser Anleitung wird eine Architektur zur Notfallwiederherstellung mit einer sekundären Instanz eingerichtet, die in einem Failover zur primären Instanz wird, wie im folgenden Diagramm dargestellt.

Abbildung 6. Standardarchitektur für die Notfallwiederherstellung mit Microsoft SQL Server.

Dies bedeutet, dass bei einem Failover eine einzelne Instanz so lange vorhanden ist, bis ein Fallback möglich ist, oder bis Sie eine Standby-Instanz (für HA) und eine sekundäre Instanz (für DR) konfigurieren.

Eine alternative Bereitstellungsarchitektur besteht darin, zwei sekundäre Instanzen zu konfigurieren. Beide Instanzen sind Replikate der primären Instanz. Wenn ein Failover auftritt, können Sie eine der sekundären Instanzen als Standby neu konfigurieren. Die folgenden Diagramme zeigen die Bereitstellungsarchitektur vor und nach einem Failover.

Abbildung 7. Standardarchitektur der Notfallwiederherstellung mit zwei sekundären Instanzen.

Abbildung 8. Standardarchitektur für die Notfallwiederherstellung mit zwei sekundären Instanzen nach dem Failover.

Sie müssen zwar trotzdem eine der beiden sekundären Instanzen als Standby-Instanz festlegen (Abbildung 8), dieser Prozess ist jedoch deutlich schneller als das Erstellen und Konfigurieren einer neuen Standby-Instanz.

Sie können die Notfallwiederherstellung auch mit einer Einrichtung erreichen, die dieser Architektur mit zwei sekundären Instanzen entspricht. Zusätzlich zu den zwei sekundären Instanzen in einer zweiten Region (Abbildung 7) können Sie weitere sekundäre Instanzen in einer dritten Region bereitstellen. Mit dieser Konfiguration können Sie eine HA- und DR-fähige Bereitstellungsarchitektur nach einem Ausfall der primären Region effizient erstellen.