Een gedistribueerde AlwaysOn-beschikbaarheidsgroep configureren

2025-05-27

Van toepassing op:SQL Server

Als u een gedistribueerde beschikbaarheidsgroep wilt maken, moet u twee beschikbaarheidsgroepen maken die elk een eigen listener hebben. Vervolgens combineert u deze beschikbaarheidsgroepen in een gedistribueerde beschikbaarheidsgroep. De volgende stappen bevatten een basisvoorbeeld in Transact-SQL. In dit voorbeeld worden niet alle details behandeld van het maken van beschikbaarheidsgroepen en listeners; In plaats daarvan richt het zich op het markeren van de belangrijkste vereisten.

Zie Gedistribueerde beschikbaarheidsgroepen voor een technisch overzicht van gedistribueerde beschikbaarheidsgroepen.

Vereiste voorwaarden

Als u een gedistribueerde beschikbaarheidsgroep wilt configureren, moet u het volgende hebben:

Een ondersteunde versie van SQL Server.

Opmerking

Als u de listener voor uw beschikbaarheidsgroep hebt geconfigureerd op uw SQL Server op azure-VM met behulp van een gedistribueerde netwerknaam (DNN), wordt het configureren van een gedistribueerde beschikbaarheidsgroep boven op uw beschikbaarheidsgroep niet ondersteund. Zie sql Server op Azure VM-functie-interoperabiliteit met AG en DNN-listener voor meer informatie.

Machtigingen

Vereist de machtiging CREATE AVAILABILITY GROUP op de server om een beschikbaarheidsgroep te maken en sysadmin om een failover uit te voeren voor een gedistribueerde beschikbaarheidsgroep.

Stel de eindpunten voor databasespiegeling in om te luisteren op alle IP-adressen

Zorg ervoor dat de eindpunten voor databasespiegeling kunnen communiceren tussen de verschillende beschikbaarheidsgroepen in de gedistribueerde beschikbaarheidsgroep. Als één beschikbaarheidsgroep is ingesteld op een specifiek netwerk op het eindpunt voor databasespiegeling, werkt de gedistribueerde beschikbaarheidsgroep niet goed. Stel op elke server die als host fungeert voor een replica in de gedistribueerde beschikbaarheidsgroep het eindpunt voor databasespiegeling in om te luisteren op alle IP-adressen (LISTENER_IP = ALL).

Een eindpunt voor databasespiegeling maken om te luisteren op alle IP-adressen

Met het volgende script wordt bijvoorbeeld een nieuw eindpunt voor databasespiegeling gemaakt op TCP-poort 5022 dat luistert op alle IP-adressen.

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

Een bestaand database-mirroring-eindpunt wijzigen zodat het luistert naar alle IP-adressen

Met het volgende script wordt bijvoorbeeld een bestaand eindpunt voor databasespiegeling gewijzigd om te luisteren op alle IP-adressen.

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

Eerste beschikbaarheidsgroep maken

De primaire beschikbaarheidsgroep op het eerste cluster maken

Maak een beschikbaarheidsgroep op het eerste Windows Server-failovercluster (WSFC). In dit voorbeeld heeft de beschikbaarheidsgroep de naam ag1 van de database db1. De primaire replica van de primaire beschikbaarheidsgroep wordt de globale primaire in een gedistribueerde beschikbaarheidsgroep genoemd. Server1 is de globale primaire in dit voorbeeld.

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

Opmerking

In het voorgaande voorbeeld wordt automatische seeding gebruikt, waarbij SEEDING_MODE is ingesteld op AUTOMATISCH voor zowel de replica's als de gedistribueerde beschikbaarheidsgroep. Met deze configuratie worden de secundaire replica's en de secundaire beschikbaarheidsgroep automatisch ingevuld zonder dat er handmatig een back-up en herstel van de primaire database nodig is.

Verbind de secundaire replica's met de primaire beschikbaarheidsgroep

Secundaire replica's moeten toegevoegd worden aan de beschikbaarheidsgroep met ALTER AVAILABILITY GROUP en de optie JOIN. Omdat automatische seeding in dit voorbeeld wordt gebruikt, moet u ook de optie GRANT CREATE ANY DATABASE gebruiken bij het aanroepen van ALTER AVAILABILITY GROUP. Met deze instelling kan de beschikbaarheidsgroep de database maken en automatisch beginnen met het seeden van de database vanaf de primaire replica.

