Konfigurieren verteilter Always On-Verfügbarkeitsgruppen

Verwenden Sie den folgenden Transact-SQL-Code, um Ihre verteilte Verfügbarkeitsgruppe mithilfe des automatischen Seedings zu erstellen:

CREATE AVAILABILITY GROUP [distributedAG]
   WITH (DISTRIBUTED)
   AVAILABILITY GROUP ON
      'ag1' WITH
      (
         LISTENER_URL = 'tcp://ag1-listener.contoso.com:5022',
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
         FAILOVER_MODE = MANUAL,
         SEEDING_MODE = AUTOMATIC
      ),
      'ag2' WITH
      (
         LISTENER_URL = 'tcp://ag2-listener.contoso.com:5022',
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
         FAILOVER_MODE = MANUAL,
         SEEDING_MODE = AUTOMATIC
      );
GO

Verwenden Sie den folgenden Transact-SQL-Code, um Ihre verteilte Verfügbarkeitsgruppe mithilfe des manuellen Seedings zu erstellen:

CREATE AVAILABILITY GROUP [distributedAG]
   WITH (DISTRIBUTED)
   AVAILABILITY GROUP ON
      'ag1' WITH
      (
         LISTENER_URL = 'tcp://ag1-listener.contoso.com:5022',
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
         FAILOVER_MODE = MANUAL,
         SEEDING_MODE = MANUAL
      ),
      'ag2' WITH
      (
         LISTENER_URL = 'tcp://ag2-listener.contoso.com:5022',
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
         FAILOVER_MODE = MANUAL,
         SEEDING_MODE = MANUAL
      );
GO

Verwenden Sie den folgenden Transact-SQL-Code, um Ihre verteilte Verfügbarkeitsgruppe mithilfe des automatischen Seedings zu verknüpfen:

ALTER AVAILABILITY GROUP [distributedAG]
   JOIN
   AVAILABILITY GROUP ON
      'ag1' WITH
      (
         LISTENER_URL = 'tcp://ag1-listener.contoso.com:5022',
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
         FAILOVER_MODE = MANUAL,
         SEEDING_MODE = AUTOMATIC
      ),
      'ag2' WITH
      (
         LISTENER_URL = 'tcp://ag2-listener.contoso.com:5022',
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
         FAILOVER_MODE = MANUAL,
         SEEDING_MODE = AUTOMATIC
      );
GO

Verwenden Sie den folgenden Transact-SQL-Code, um Ihre verteilte Verfügbarkeitsgruppe mithilfe des manuellen Seedings zu verknüpfen:

ALTER AVAILABILITY GROUP [distributedAG]
   JOIN
   AVAILABILITY GROUP ON
      'ag1' WITH
      (
         LISTENER_URL = 'tcp://ag1-listener.contoso.com:5022',
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
         FAILOVER_MODE = MANUAL,
         SEEDING_MODE = MANUAL
      ),
      'ag2' WITH
      (
         LISTENER_URL = 'tcp://ag2-listener.contoso.com:5022',
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
         FAILOVER_MODE = MANUAL,
         SEEDING_MODE = MANUAL
      );
GO

Wenn manuelles Seeding verwendet wird, um die Datenbank auf der weiterleitenden Instanz zu erstellen, führen Sie eine vollständige Sicherung und eine Transaktionsprotokollsicherung auf der globalen primären Instanz durch, und stellen Sie sie mit der Option „NORECOVERY“ auf der weiterleitenden Instanz wieder her. Zum Beispiel:

So sichern Sie auf der globalen Primärinstanz:

BACKUP DATABASE [db1]
    TO DISK = '<full backup location>'
    WITH FORMAT;

BACKUP LOG [db1]
    TO DISK = '<log backup location>'
    WITH FORMAT;

Auf dem Forwarder wiederherstellen:

RESTORE DATABASE [db1] FROM DISK = '<full backup location>'
    WITH NORECOVERY;

RESTORE LOG [db1] FROM DISK = '<log backup location>'
    WITH NORECOVERY;

Führen Sie anschließend das Folgende auf dem Forwarder aus:

ALTER DATABASE [db1]
    SET HADR AVAILABILITY GROUP = [distributedAG];

