Konfigurieren verteilter Always On-Verfügbarkeitsgruppen

Gilt für:SQL Server

Sie müssen zwei Verfügbarkeitsgruppen mit eigenen Listenern erstellen, um eine verteilte Verfügbarkeitsgruppe zu erstellen. Anschließend kombinieren Sie diese Verfügbarkeitsgruppen zu einer verteilten Verfügbarkeitsgruppe. Die folgenden Schritte stellen ein einfaches Beispiel in Transact-SQL dar. Dieses Beispiel deckt nicht alle Details zum Erstellen von Verfügbarkeitsgruppen und Listenern ab, stattdessen legt es den Schwerpunkt auf die Herausarbeitung der wichtigsten Anforderungen.

Eine technische Übersicht über verteilte Verfügbarkeitsgruppen finden Sie unter Verteilte Verfügbarkeitsgruppen.

Voraussetzungen

Um eine verteilte Verfügbarkeitsgruppe zu konfigurieren, müssen Sie folgende Voraussetzungen erfüllen:

• Eine unterstützte Version von SQL Server.

Hinweis

Wenn Sie den Listener für Ihre Verfügbarkeitsgruppe auf Ihrem SQL Server auf Azure VM mithilfe eines verteilten Netzwerknamens (Distributed Network Name, DNN) konfiguriert haben, wird die Konfiguration einer verteilten Verfügbarkeitsgruppe über Ihrer Verfügbarkeitsgruppe nicht unterstützt. Weitere Informationen finden Sie unter Featureinteroperabilität von SQL Server auf Azure VM mit AG und DNN-Listener.

Festlegen der Endpunktlistener zur Überwachung aller IP-Adressen

Stellen Sie sicher, dass die Endpunkte zwischen den verschiedenen Verfügbarkeitsgruppen in der verteilten Verfügbarkeitsgruppe kommunizieren können. Wenn eine Verfügbarkeitsgruppe auf ein bestimmtes Netzwerk auf dem Endpunkt festgelegt ist, funktioniert die verteilte Verfügbarkeitsgruppe nicht ordnungsgemäß. Konfigurieren Sie den Listener aller Server, die ein Replikat in der verteilten Verfügbarkeitsgruppe hosten, so, dass er auf alle IP-Adressen lauscht (LISTENER_IP = ALL).

Erstellen eines Endpunkts zum Lauschen auf alle IP-Adressen

Das folgende Skript erstellt z.B. einen Listenerendpunkt auf TCP-Port 5022, der alle IP-Adressen überwacht.

CREATE ENDPOINT [aodns-hadr]
    STATE = STARTED
    AS TCP
(
            LISTENER_PORT = 5022,
            LISTENER_IP = ALL
)
    FOR DATABASE_MIRRORING
(
            ROLE = ALL,
            AUTHENTICATION = WINDOWS NEGOTIATE,
            ENCRYPTION = REQUIRED ALGORITHM AES
);
GO

Ändern eines Endpunkts zum Lauschen auf alle IP-Adressen

Das folgende Skript ändert z.B. einen Listenerendpunkt so, dass er alle IP-Adressen überwacht.

ALTER ENDPOINT [aodns-hadr]
    AS TCP
(
            LISTENER_IP = ALL
);
GO

Erstellen der ersten Verfügbarkeitsgruppe

Erstellen der ersten Verfügbarkeitsgruppe auf dem ersten Cluster

Erstellen Sie eine Verfügbarkeitsgruppe für den ersten Windows Server-Failovercluster (WSFC). In diesem Beispiel heißt die Verfügbarkeitsgruppe ag1 für die Datenbank db1. Das primäre Replikat der primären Verfügbarkeitsgruppe wird in einer verteilten Verfügbarkeitsgruppe als globales primäres Replikat bezeichnet. Server1 ist in diesem Beispiel das primäre Replikat.

CREATE AVAILABILITY GROUP [ag1]
FOR DATABASE db1
REPLICA ON N'server1' WITH (ENDPOINT_URL = N'TCP://server1.contoso.com:5022',
    FAILOVER_MODE = AUTOMATIC,
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
    BACKUP_PRIORITY = 50,
    SECONDARY_ROLE(ALLOW_CONNECTIONS = NO),
    SEEDING_MODE = AUTOMATIC),
N'server2' WITH (ENDPOINT_URL = N'TCP://server2.contoso.com:5022',
    FAILOVER_MODE = AUTOMATIC,
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
    BACKUP_PRIORITY = 50,
    SECONDARY_ROLE(ALLOW_CONNECTIONS = NO),
    SEEDING_MODE = AUTOMATIC);