In dit voorbeeld worden de volgende opdrachten uitgevoerd op de secundaire replica, server2om lid te worden van de ag1 beschikbaarheidsgroep. De beschikbaarheidsgroep is vervolgens toegestaan om databases op de secundaire database te maken.

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

Opmerking

Wanneer de beschikbaarheidsgroep een database maakt op een secundaire replica, wordt de eigenaar van de database ingesteld als het account dat de ALTER AVAILABILITY GROUP instructie heeft uitgevoerd om machtigingen te verlenen voor het maken van een database. Voor volledige informatie, zie Verleen database-aanmaakmachtiging op secundaire replica aan beschikbaarheidsgroep.

Een listener maken voor de primaire beschikbaarheidsgroep

Voeg vervolgens een listener toe voor de primaire beschikbaarheidsgroep op de eerste WSFC. In dit voorbeeld heeft de listener de naam ag1-listener. Zie Een listener voor beschikbaarheidsgroepen maken of configureren (SQL Server) voor gedetailleerde instructies voor het maken van een listener.

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

Tweede beschikbaarheidsgroep maken

Maak vervolgens op de tweede WSFC een tweede beschikbaarheidsgroep. ag2 In dit geval wordt de database niet opgegeven, omdat deze automatisch wordt gezaaid vanuit de primaire beschikbaarheidsgroep. De primaire replica van de secundaire beschikbaarheidsgroep wordt de doorstuurserver genoemd in een gedistribueerde beschikbaarheidsgroep. In dit voorbeeld is server3 de doorstuurserver.

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

Opmerking

De secundaire beschikbaarheidsgroep moet hetzelfde eindpunt voor databasespiegeling gebruiken (in dit voorbeeld poort 5022). Anders stopt de replicatie na een lokale failover.
De onderliggende beschikbaarheidsgroepen moeten zich in dezelfde beschikbaarheidsmodus bevinden: beide beschikbaarheidsgroepen moeten zich in de synchrone doorvoermodus bevinden of beide moeten zich in de asynchrone doorvoermodus bevinden. Als u niet zeker weet welke bewerking moet worden gebruikt, stelt u beide in op de asynchrone doorvoermodus totdat u klaar bent om een failover uit te voeren.

De secundaire replica's koppelen aan de secundaire beschikbaarheidsgroep

In dit voorbeeld worden de volgende opdrachten uitgevoerd op de secundaire replica, server4om lid te worden van de ag2 beschikbaarheidsgroep. De beschikbaarheidsgroep mag vervolgens databases op de secundaire maken ter ondersteuning van automatische seeding.

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

Een listener maken voor de secundaire beschikbaarheidsgroep

Voeg vervolgens een listener toe voor de secundaire beschikbaarheidsgroep op de tweede WSFC. In dit voorbeeld heeft de listener de naam ag2-listener. Zie Een listener voor beschikbaarheidsgroepen maken of configureren (SQL Server) voor gedetailleerde instructies voor het maken van een listener.

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

Gedistribueerde beschikbaarheidsgroep maken op het eerste cluster

Maak op de eerste WSFC een gedistribueerde beschikbaarheidsgroep (in dit voorbeeld genoemd distributedAG ). Gebruik de opdracht CREATE AVAILABILITY GROUP met de optie DISTRIBUTED . De parameter AVAILABILITY GROUP ON specificeert de beschikbaarheidsgroepen ag1 voor leden en ag2.

Automatisch zaaien
Handmatige seeding

Gebruik de volgende Transact-SQL code om uw gedistribueerde beschikbaarheidsgroep te maken met behulp van automatische seeding:

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

Gebruik de volgende Transact-SQL code om uw gedistribueerde beschikbaarheidsgroep te maken met behulp van handmatige seeding:

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

Opmerking

De LISTENER_URL geeft de listener voor elke beschikbaarheidsgroep op, samen met het eindpunt voor databasespiegeling van de beschikbaarheidsgroep. In dit voorbeeld is dat de poort 5022 (niet de poort 60173 die wordt gebruikt om de listener te maken). Als u een load balancer gebruikt, bijvoorbeeld in Azure, voegt u een taakverdelingsregel toe voor de poort van de gedistribueerde beschikbaarheidsgroep. Voeg de regel voor de listenerpoort toe, naast de poort van de SQL Server-instantie.

