Freigeben über

Konfigurieren verteilter Always On-Verfügbarkeitsgruppen

  • Artikel

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:

Hinweis

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.

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

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.

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

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

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.

Um sicherzustellen, dass kein Datenverlust besteht, stellen Sie folgendes sicher:

  1. Beenden Sie alle Transaktionen auf den globalen primären Datenbanken (d. h. Datenbanken der primären Verfügbarkeitsgruppe)
  2. Legen Sie die verteilte Verfügbarkeitsgruppe auf synchronen Commit fest.
  3. Warten Sie darauf, dass die verteilte Verfügbarkeitsgruppe synchronisiert wurde und für alle Datenbanken denselben last_hardened_lsn-Wert aufweist.

Nachdem Daten synchronisiert wurden, können Sie für die verteilte Verfügbarkeitsgruppe ein Failover ausführen:

  1. Legen Sie im globalen primären Replikat die Rolle „Verteilte Verfügbarkeitsgruppe“ auf „SECONDARY„ fest, wodurch die verteilte Verfügbarkeitsgruppe nicht verfügbar ist.
  2. Legen Sie die Einstellung für die verteilte Verfügbarkeitsgruppe REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT mithilfe der VERFÜGBARKEITSGRUPPE ÄNDERN auf 1 fest.
  3. Testen Sie die Failoverbereitschaft.
  4. Failover der primären Verfügbarkeitsgruppe mithilfe von VERFÜGBARKEITSGRUPPE ÄNDERN mit FORCE_FAILOVER_ALLOW_DATA_LOSS.
  5. Legen Sie die verteilte Verfügbarkeitsgruppe REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT auf 0 fest.

In den folgenden Transact-SQL-Beispielen werden ausführliche 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 vorherige 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 diese 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.

Verteilte AlwaysOn-Verfügbarkeitsgruppe

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)