Auf SQL Server 2022 (16.x) und höher können Sie die REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT-Einstellung für eine verteilte Verfügbarkeitsgruppe konfigurieren, die darauf ausgelegt ist, keinen Datenverlust zu gewährleisten, wenn eine verteilte Verfügbarkeitsgruppe fehlschlägt. Wenn diese Einstellung konfiguriert ist, führen Sie die Schritte in diesem Abschnitt aus, um für Ihre verteilte Verfügbarkeitsgruppe einen Failover auszuführen. Wenn Sie die REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT-Einstellung nicht verwenden möchten, führen Sie die Anweisungen aus, um für eine verteilte Verfügbarkeitsgruppe in SQL Server 2019 und früheren Versionen einen Failover auszuführen.

Schritte, um sicherzustellen, dass kein Datenverlust auftritt

Um sicherzustellen, dass kein Datenverlust auftritt, müssen Sie zuerst die Verteilte Verfügbarkeitsgruppe so konfigurieren, dass keine Datenverluste unterstützt werden, indem Sie die folgenden Schritte ausführen:

1. Um sich auf Failover vorzubereiten, überprüfen Sie, ob sich die globale primäre und Weiterleitung im SYNCHRONOUS_COMMIT Modus befinden. Wenn nicht, legen Sie sie auf " SYNCHRONOUS_COMMIT Through ALTER AVAILABILITY GROUP" fest.
2. Legen Sie die verteilte Verfügbarkeitsgruppe auf dem globalen primären Replikat und der Weiterleitung auf einen synchronen Commit fest.
3. Warten Sie, bis die Verteilte Verfügbarkeitsgruppe synchronisiert wird.
4. Legen Sie auf dem globalen primären Replikat die Einstellung REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT für die verteilte Verfügbarkeitsgruppe mithilfe von ALTER AVAILABILITY GROUP auf 1 fest.
5. Stellen Sie sicher, dass alle Replikate in den lokalen VG und der verteilten Verfügbarkeitsgruppe intakt sind und die verteilte Verfügbarkeitsgruppe SYNCHRONIZED ist.
6. Legen Sie im globalen primären Replikat die Rolle „Verteilte Verfügbarkeitsgruppe“ auf „SECONDARY„ fest, wodurch die verteilte Verfügbarkeitsgruppe nicht verfügbar ist.
7. Führen Sie auf dem Forwarder (der vorgesehenen neuen primären Instanz) ein Failover der verteilten Verfügbarkeitsgruppe mit ALTER AVAILABILITY GROUP und FORCE_FAILOVER_ALLOW_DATA_LOSS durch.
8. Legen Sie für das neue sekundäre Replikat (das vorherige globale primäre Replikat) die verteilte Verfügbarkeitsgruppe REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT auf 0 fest.
9. Optional: Wenn sich die Verfügbarkeitsgruppen über eine geografische Entfernung befinden, die zu Latenz führt, ändern Sie den Verfügbarkeitsmodus in ASYNCHRONOUS_COMMIT. Dadurch wird die Änderung aus dem ersten Schritt bei Bedarf rückgängig gemacht.

T-SQL-Beispiel

Dieser Abschnitt enthält die Schritte in einem detaillierten Beispiel, um für die verteilte Verfügbarkeitsgruppe mit dem Namen distributedAG mithilfe von Transact-SQL ein Failover durchzuführen. Die Beispielumgebung verfügt über insgesamt vier Knoten für die Verteilte Verfügbarkeitsgruppe. Die globale primäre N1 und N2-Hostverfügbarkeitsgruppe ag1 sowie die N3- und N4-Weiterleitungs-Hostverfügbarkeitsgruppe ag2. Die Verteilte Verfügbarkeitsgruppe distributedAG überträgt Änderungen von ag1 auf ag2.

