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

Wenn Sie den Listener für Ihre Verfügbarkeitsgruppe in ihrer SQL Server auf Azure-VM mithilfe eines verteilten Netzwerknamens (DNN) konfiguriert haben, wird die Konfiguration einer verteilten Verfügbarkeitsgruppe zusätzlich zu 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 für ein bestimmtes Netzwerk auf den Endpunkt festgelegt ist, funktioniert die verteilte Verfügbarkeitsgruppe nicht richtig. 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 DATA_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. Die Datenbank wird in diesem Fall nicht angegeben, da sie automatisch per Seeding aus der primären Verfügbarkeitsgruppe aufgefüllt 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 beispielsweise in Azure einen Lastenausgleich verwenden, fügen Sie eine Regel für den Lastenausgleich für den Port der verteilten Verfügbarkeitsgruppe hinzu. 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 auf der weiterleitenden Instanz Folgendes 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];   

Failover auf eine sekundäre Verfügbarkeitsgruppe

Es gibt zwei verschiedene Sätze von Anweisungen für das Failover auf eine sekundäre Verfügbarkeitsgruppe. Folgen Sie den Anweisungen, die für Ihre Version und Konfiguration gelten.

Die nachstehenden Anweisungen sind für SQL Server 2022 (16.x) oder höher bestimmt, wenn REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT festgelegt ist.

Für andere Konfigurationen finden Sie entsprechende Anweisungen unter Failover auf eine sekundäre Verfügbarkeitsgruppe (vor SQL Server 2022).

Failover auf eine sekundäre Verfügbarkeitsgruppe (SQL Server 2022 und höher)

Die Schritte in diesem Abschnitt sind so konzipiert, dass es beim Ausfall einer verteilten Verfügbarkeitsgruppe nicht zu einem Datenverlust kommt. Die Schritte umfassen die Einstellung REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT. Diese Einstellung für verteilte Verfügbarkeitsgruppen wird ab SQL Server 2022 (16.x) unterstützt.

Zurzeit wird nur manuelles Failover unterstützt. So führen Sie ein manuelles Failover für eine verteilte Verfügbarkeitsgruppe aus:

1. Beenden Sie alle Transaktionen auf den globalen primären Datenbanken (d. h. Datenbanken der primären Verfügbarkeitsgruppe), und legen Sie dann die verteilte Verfügbarkeitsgruppe auf synchrone Commits fest, um sicherzustellen, dass keine Daten verloren gehen.
2. Warten Sie darauf, dass die verteilte Verfügbarkeitsgruppe synchronisiert wurde und für alle Datenbanken denselben last_hardened_lsn-Wert aufweist.
3. Legen Sie die Rolle der verteilten Verfügbarkeitsgruppe für das globale, primäre Replikat auf SECONDARY fest.

Wichtig

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

1. Legen Sie die verteilte Verfügbarkeitsgruppe REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT auf 1 fest.
2. Testen Sie die Failoverbereitschaft.
3. Führen Sie einen Failover der primären Verfügbarkeitsgruppe aus.
4. Legen Sie die verteilte Verfügbarkeitsgruppe REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT auf 0 fest.

In den folgenden Transact-SQL-Beispielen werden die ausführlichen Schritte zum Ausführen eines Failover für die verteilte Verfügbarkeitsgruppe namens distributedag veranschaulicht:

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. Legen Sie dann 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 
     );
   
    -- verifies the commit state of the distributed availability group
    select ag.name, ag.is_distributed, ar.replica_server_name, ar.availability_mode_desc, ars.connected_state_desc, ars.role_desc, 
    ars.operational_state_desc, ars.synchronization_health_desc from sys.availability_groups ag  
    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
    where ag.is_distributed=1
    GO
   
   

   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 das obige Skript auf dem globalen primären Replikat und der Weiterleitung ausführen.