GO

Hinweis

Im vorherigen Beispiel wird automatisches Seeding verwendet, wobei SEEDING_MODE sowohl für die Replikate als auch für die verteilte Verfügbarkeitsgruppe auf AUTOMATIC festgelegt ist. Diese Konfiguration legt fest, dass die sekundären Replikate und sekundären Verfügbarkeitsgruppen automatisch aufgefüllt werden, ohne eine manuelle Sicherung und Wiederherstellung der primären Datenbank erforderlich zu machen.

Verknüpfen der sekundären Replikate mit der primären Verfügbarkeitsgruppe

Alle sekundären Replikate müssen mithilfe von ALTER AVAILABILITY GROUP mit der Option JOIN mit der Verfügbarkeitsgruppe verknüpft werden. Da in diesem Beispiel automatisches Seeding verwendet wird, müssen Sie außerdem ALTER AVAILABILITY GROUP mit der Option GRANT CREATE ANY DATABASE aufrufen. Diese Einstellung ermöglicht der Verfügbarkeitsgruppe, die Datenbank zu erstellen und mit dem automatischen Seeding aus dem ersten Replikat zu beginnen.

In diesem Beispiel werden die folgenden Befehle auf dem sekundären Replikat server2ausgeführt, um die Verknüpfung mit der Verfügbarkeitsgruppe ag1 herzustellen. Der Verfügbarkeitsgruppe ist es damit gestattet, Datenbanken auf dem sekundären Replikat zu erstellen.

ALTER AVAILABILITY GROUP [ag1] JOIN
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE
GO

Hinweis

Wenn die Verfügbarkeitsgruppe eine Datenbank auf einem sekundären Replikat erstellt, legt sie als Datenbankbesitzer das Konto fest, das die Anweisung ALTER AVAILABILITY GROUP ausgeführt hat, um die Berechtigung zum Erstellen von Datenbanken zu erteilen. Ausführliche Informationen finden Sie unter Grant create database permission on secondary replica to availability group (Erteilen der Berechtigung zum Erstellen von Datenbanken auf dem sekundären Replikat von Verfügbarkeitsgruppen).

Erstellen eines Listeners für die primäre Verfügbarkeitsgruppe

Fügen Sie im nächsten Schritt einen Listener für die primäre Verfügbarkeitsgruppe auf dem ersten WSFC hinzu. In diesem Beispiel hat der Listener den Namen ag1-listener. Weitere Informationen zum Erstellen eines Listeners finden Sie unter Erstellen oder Konfigurieren eines Verfügbarkeitsgruppenlisteners (SQL Server).

ALTER AVAILABILITY GROUP [ag1]
    ADD LISTENER 'ag1-listener' (
        WITH IP ( ('2001:db88:f0:f00f::cf3c'),('2001:4898:e0:f213::4ce2') ) ,
        PORT = 60173);
GO

Erstellen der zweiten Verfügbarkeitsgruppe

Erstellen Sie anschließend auf dem zweiten WSFC eine zweite Verfügbarkeitsgruppe, ag2. In diesem Fall wird die Datenbank nicht angegeben, da sie automatisch aus der primären Verfügbarkeitsgruppe seediert wird. Das primäre Replikat der sekundären Verfügbarkeitsgruppe wird in einer verteilten Verfügbarkeitsgruppe als Weiterleitung bezeichnet. In diesem Beispiel ist Server3 die Weiterleitung.

CREATE AVAILABILITY GROUP [ag2]
FOR
REPLICA ON N'server3' WITH (ENDPOINT_URL = N'TCP://server3.contoso.com:5022',
    FAILOVER_MODE = MANUAL,
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
    BACKUP_PRIORITY = 50,
    SECONDARY_ROLE(ALLOW_CONNECTIONS = NO),
    SEEDING_MODE = AUTOMATIC),
N'server4' WITH (ENDPOINT_URL = N'TCP://server4.contoso.com:5022',
    FAILOVER_MODE = MANUAL,
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
    BACKUP_PRIORITY = 50,
    SECONDARY_ROLE(ALLOW_CONNECTIONS = NO),
    SEEDING_MODE = AUTOMATIC);
GO

Hinweis

Die sekundäre Verfügbarkeitsgruppe muss denselben Endpunkt für die Datenbankspiegelung verwenden (in diesem Beispiel Port 5022). Andernfalls wird die Replikation nach einem lokalen Failover beendet.

Verknüpfen der sekundären Replikate mit der sekundären Verfügbarkeitsgruppe