Automatische seeding naar doorstuurserver annuleren

Als het om welke reden dan ook nodig is om de initialisatie van de doorstuurserver te annuleren voordat de twee beschikbaarheidsgroepen worden gesynchroniseerd, wijzigt u de gedistribueerde beschikbaarheidsgroep door de SEEDING_MODE parameter van de doorstuurserver in te stellen op HANDMATIG en de seeding onmiddellijk te annuleren. Voer de opdracht uit op de globale primaire:

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

Lid worden van gedistribueerde beschikbaarheidsgroep op het tweede cluster

Voeg vervolgens de gedistribueerde beschikbaarheidsgroep toe aan de tweede WSFC.

Automatisch zaaien
Handmatige seeding

Gebruik de volgende Transact-SQL code om deel te nemen aan uw gedistribueerde beschikbaarheidsgroep met behulp van automatische seeding:

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

Als u wilt deelnemen aan uw gedistribueerde beschikbaarheidsgroep met behulp van handmatige seeding, gebruikt u de volgende Transact-SQL code:

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

Als handmatig seeding wordt gebruikt om de database op de doorstuurserver te maken, voert u een volledige back-up en een back-up van het transactielogboek van de globale primaire server uit en herstelt u deze op de doorstuurserver met de NORECOVERY-optie. Voorbeeld:

Volg de volgende stappen om een back-up te maken van de wereldwijde primaire server:

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

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

Ga als volgende te werk om terug te zetten naar de doorstuurserver:

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

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

Voer daarna het volgende uit op de doorstuurserver:

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

De database toevoegen aan de secundaire beschikbaarheidsgroep

Als de tweede beschikbaarheidsgroep is ingesteld voor het gebruik van automatische seeding, gaat u naar stap 2.

Als de tweede beschikbaarheidsgroep handmatige seeding gebruikt, herstelt u de back-up die u op de globale primaire node hebt gemaakt naar de secundaire node van de tweede beschikbaarheidsgroep.
```
RESTORE DATABASE [db1] FROM DISK = '<full backup location>'
    WITH NORECOVERY;

RESTORE LOG [db1] FROM DISK = '<log backup location>'
    WITH NORECOVERY;
```
Nadat de database op de secundaire replica van de tweede beschikbaarheidsgroep de herstelstatus heeft, moet u deze handmatig toevoegen aan de beschikbaarheidsgroep.
```
ALTER DATABASE [db1]
    SET HADR AVAILABILITY GROUP = [ag2];
```

Failover bij een gedistribueerde beschikbaarheidsgroep

Omdat SQL Server 2022 (16.x) ondersteuning voor gedistribueerde beschikbaarheidsgroepen voor de REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT instelling heeft geïntroduceerd, zijn instructies voor het uitvoeren van een failover van een gedistribueerde beschikbaarheid anders voor SQL Server 2022 en latere versies dan voor SQL Server 2019 en eerdere versies.

Voor een gedistribueerde beschikbaarheidsgroep is het enige ondersteunde failovertype een handmatig door de gebruiker geïnitieerd FORCE_FAILOVER_ALLOW_DATA_LOSS. Om gegevensverlies te voorkomen, moet u daarom extra stappen uitvoeren (in deze sectie beschreven) om ervoor te zorgen dat gegevens tussen de twee replica's worden gesynchroniseerd voordat de failover wordt gestart.

In het geval van een noodgeval waarbij gegevensverlies acceptabel is, kunt u een failover initiëren zonder ervoor te zorgen dat gegevenssynchronisatie wordt uitgevoerd:

ALTER AVAILABILITY GROUP distributedAG FORCE_FAILOVER_ALLOW_DATA_LOSS;

U kunt dezelfde opdracht gebruiken om een failover uit te voeren naar de doorstuurserver, evenals een failback naar de globale primaire.

SQL Server 2022 en hoger
SQL Server 2019 en eerder