1. Abfrage, um SYNCHRONOUS_COMMIT für die Primärinstanzen der lokalen Verfügbarkeitsgruppen zu überprüfen, die die verteilte Verfügbarkeitsgruppe bilden. Führen Sie den folgenden T-SQL-Code direkt auf dem Weiterleitungsserver und dem globalen Primärserver aus:

   SELECT DISTINCT ag.name AS [Availability Group],
                   ar.replica_server_name AS [Replica],
                   ar.availability_mode_desc AS [Availability Mode]
   FROM sys.availability_replicas AS ar
        INNER JOIN
        sys.availability_groups AS ag
        ON ar.group_id = ag.group_id
        INNER JOIN
        sys.dm_hadr_database_replica_states AS rs
        ON ar.group_id = rs.group_id
           AND ar.replica_id = rs.replica_id
   WHERE ag.name IN ('ag1', 'ag2')
         AND rs.is_primary_replica = 1
   ORDER BY [Availability Group];
   --if needed, to set a given replica to SYNCHRONOUS for node N1, default instance. If named, change from N1 to something like N1\SQL22
   
   ALTER AVAILABILITY GROUP [testag] MODIFY REPLICA ON N'N1\SQL22' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
   

2. Legen Sie die verteilte Verfügbarkeitsgruppe auf den Modus für synchronen Commit fest, indem Sie den folgenden Code auf beiden Replikaten, dem globalen primären Replikat und dem Weiterleitungsreplikat, ausführen:

    -- sets the distributed availability group to synchronous commit
    ALTER AVAILABILITY GROUP [distributedAG] MODIFY AVAILABILITY GROUP ON
    'ag1' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
    'ag2' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
   

   Hinweis

   In einer verteilten Verfügbarkeitsgruppe hängt der Synchronisierungsstatus der zwei Verfügbarkeitsgruppen vom Verfügbarkeitsmodus beider Replikate ab. Für den synchronen Commit-Modus muss sowohl für die derzeitige primäre Verfügbarkeitsgruppe als auch für die derzeitige sekundäre Verfügbarkeitsgruppe der Verfügbarkeitsmodus SYNCHRONOUS_COMMIT festgelegt sein. Aus diesem Grund müssen Sie dieses Skript sowohl für das globale primäre Replikat als auch für die Weiterleitung ausführen.

3. Warten Sie, bis sich der Status der verteilten Verfügbarkeitsgruppe in SYNCHRONIZEDändert. Führen Sie die folgende Abfrage für die globale Primäre aus:

   -- Run this query on the Global Primary
   
   -- Check the results to see if synchronization_state_desc is SYNCHRONIZED
   SELECT ag.name,
          drs.database_id AS [Availability Group],
          db_name(drs.database_id) AS database_name,
          drs.synchronization_state_desc,
          drs.last_hardened_lsn
   FROM sys.dm_hadr_database_replica_states AS drs
        INNER JOIN
        sys.availability_groups AS ag
        ON drs.group_id = ag.group_id
   WHERE ag.name = 'distributedAG'
   ORDER BY [Availability Group];
   

   Führen Sie den nächsten Schritt aus, sobald synchronization_state_desc für die Verfügbarkeitsgruppe gleich SYNCHRONIZED ist.

4. Legen Sie für SQL Server 2022 (16.x) und höher auf der globalen primären Instanz REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT auf 1 fest, indem Sie die folgende T-SQL verwenden:

   ALTER AVAILABILITY GROUP distributedAG SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);
   

5. Überprüfen Sie, ob Ihre Verfügbarkeitsgruppen auf allen Replikaten gesund sind, indem Sie das globale primäre Replikat und die Weiterleitung abfragen.

   SELECT ag.name AS [AG Name],
          db_name(drs.database_id) AS database_name,
          ar.replica_server_name AS [replica],
          drs.synchronization_state_desc,
          drs.last_hardened_lsn
   FROM sys.dm_hadr_database_replica_states AS drs
        INNER JOIN
        sys.availability_groups AS ag
        ON drs.group_id = ag.group_id
        INNER JOIN
        sys.availability_replicas AS ar
        ON drs.replica_id = ar.replica_id
           AND drs.replica_id = ar.replica_id
   WHERE ag.name IN ('ag1', 'ag2', 'distributedAG');
   

6. Legen Sie auf dem globalen primären Replikat die Rolle der verteilten Verfügbarkeitsgruppe auf SECONDARY fest. Zu diesem Zeitpunkt ist die verteilte Verfügbarkeitsgruppe nicht verfügbar. Nach Abschluss dieses Schritts können Sie kein Failback durchführen, bis die restlichen Schritte ausgeführt wurden.

   ALTER AVAILABILITY GROUP distributedAG SET (ROLE = SECONDARY);
   