In diesem Beispiel werden die folgenden Befehle auf dem sekundären Replikat server4ausgeführt, um die Verknüpfung mit der Verfügbarkeitsgruppe ag2 herzustellen. Der Verfügbarkeitsgruppe wird dann erlaubt, Datenbanken auf dem sekundären Replikat zu erstellen, um das automatische Seeding zu unterstützen.

ALTER AVAILABILITY GROUP [ag2] JOIN
ALTER AVAILABILITY GROUP [ag2] GRANT CREATE ANY DATABASE
GO

Erstellen eines Listeners für die sekundäre Verfügbarkeitsgruppe

Fügen Sie im nächsten Schritt einen Listener für die sekundäre Verfügbarkeitsgruppe auf dem zweiten WSFC hinzu. In diesem Beispiel hat der Listener den Namen ag2-listener. Weitere Informationen zum Erstellen eines Listeners finden Sie unter Erstellen oder Konfigurieren eines Verfügbarkeitsgruppenlisteners (SQL Server).

ALTER AVAILABILITY GROUP [ag2]
    ADD LISTENER 'ag2-listener' ( WITH IP ( ('2001:db88:f0:f00f::cf3c'),('2001:4898:e0:f213::4ce2') ) , PORT = 60173);
GO

Erstellen einer verteilten Verfügbarkeitsgruppe auf dem ersten Cluster

Erstellen Sie auf dem ersten WSFC eine verteilte Verfügbarkeitsgruppe (die in diesem Beispiel den Namen distributedAG trägt). Verwenden Sie den CREATE AVAILABILITY GROUP -Befehl mit der DISTRIBUTED -Option. Der AVAILABILITY GROUP ON-Parameter gibt die Memberverfügbarkeitsgruppen ag1 und ag2 an.

Automatisches Seeding

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

Manuelles Seeding

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

Hinweis

Die LISTENER_URL gibt den Listener für jede Verfügbarkeitsgruppe zusammen mit dem Datenbankspiegelungs-Endpunkt der Verfügbarkeitsgruppe an. In diesem Beispiel ist das Port 5022 (nicht Port 60173 , der zum Erstellen des Listeners verwendet wurde). Wenn Sie einen Lastenausgleich verwenden, z. B. in Azure, fügen Sie eine Lastenausgleichsregel für den Port einer verteilten Verfügbarkeitsgruppehinzu. Fügen Sie zusätzlich zum SQL Server-Instanzport die Regel für den Listenerport hinzu.

Abbrechen des automatischen Seedings für die Weiterleitung

Falls es aus unterschiedlichsten Gründen erforderlich ist, die Initialisierung der Weiterleitung abzubrechen, bevor die zwei Verfügbarkeitsgruppen synchronisiert werden, ändern Sie die verteilte Verfügbarkeitsgruppe mit ALTER, indem Sie den SEEDING_MODE-Parameter der Weiterleitung auf MANUAL festlegen und das Seeding sofort abbrechen. Führen Sie den Befehl für die globale primäre Datenbank aus:

-- Cancel automatic seeding​.  Connect to global primary but specify DAG AG2
ALTER AVAILABILITY GROUP [distributedAG] ​
   MODIFY ​
   AVAILABILITY GROUP ON ​
   'ag2' WITH ​
   ( ​ SEEDING_MODE = MANUAL ​ ); ​

Verknüpfen der verteilten Verfügbarkeitsgruppe auf dem zweiten Cluster

Verknüpfen Sie anschließend die verteilte Veerfügbarkeitsgruppe auf dem zweiten WSFC.

Automatisches Seeding

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

Manuelles Seeding

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ären Instanz

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

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

So stellen Sie auf der weiterleitenden Instanz wieder her

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];

Verknüpfen der Datenbank auf dem sekundären Replikat der zweiten Verfügbarkeitsgruppe

Wenn die zweite Verfügbarkeitsgruppe für die Verwendung des automatischen Seedings eingerichtet wurde, fahren Sie mit Schritt 2 fort.

1. Wenn die zweite Verfügbarkeitsgruppe manuelles Seeding verwendet, stellen Sie die Sicherung, die Sie auf dem globalen primären Replikat erstellt haben, auf dem sekundären Replikat der zweiten Verfügbarkeitsgruppe wieder her:

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

2. Nachdem die Datenbank auf dem sekundären Replikat der zweiten Verfügbarkeitsgruppe in einen Wiederherstellungsstatus versetzt wurde, müssen Sie sie manuell mit der Verfügbarkeitsgruppe verknüpfen.

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