2. 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 für die globale primäre Datenbank, d. h. das primäre Replikat der primären Verfügbarkeitsgruppe, und die Weiterleitung aus, um synchronization_state_desc und last_hardened_lsn zu ü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
          , drs.database_id
          , db_name(drs.database_id) as database_name
          , drs.group_id
          , drs.replica_id
          , drs.synchronization_state_desc
          , drs.last_hardened_lsn  
   FROM sys.dm_hadr_database_replica_states drs 
   INNER JOIN sys.availability_groups ag on drs.group_id = ag.group_id;
   

   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 entspricht oder die last_hardened_lsn-Werte nicht identisch sind, führen Sie den Befehl alle fünf Sekunden aus, bis die Änderung erfolgt. Fahren Sie nicht fort, bevor synchronization_state_desc den Wert SYNCHRONIZED aufweist und die last_hardened_lsn-Werte identisch sind.

3. 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.

4. Legen Sie für SQL Server 2022 (16.x) und höher für die globale primäre Instanz REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT fest.

   ALTER AVAILABILITY GROUP distributedag 
     SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);
   

5. Testen Sie die Failoverbereitschaft. Führen Sie die folgende Abfrage für die globale primäre Datenbank und die Weiterleitung aus:

    -- Run this query on the Global Primary and the forwarder
    -- Check the results to see if the last_hardened_lsn is the same per database on both the global primary and forwarder 
    -- The availability group is ready to fail over when the last_hardened_lsn is the same for both availability groups per database
    --
    SELECT ag.name, 
        drs.database_id, 
        db_name(drs.database_id) as database_name,
        drs.group_id, 
        drs.replica_id,
        drs.last_hardened_lsn
    FROM sys.dm_hadr_database_replica_states drs
    INNER JOIN sys.availability_groups ag ON drs.group_id = ag.group_id;
   

   Die Verfügbarkeitsgruppe ist für das Failover bereit, wenn die last_hardened_lsn-Werte der Verfügbarkeitsgruppen pro Datenbank identisch sind. Wenn die last_hardened_lsn-Werte nach einiger Zeit nicht identisch sind, führen Sie ein Failback auf die globale primäre Datenbank durch, indem Sie den folgenden Befehl auf dieser ausführen, und fangen Sie dann ab dem zweiten Schritt von neu an, um Datenverlust zu vermeiden:

   -- If the last_hardened_lsn is not the same after a period of time, to avoid data loss, 
   -- we need to fail back to the global primary by running this command on the global primary 
   -- and then start over from the second step:
   
   ALTER AVAILABILITY GROUP distributedag FORCE_FAILOVER_ALLOW_DATA_LOSS; 
   

6. Führen Sie ein Failover von der primären Verfügbarkeitsgruppe auf die sekundäre Verfügbarkeitsgruppe aus. Führen Sie den folgenden Befehl für die Weiterleitung aus, die SQL Server-Instanz, die das primäre Replikat der sekundären Verfügbarkeitsgruppe hostet.

   -- Once the last_hardened_lsn is the same per database on both sides
   -- We can Fail over from the primary availability group to the secondary availability group. 
   -- 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 ist die verteilte Verfügbarkeitsgruppe verfügbar.

7. Löschen Sie für SQL Server 2022 (16.x) und höher die verteilte Verfügbarkeitsgruppe REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT.

   ALTER AVAILABILITY GROUP distributedag 
     SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0);
   

Nachdem Sie die obigen Schritte ausgeführt haben, erfolgt ein Failover für die verteilte Verfügbarkeitsgruppe ohne Datenverlust. Wenn zwischen den Verfügbarkeitsgruppen eine geografische Entfernung liegt, die Wartezeit verursacht, ändern Sie den Verfügbarkeitsmodus zurück zu „ASYNCHRONOUS_COMMIT“.

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.

Mit der folgenden DDL-Anweisung wird diese verteilte Verfügbarkeitsgruppe erstellt.

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'
    )

Nächste Schritte

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