7. Führen Sie ein Failover vom globalen primären Repliakt durch, indem Sie die folgende Abfrage auf der Weiterleitung ausführen, um die Verfügbarkeitsgruppen zu übertragen und die verteilte Verfügbarkeitsgruppe wieder online zu bringen.

   -- Run the following command on the forwarder, the SQL Server instance that hosts the primary replica of the secondary availability group.
   ALTER AVAILABILITY GROUP distributedAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
   

   Nach diesem Schritt:

   • Die globalen primären Übergänge von N1 zu N3.
   • Die Weiterleitung wechselt von N3 zu N1.
   • Die Gruppe für verteilte Verfügbarkeit ist verfügbar.

8. Auf dem neuen Weiterleiterserver (dem vorherigen globalen Primär-N1) löschen Sie die Eigenschaft "Verteilte Verfügbarkeitsgruppe" REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT, indem Sie sie auf 0 setzen:

   ALTER AVAILABILITY GROUP distributedAG SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0);
   

9. OPTIONAL: Wenn die Verfügbarkeitsgruppen geografisch so weit voneinander entfernt sind, dass dadurch Latenz entsteht, erwägen Sie, den Verfügbarkeitsmodus auf ASYNCHRONOUS_COMMIT auf beiden dem globalen primären Replikat und dem Weiterleitungsserver wieder zurückzusetzen. Dadurch wird die im ersten Schritt vorgenommene Änderung bei Bedarf wiederhergestellt.

    -- If applicable: sets the distributed availability group to asynchronous commit:
    ALTER AVAILABILITY GROUP distributedAG MODIFY AVAILABILITY GROUP ON
    'ag1' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT),
    'ag2' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT);
   

Die Anweisungen in diesem Abschnitt gelten, wenn REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT nicht für die Verteilte Verfügbarkeitsgruppe festgelegt ist, z. B. bei Versionen vor SQL Server 2022 (16.x), da sie sie für verteilte Verfügbarkeitsgruppen nicht unterstützen.

Schritte, um sicherzustellen, dass kein Datenverlust auftritt

Führen Sie die folgenden Schritte aus, um sicherzustellen, dass kein Datenverlust auftritt:

1. Beenden Sie alle Transaktionen, die in der globalen primären Verfügbarkeitsgruppendatenbank(n) ausgeführt werden.
2. Stellen Sie sicher, dass sich das globale Primärsystem und Weiterleitersystem im SYNCHRONOUS_COMMIT-Modus befinden. Wenn nicht, legen Sie sie auf " SYNCHRONOUS_COMMIT Through ALTER AVAILABILITY GROUP" fest.
3. Legen Sie die verteilte Verfügbarkeitsgruppe auf dem globalen primären Replikat und der Weiterleitung auf einen synchronen Commit fest.
4. Warten Sie darauf, dass die verteilte Verfügbarkeitsgruppe synchronisiert wurde und für alle Datenbanken denselben last_hardened_lsn-Wert aufweist. Warten Sie, bis die last_hardened_lsn pro Datenbank zwischen Replikaten übereinstimmt.
5. Legen Sie im globalen primären Replikat die Rolle „Verteilte Verfügbarkeitsgruppe“ auf „SECONDARY„ fest, wodurch die verteilte Verfügbarkeitsgruppe nicht verfügbar ist.
6. Testen Sie die Failover-Bereitschaft, indem Sie überprüfen, ob die last_hardened_lsn-Werte für das globale primäre Replikat und die Weiterleitung identisch sind. Wenn sie nicht übereinstimmen, kehren Sie zum globalen primären Replikat zurück, und beginnen Sie den Prozess erneut mit dem ersten Schritt.
7. Führen Sie ein Failover der primären Verfügbarkeitsgruppe mithilfe von ALTER AVAILABILITY GROUP mit FORCE_FAILOVER_ALLOW_DATA_LOSS durch.
8. Optional: Wenn sich die Verfügbarkeitsgruppen über eine geografische Entfernung befinden, die zu Latenz führt, ändern Sie den Verfügbarkeitsmodus wieder in ASYNCHRONOUS_COMMIT.