Ein Failover für eine verteilte Verfügbarkeitsgruppe

Da SQL Server 2022 (16.x) die Unterstützung für verteilte Verfügbarkeitsgruppen für die REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT-Einstellung eingeführt hat, unterscheiden sich Anweisungen zum Ausführen eines Failover für eine verteilte Verfügbarkeit für SQL Server 2022 und höhere Versionen als für SQL Server 2019 und frühere Versionen.

Bei einer verteilten Verfügbarkeitsgruppe ist der einzige unterstützte Failover-Typ ein durch einen manuellen Benutzer initiiertes FORCE_FAILOVER_ALLOW_DATA_LOSS. Um Datenverluste zu verhindern, müssen Sie daher zusätzliche Schritte ausführen (im Detail in diesem Abschnitt beschrieben), um sicherzustellen, dass Daten zwischen den beiden Replikaten synchronisiert werden, bevor Sie das Failover initiieren.

Im Falle eines Notfalls, in dem Datenverlust akzeptabel ist, können Sie ein Failover initiieren, ohne sicherzustellen, dass die Datensynchronisierung ausgeführt wird:

ALTER AVAILABILITY GROUP distributedAG FORCE_FAILOVER_ALLOW_DATA_LOSS;

Mit demselben Befehl können Sie sowohl den Failover zur Weiterleitung als auch das Failback zum globalen Primärserver durchführen.

SQL Server 2022 und höher

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.

Hinweis

Das Festlegen von REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT auf 1 bedeutet, dass das primäre Replikat wartet, bis Transaktionen auf dem sekundären Replikat bestätigt werden, bevor sie auf dem primären Replikat bestätigt werden, was die Leistung beeinträchtigen kann. Während das Einschränken oder Beenden von Transaktionen auf der globalen Primären nicht erforderlich ist, damit die verteilte Verfügbarkeitsgruppe in SQL Server 2022 (16.x) synchronisiert werden kann, kann dies die Leistung sowohl für Benutzertransaktionen als auch für die Synchronisierung verteilter Verfügbarkeitsgruppen mit REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT auf 1 verbessern.

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 das Failover vorzubereiten, überprüfen Sie, ob sich die globale Primärinstanz und der globale Weiterleiter im SYNCHRONOUS_COMMIT-Modus befinden. Wenn nicht, setzen Sie sie auf SYNCHRONOUS_COMMIT bis ALTER AVAILABILITY GROUP.
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 im globalen primären Replikat die REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT-Einstellung für die verteilte Verfügbarkeitsgruppe auf 1 fest, indem Sie ALTER AVAILABILITY GROUP verwenden.
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 der Weiterleitung (das beabsichtigte neue primäre Replikat) ein Failover der verteilten Verfügbarkeitsgruppe durch, indem Sie ALTER AVAILABILITY GROUP mit FORCE_FAILOVER_ALLOW_DATA_LOSS verwenden.
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. Das globale primäre Replikat N1 und die Hostverfügbarkeitsgruppe N2ag1, die globale Weiterleitung N3 und Hostverfügbarkeitsgruppe N4ag2. 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 globalen Weiterleiter und dem globalen Primärsystem 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 einen synchronen Commit fest, indem Sie folgenden Code auf dem globalen primären Replikat und der Weiterleitung 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 Commitmodus müssen sowohl die aktuell primäre Verfügbarkeitsgruppe als auch die aktuell sekundäre Verfügbarkeitsgruppe den Verfügbarkeitsmodus SYNCHRONOUS_COMMIT aufweisen. 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 and the forwarder
   
   -- 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 globale 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 zwischen Verfügbarkeitsgruppen eine geografische Entfernung liegt, die Latenz (Wartezeit) verursacht, ziehen Sie in Betracht, den Verfügbarkeitsmodus wieder auf dem globalen primären Replikat und der Weiterleitung in ASYNCHRONOUS_COMMIT zu ändern. 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);
   