Op SQL Server 2022 (16.x) en hoger kunt u de REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT instelling configureren voor een gedistribueerde beschikbaarheidsgroep, die is ontworpen om geen gegevensverlies te garanderen wanneer een gedistribueerde beschikbaarheidsgroep een failover-overschakeling uitvoert. Als deze instelling is geconfigureerd, volgt u de stappen in deze sectie om een failover uit te voeren voor uw gedistribueerde beschikbaarheidsgroep. Als u de REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT instelling niet wilt gebruiken, volgt u de instructies om een failover uit te voeren voor een gedistribueerde beschikbaarheidsgroep in SQL Server 2019 en eerder.

Opmerking

Instelling REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT op 1 betekent dat de primaire replica wacht tot transacties worden doorgevoerd op de secundaire replica voordat ze worden doorgevoerd op de primaire replica, wat de prestaties kan verminderen. Hoewel het beperken of stoppen van transacties op de globale primaire server niet vereist is voor de gedistribueerde beschikbaarheidsgroep om te synchroniseren in SQL Server 2022 (16.x), kan dit de prestaties verbeteren voor zowel gebruikerstransacties als synchronisatie van gedistribueerde beschikbaarheidsgroepen met REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT ingesteld op 1.

Stappen om ervoor te zorgen dat er geen gegevensverlies is

Om ervoor te zorgen dat er geen gegevensverlies is, moet u eerst de gedistribueerde beschikbaarheidsgroep configureren om geen gegevensverlies te ondersteunen door de volgende stappen uit te voeren:

Controleer of de mondiale primaire en doorstuurserver in de modus SYNCHRONOUS_COMMIT staan om de failover voor te bereiden. Als dat niet zo is, stelt u deze in met SYNCHRONOUS_COMMIT ALTER AVAILABILITY GROUP.
Stel de gedistribueerde beschikbaarheidsgroep in op synchrone doorvoer op zowel de globale primaire als de doorstuurserver.
Wacht totdat de gedistribueerde beschikbaarheidsgroep is gesynchroniseerd.
Stel op de algemene primaire locatie de instelling voor de gedistribueerde beschikbaarheidsgroep REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT in op 1 met behulp van ALTER AVAILABILITY GROUP.
Controleer of alle replica's in de lokale AG's en de gedistribueerde beschikbaarheidsgroep gezond zijn en dat de gedistribueerde beschikbaarheidsgroep GESYNCHRONISEERD is.
Stel op de globale primaire replica de rol voor de SECONDARY-gedistribueerde beschikbaarheidsgroep in, dit maakt de gedistribueerde beschikbaarheidsgroep onbeschikbaar.
Voer een failover uit van de gedistribueerde beschikbaarheidsgroep op de doorstuurserver (de beoogde nieuwe primaire) door gebruik te maken van ALTER AVAILABILITY GROUP met FORCE_FAILOVER_ALLOW_DATA_LOSS.
Stel op de nieuwe secundaire (de vorige globale primaire replica) de gedistribueerde beschikbaarheidsgroep REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT in op 0.
Optioneel: Als de beschikbaarheidsgroepen zich op een geografische afstand bevinden die latentie veroorzaakt, wijzigt u de beschikbaarheidsmodus in ASYNCHRONOUS_COMMIT. Hiermee wordt de wijziging van de eerste stap teruggezet, indien nodig.

T-SQL-voorbeeld

Deze sectie biedt de stappen in een gedetailleerd voorbeeld om een failover uit te voeren voor de gedistribueerde beschikbaarheidsgroep genaamd distributedAG door gebruik te maken van Transact-SQL. De voorbeeldomgeving heeft in totaal vier knooppunten voor de gedistribueerde beschikbaarheidsgroep. De globale primaire N1 en N2 host-beschikbaarheidsgroep ag1, terwijl de N3 en N4 doorstuur-hostbeschikbaarheidsgroep ag2. De gedistribueerde beschikbaarheidsgroep distributedAG pusht wijzigingen van ag1 naar ag2.

Voer een query uit om SYNCHRONOUS_COMMIT te verifiëren op de primaries van de lokale beschikbaarheidsgroepen die de gedistribueerde beschikbaarheidsgroep vormen. Voer de volgende T-SQL rechtstreeks uit op de doorstuurserver en de globale primaire server:

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

Stel de gedistribueerde beschikbaarheidsgroep in op synchrone doorvoer door de volgende code uit te voeren op zowel de globale primaire als de doorstuurserver:
```
 -- 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);
```
Opmerking