T-SQL-Beispiel

Dieser Abschnitt enthält die Schritte in einem detaillierten Beispiel, um für die verteilte Verfügbarkeitsgruppe mit dem Namen distributedAG mithilfe von Transact-SQL ein Failover durchzuführen. Die Beispielumgebung verfügt über insgesamt vier Knoten für die Verteilte Verfügbarkeitsgruppe. Die globale primäre N1 und N2-Hostverfügbarkeitsgruppe ag1 sowie die N3- und N4-Weiterleitungs-Hostverfügbarkeitsgruppe ag2. Die Verteilte Verfügbarkeitsgruppe distributedAG überträgt Änderungen von ag1 auf ag2.

1. Beenden Sie alle Transaktionen auf den globalen primären Datenbanken (d. h. Datenbanken der primären Verfügbarkeitsgruppe), um sicherzustellen, dass keine Daten verloren gehen.

2. Abfrage, um SYNCHRONOUS_COMMIT für die Primärinstanzen der lokalen Verfügbarkeitsgruppen zu überprüfen, aus denen die verteilte Verfügbarkeitsgruppe besteht. Direkt auf dem Forwarder und dem globalen Primärserver ausführen.

   SELECT ag.name AS [Availability Group],
          ar.replica_server_name AS [Replica],
          ar.availability_mode_desc AS [Availability Mode]
   FROM sys.availability_replicas AS ar
        INNER JOIN
        sys.availability_groups AS ag
        ON ar.group_id = ag.group_id
        INNER JOIN
        sys.dm_hadr_database_replica_states AS rs
        ON ar.group_id = rs.group_id
           AND ar.replica_id = rs.replica_id
   WHERE ag.name IN ('ag1', 'ag2')
         AND rs.is_primary_replica = 1
   ORDER BY [Availability Group];
   

3. Legen Sie die verteilte Verfügbarkeitsgruppe auf den Modus für synchronen Commit fest, indem Sie den folgenden Code auf beiden Replikaten, dem globalen primären Replikat und dem Weiterleitungsreplikat, ausführen:

    -- sets the distributed availability group to synchronous commit
    ALTER AVAILABILITY GROUP [distributedAG]
    MODIFY AVAILABILITY GROUP ON
    'ag1' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
    'ag2' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
   
    -- query to verify the commit state of the distributed availability group
    SELECT
     ag.name,
     ag.is_distributed,
     ar.replica_server_name [Local AG Names],
     ar.availability_mode_desc,
     ars.connected_state_desc,
     ars.role_desc,
     ars.operational_state_desc,
     ars.synchronization_health_desc
    FROM sys.availability_groups ag
    INNER JOIN sys.availability_replicas ar ON ag.group_id=ar.group_id
    LEFT JOIN sys.dm_hadr_availability_replica_states ars on ars.replica_id=ar.replica_id and ag.group_id = ars.group_id
    WHERE ag.is_distributed=1;
   

   Hinweis

   In einer verteilten Verfügbarkeitsgruppe hängt der Synchronisierungsstatus der zwei Verfügbarkeitsgruppen vom Verfügbarkeitsmodus beider Replikate ab. Im synchronen Commitmodus müssen sowohl die derzeitige primäre Verfügbarkeitsgruppe als auch die derzeitige sekundäre Verfügbarkeitsgruppe den Verfügbarkeitsmodus SYNCHRONOUS_COMMIT verwenden. Aus diesem Grund müssen Sie dieses Skript sowohl auf dem globalen primären Replikat als auch auf dem Forwarder ausführen.