SQL Server 2019 und älter

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. Überprüfen Sie, ob sich der globale Primärserver und der globale Weiterleitungsserver im SYNCHRONOUS_COMMIT Modus befinden. Wenn nicht, setzen Sie sie auf SYNCHRONOUS_COMMIT bis ALTER AVAILABILITY GROUP.
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. Failover der primären Verfügbarkeitsgruppe mithilfe von VERFÜGBARKEITSGRUPPE ÄNDERN mit FORCE_FAILOVER_ALLOW_DATA_LOSS.
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. Das globale primäre Replikat N1 und die Hostverfügbarkeitsgruppe N2ag1, die globale Weiterleitung N3 und Hostverfügbarkeitsgruppe N4ag2. 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 der globalen Weiterleitung und dem globalen primären Replikat 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 einen synchronen Commit fest, indem Sie folgenden Code auf dem globalen primären Replikat und der Weiterleitung 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. Für den synchronen Commitmodus müssen sowohl die aktuell primäre Verfügbarkeitsgruppe als auch die aktuell sekundäre Verfügbarkeitsgruppe den Verfügbarkeitsmodus SYNCHRONOUS_COMMIT aufweisen. Aus diesem Grund müssen Sie dieses Skript auf dem globalen primären Replikat und der Weiterleitung 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, sobald der synchronization_state_desc-Wert der Verfügbarkeitsgruppe SYNCHRONIZED ist und die last_hardened_lsn-Werte der Datenbanken in der globalen primären Datenbank und der Weiterleitung identisch sind. 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 Befehl ALTER AVAILABILITY GROUP auf dem Forwarder-SQL-Server aus, dem SQL Server, der das primäre Replikat der sekundären Verfügbarkeitsgruppe hostet.

   • Wenn last_hardened_lsnsnach einiger Zeit nicht mit der SELECT-Abfrage übereinstimmt, führen Sie ein Failback für die verteilte VG auf die ursprüngliche globale Weiterleitung (N1) durch, indem Sie den Failoverbefehl am globalen primären Replikat 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.

Entfernen einer verteilten Verfügbarkeitsgruppe

Die folgende Transact-SQL-Anweisung entfernt eine verteilte Verfügbarkeitsgruppe mit dem Namen distributedAG:

DROP AVAILABILITY GROUP distributedAG;

Erstellen einer verteilten Verfügbarkeitsgruppe auf Failoverclusterinstanzen

Sie können eine verteilte Verfügbarkeitsgruppe mit einer Verfügbarkeitsgruppe auf einer Failoverclusterinstanz (FCI) erstellen. In diesem Fall benötigen Sie keinen Verfügbarkeitsgruppenlistener. Verwenden Sie den virtuellen Netzwerknamen (VNN) für das primäre Replikat der FCI-Instanz. Im folgenden Beispiel ist eine verteilte Verfügbarkeitsgruppe namens SQLFCIDAG dargestellt. Eine Verfügbarkeitsgruppe ist SQLFCIAG. SQLFCIAG besitzt zwei FCI-Replikate. Der VNN für das primäre FCI-Replikat ist FCI SQLFCIAG-1, und der VNN für das sekundäre FCI-Replikat ist SQLFCIAG-2. Die verteilte Verfügbarkeitsgruppe enthält außerdem SQLAG-DR zur Wiederherstellung im Notfall.

Die folgende DDL erstellt diese verteilte Verfügbarkeitsgruppe:

CREATE AVAILABILITY GROUP [SQLFCIDAG]
   WITH (DISTRIBUTED)
   AVAILABILITY GROUP ON
  'SQLFCIAG' WITH
      (
         LISTENER_URL = 'tcp://SQLFCIAG-1.contoso.com:5022',
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
         FAILOVER_MODE = MANUAL,
         SEEDING_MODE = AUTOMATIC
      ),
  'SQLAG-DR' WITH
      (
         LISTENER_URL = 'tcp://SQLAG-DR.contoso.com:5022',
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
         FAILOVER_MODE = MANUAL,
         SEEDING_MODE = AUTOMATIC
      );

Die Listener-URL ist mit dem VNN der primären FCI-Instanz identisch.

Ausführen eines manuellen Failovers für die FCI in der verteilten Verfügbarkeitsgruppe

Um ein manuelles Failover für die FCI-Verfügbarkeitsgruppe auszuführen, aktualisieren Sie die verteilte Verfügbarkeitsgruppe, um die Änderung der Listener-URL zu übernehmen. Führen Sie beispielsweise die folgende DDL sowohl für das globale primäre Replikat der verteilten Verfügbarkeitsgruppe als auch für die Weiterleitung der verteilten Verfügbarkeitsgruppe von SQLFCIDAG aus:

ALTER AVAILABILITY GROUP [SQLFCIDAG]
   MODIFY AVAILABILITY GROUP ON
 'SQLFCIAG' WITH
    (
        LISTENER_URL = 'tcp://SQLFCIAG-2.contoso.com:5022'
    )

Verwandte Inhalte

• CREATE AVAILABILITY GROUP (Transact-SQL)
• ALTER AVAILABILITY GROUP (Transact-SQL)