In een gedistribueerde beschikbaarheidsgroep is de synchronisatiestatus tussen de twee beschikbaarheidsgroepen afhankelijk van de beschikbaarheidsmodus van beide replica's. Voor de synchrone doorvoermodus moeten zowel de huidige primaire beschikbaarheidsgroep als de huidige secundaire beschikbaarheidsgroep de beschikbaarheidsmodus hebben SYNCHRONOUS_COMMIT . Daarom moet u dit script uitvoeren op zowel de globale primaire replica als de doorstuurserver.

Wacht totdat de status van de gedistribueerde beschikbaarheidsgroep is gewijzigd in SYNCHRONIZED. Voer de volgende query uit op de globale primaire:

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

Ga door nadat de beschikbaarheidsgroep synchronization_state_desc is SYNCHRONIZED.

Voor SQL Server 2022 (16.x) en hoger, stel op de globale primaire REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT in op 1 met behulp van de volgende T-SQL:
```
ALTER AVAILABILITY GROUP distributedAG SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);
```

Controleer of uw beschikbaarheidsgroepen in orde zijn op alle replica's door een query uit te voeren op de globale primaire en de doorstuurserver:

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

Stel de rol gedistribueerde beschikbaarheidsgroep in op de globale primaire.SECONDARY Op dit moment is de gedistribueerde beschikbaarheidsgroep niet beschikbaar. Nadat deze stap is voltooid, kunt u geen failback uitvoeren totdat de rest van de stappen worden uitgevoerd.
```
ALTER AVAILABILITY GROUP distributedAG SET (ROLE = SECONDARY);
```
Voer een failover uit vanaf de globale primaire server door de volgende query uit te voeren op de doorstuurserver om de beschikbaarheidsgroepen over te zetten en de gedistribueerde beschikbaarheidsgroep weer online te brengen:
```
-- 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;
```
Na deze stap:
- De globale primaire overgang van N1 naar N3.
- De doorstuurserver gaat over van N3 naar N1.
- De gedistribueerde beschikbaarheidsgroep is beschikbaar.
Schakel op de nieuwe forwarder (vorige globale primaire N1) de eigenschap van de gedistribueerde beschikbaarheidsgroep REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT uit door deze in te stellen op 0:
```
ALTER AVAILABILITY GROUP distributedAG SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0);
```
OPTIONEEL: Als de beschikbaarheidsgroepen zich op een geografische afstand bevinden die latentie veroorzaakt, kunt u overwegen om de beschikbaarheidsmodus weer te ASYNCHRONOUS_COMMIT wijzigen op zowel de globale primaire als de doorstuurserver. Hiermee wordt de wijziging die in de eerste stap is aangebracht, teruggezet, indien nodig.
```
 -- 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);
```

De instructies in deze sectie zijn van toepassing als REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT deze niet zijn ingesteld voor de gedistribueerde beschikbaarheidsgroep, zoals versies vóór SQL Server 2022 (16.x), omdat deze niet worden ondersteund voor gedistribueerde beschikbaarheidsgroepen.

Stappen om ervoor te zorgen dat er geen gegevensverlies is

Volg deze stappen om ervoor te zorgen dat er geen gegevensverlies is:

Stop alle transacties die worden uitgevoerd op de globale primaire beschikbaarheidsgroepdatabase(s).
Controleer of de globale hoofdserver en doorstuurserver zich in de SYNCHRONOUS_COMMIT modus bevinden. Als dat niet zo is, stelt u deze in met SYNCHRONOUS_COMMIT ALTER AVAILABILITY GROUP.
Stel de gedistribueerde beschikbaarheidsgroep in op synchrone doorvoer op de globale primaire en de doorstuurserver.
Wacht totdat de gedistribueerde beschikbaarheidsgroep is gesynchroniseerd en dezelfde last_hardened_lsn per database heeft. Wacht totdat de last_hardened_lsn per database overeenkomt tussen replica's.
Stel op de globale primaire replica de rol voor de SECONDARY-gedistribueerde beschikbaarheidsgroep in, dit maakt de gedistribueerde beschikbaarheidsgroep onbeschikbaar.
Test de failovergereedheid door te controleren of de last_hardened_lsn-waarden hetzelfde zijn op de globale primaire server en de doorstuurserver. Als ze niet overeenkomen, voert u een failback uit naar de algemene primaire server en start u het proces opnieuw vanaf de eerste stap.
Schakel de primaire beschikbaarheidsgroep over door gebruik te maken van ALTER AVAILABILITY GROUP met FORCE_FAILOVER_ALLOW_DATA_LOSS.
Optioneel: Als de beschikbaarheidsgroepen zich op een geografische afstand bevinden die latentie veroorzaakt, wijzigt u de beschikbaarheidsmodus weer in ASYNCHRONOUS_COMMIT.