4. Warten Sie, bis der Status der verteilten Verfügbarkeitsgruppe in SYNCHRONIZED geändert wurde und alle Replikate denselben last_hardened_lsn-Wert aufweisen (pro Datenbank). Führen Sie die folgende Abfrage sowohl auf dem globalen Primärreplikat, welches das primäre Replikat der primären Verfügbarkeitsgruppe ist, als auch auf dem Forwarder aus, um den synchronization_state_desc und last_hardened_lsnzu überprüfen:

   -- Run this query on the global primary and the forwarder
   
   -- Check the results to see if synchronization_state_desc is SYNCHRONIZED, and the last_hardened_lsn is the same per database on both the global primary and forwarder
   
   -- If not, rerun the query on both side every 5 seconds until it is the case
   
   --
   SELECT ag.name AS [AG Name],
          ar.replica_server_name AS [replica],
          db_name(drs.database_id) AS database_name,
          drs.synchronization_state_desc,
          drs.last_hardened_lsn
   FROM sys.availability_groups AS ag
        INNER JOIN
        sys.availability_replicas AS ar
        ON ag.group_id = ar.group_id
        INNER JOIN
        sys.dm_hadr_database_replica_states AS drs
        ON drs.replica_id = ar.replica_id
           AND ag.group_id = drs.group_id
   WHERE ag.name IN ('ag1', 'ag2');
   

   Fahren Sie fort, wenn synchronization_state_desc der Verfügbarkeitsgruppe SYNCHRONIZED lautet und last_hardened_lsn für jede Datenbank sowohl auf dem globalen Primärserver als auch auf dem Forwarder identisch ist. Wenn synchronization_state_desc nicht SYNCHRONIZED ist oder last_hardened_lsn nicht übereinstimmt, führen Sie den Befehl alle fünf Sekunden aus, bis er sich ändert. Um Datenverluste zu verhindern, fahren Sie nicht fort, bis die synchronization_state_desc = SYNCHRONIZED und last_hardened_lsn bei jeder Datenbank gleich sind.

5. Legen Sie auf dem globalen primären Replikat die Rolle der verteilten Verfügbarkeitsgruppe auf SECONDARY fest.

   ALTER AVAILABILITY GROUP distributedAG SET (ROLE = SECONDARY);
   

   Zu diesem Zeitpunkt ist die verteilte Verfügbarkeitsgruppe nicht verfügbar.

6. Testen Sie die Failoverbereitschaft. Führen Sie die SELECT-Abfrage erneut aus, um last_hardened_lsn (pro Datenbank) sowohl für das globale primäre Replikat als auch für die Weiterleitung zu überprüfen. Überprüfen Sie, ob „last_hardened_lsn“ für alle Datenbanken auf dem globalen primären Replikat und der Weiterleitung übereinstimmt.

7. Je nach Ergebnis des vorherigen Schritts variiert der nächste Schritt.

   • Wenn last_hardened_lsns aus der SELECT-Abfrage übereinstimmt, führen Sie ein Failover von der primären Verfügbarkeitsgruppe zur sekundären Verfügbarkeitsgruppe durch. Führen Sie den ALTER AVAILABILITY GROUP-Befehl auf dem Weiterleitungsserver aus, auf dem sich der SQL Server befindet, der das primäre Replikat der sekundären Verfügbarkeitsgruppe beherbergt.

   • Wenn die last_hardened_lsns nach einiger Zeit nicht mit den Ergebnissen der SELECT-Abfrage übereinstimmen, führen Sie ein Failover der verteilten AG zur ursprünglichen Weiterleitung (N1) durch, indem Sie den Failover-Befehl gegen die globale Primärinstanz ausführen. Starten Sie dann den Prozess erneut aus dem ersten Schritt.

   -- If the last_hardened_lsns match, you can run the failover query below against the forwarder
   
   -- If the last_hardened_lsns do not match after some time, you can run the failover query against the original global primary
   ALTER AVAILABILITY GROUP distributedAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
   

   Nach diesem Schritt ist die verteilte Verfügbarkeitsgruppe verfügbar.

8. OPTIONAL: Nach einem erfolgreichen Failover und wenn die Verfügbarkeitsgruppen durch geografische Distanz bedingte Latenz erfahren, erwägen Sie, den Verfügbarkeitsmodus wieder in ASYNCHRONOUS_COMMIT zu ändern, um die zuvor vorgenommene Änderung rückgängig zu machen.

    -- If applicable: sets the distributed availability group to asynchronous commit:
    ALTER AVAILABILITY GROUP distributedAG MODIFY AVAILABILITY GROUP ON
    'ag1' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT),
    'ag2' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT);
   

Nachdem Sie diese Schritte ausgeführt haben, erfolgt ein Failover für die verteilte Verfügbarkeitsgruppe ohne Datenverlust.