T-SQL-voorbeeld

Als u ervoor wilt zorgen dat er geen gegevens verloren gaan, stopt u alle transacties op de globale primaire databases (dat wil gezegd databases van de primaire beschikbaarheidsgroep).

Voer een query uit om SYNCHRONOUS_COMMIT te verifiëren op de primaire exemplaren van de lokale beschikbaarheidsgroepen die samen de gedistribueerde beschikbaarheidsgroep vormen. Rechtstreeks uitvoeren op de doorstuurserver en de globale primaire server.

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

Stel de gedistribueerde beschikbaarheidsgroep in op synchrone doorvoer door de volgende code uit te voeren op zowel de globale primaire als de doorstuurserver:

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

Opmerking

In een gedistribueerde beschikbaarheidsgroep is de synchronisatiestatus tussen de twee beschikbaarheidsgroepen afhankelijk van de beschikbaarheidsmodus van beide replica's. Voor de synchrone doorvoermodus moeten zowel de huidige primaire beschikbaarheidsgroep als de huidige secundaire beschikbaarheidsgroep de beschikbaarheidsmodus hebben SYNCHRONOUS_COMMIT . Daarom moet u dit script uitvoeren op zowel de globale primaire replica als de doorstuurserver.

Wacht totdat de status van de gedistribueerde beschikbaarheidsgroep is gewijzigd naar SYNCHRONIZED en alle replica's dezelfde last_hardened_lsn hebben (per database). Voer de volgende query uit zowel op de globale primaire replica van de primaire beschikbaarheidsgroep als op de doorstuurserver om de synchronization_state_desc en last_hardened_lsn te controleren.
```
-- 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');
```
Ga door nadat de beschikbaarheidsgroep synchronization_state_desc is SYNCHRONIZEDen de last_hardened_lsn hetzelfde is per database op zowel de globale primaire als de doorstuurserver. Als synchronization_state_desc niet SYNCHRONIZED of last_hardened_lsn niet hetzelfde is, voert u de opdracht om de vijf seconden uit totdat deze wordt gewijzigd. Als u gegevensverlies wilt voorkomen, gaat u pas verder als de synchronization_state_desc = SYNCHRONIZED en last_hardened_lsn hetzelfde zijn per database.
Stel op de globale primaire server de rol van de gedistribueerde beschikbaarheidsgroep in op SECONDARY:
```
ALTER AVAILABILITY GROUP distributedAG SET (ROLE = SECONDARY);
```
Op dit moment is de gedistribueerde beschikbaarheidsgroep niet beschikbaar.
Test de failovergereedheid. Voer de SELECT-query opnieuw uit om de last_hardened_lsn (per database) te controleren op zowel de globale primaire als de doorstuurserver. Controleer of de last_hardened_lsn van alle databases overeenkomt tussen de globale primaire server en de doorstuurserver.
Afhankelijk van het resultaat van de vorige stap varieert de volgende stap.
- Als de last_hardened_lsns overeenkomen met de SELECT-query , voert u een failover uit van de primaire beschikbaarheidsgroep naar de secundaire beschikbaarheidsgroep. Voer de opdracht ALTER AVAILABILITY GROUP uit op de doorstuurserver, de SQL Server die als host fungeert voor de primaire replica van de secundaire beschikbaarheidsgroep.
- Als de last_hardened_lsns na enige tijd niet overeenkomen met de SELECT-query, voert u de gedistribueerde beschikbaarheidsgroep terug naar de oorspronkelijke doorstuurserver (N1) door de failover-opdracht uit te voeren op de globale primaire. Start vervolgens het proces opnieuw vanaf de eerste stap.
```
-- 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;
```
Na deze stap is de gedistribueerde beschikbaarheidsgroep beschikbaar.
OPTIONEEL: Als de beschikbaarheidsgroepen zich na een geslaagde failover op een geografische afstand bevinden die latentie ondervindt, kunt u overwegen om de beschikbaarheidsmodus weer te wijzigen om ASYNCHRONOUS_COMMIT de eerder aangebrachte wijziging te herstellen.
```
 -- 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);
```

Na het voltooien van deze stappen voert de gedistribueerde beschikbaarheidsgroep een failover uit zonder gegevensverlies.

Een gedistribueerde beschikbaarheidsgroep verwijderen

Met de volgende Transact-SQL instructie wordt een gedistribueerde beschikbaarheidsgroep met de naam distributedAGverwijderd:

DROP AVAILABILITY GROUP distributedAG;

Gedistribueerde beschikbaarheidsgroep maken op failoverclusterexemplaren

U kunt een gedistribueerde beschikbaarheidsgroep maken met behulp van een beschikbaarheidsgroep op een failoverclusterexemplaar (FCI). In dit geval hebt u geen listener voor een beschikbaarheidsgroep nodig. Gebruik de naam van het virtuele netwerk (VNN) voor de primaire replica van het FCI-exemplaar. In het volgende voorbeeld ziet u een gedistribueerde beschikbaarheidsgroep met de naam SQLFCIDAG. Eén beschikbaarheidsgroep is SQLFCIAG. SQLFCIAG heeft twee FCI-replica's. De VNN voor de primaire FCI-replica is SQLFCIAG-1 en de VNN voor de secundaire FCI-replica is SQLFCIAG-2. De gedistribueerde beschikbaarheidsgroep bevat ook SQLAG-DR voor herstel na noodgevallen.

Diagram van een gedistribueerde AlwaysOn-beschikbaarheidsgroep.

Met de volgende DDL wordt deze gedistribueerde beschikbaarheidsgroep gemaakt:

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

De listener-URL-adres is de VNN van de primaire FCI-instantie.

Handmatig een failover van FCI uitvoeren in een gedistribueerde beschikbaarheidsgroep

Als u handmatig een failover wilt uitvoeren voor de FCI-beschikbaarheidsgroep, werkt u de gedistribueerde beschikbaarheidsgroep bij zodat deze overeenkomt met de wijziging van de listener-URL. Voer bijvoorbeeld de volgende DDL uit op zowel de globale primaire server als de doorstuurcomponent van de gedistribueerde AG van SQLFCIDAG.

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

Feedback

Is deze pagina nuttig?

Delen via

Een gedistribueerde AlwaysOn-beschikbaarheidsgroep configureren

Vereiste voorwaarden

Machtigingen

Stel de eindpunten voor databasespiegeling in om te luisteren op alle IP-adressen

Een eindpunt voor databasespiegeling maken om te luisteren op alle IP-adressen

Een bestaand database-mirroring-eindpunt wijzigen zodat het luistert naar alle IP-adressen

Eerste beschikbaarheidsgroep maken

De primaire beschikbaarheidsgroep op het eerste cluster maken

Verbind de secundaire replica's met de primaire beschikbaarheidsgroep

Een listener maken voor de primaire beschikbaarheidsgroep

Tweede beschikbaarheidsgroep maken

De secundaire replica's koppelen aan de secundaire beschikbaarheidsgroep

Een listener maken voor de secundaire beschikbaarheidsgroep

Gedistribueerde beschikbaarheidsgroep maken op het eerste cluster

Automatische seeding naar doorstuurserver annuleren

Lid worden van gedistribueerde beschikbaarheidsgroep op het tweede cluster

De database toevoegen aan de secundaire beschikbaarheidsgroep

Failover bij een gedistribueerde beschikbaarheidsgroep

Stappen om ervoor te zorgen dat er geen gegevensverlies is

T-SQL-voorbeeld

Een gedistribueerde beschikbaarheidsgroep verwijderen

Gedistribueerde beschikbaarheidsgroep maken op failoverclusterexemplaren

Handmatig een failover van FCI uitvoeren in een gedistribueerde beschikbaarheidsgroep

Verwante inhoud

Feedback

Aanvullende resources