Configurer un groupe de disponibilité distribué Always On

S'applique à :SQL Server

Pour créer un groupe de disponibilité distribué, vous devez créer deux groupes de disponibilité ayant chacun son propre écouteur. Vous combinez ensuite ces groupes de disponibilité dans un groupe de disponibilité distribué. Les étapes suivantes fournissent un exemple de base dans Transact-SQL. Cet exemple ne couvre pas tous les détails de la création des groupes de disponibilité et des écouteurs. Son but est de mettre en évidence les exigences principales.

Pour obtenir une présentation technique des groupes de disponibilité distribués, consultez Groupes de disponibilité distribués.

Prérequis

Pour configurer un groupe de disponibilité distribué, vous devez disposer des éléments suivants :

• Version prise en charge de SQL Server.

Remarque

Si vous avez configuré l’écouteur de votre groupe de disponibilité sur votre SQL Server sur une machine virtuelle Azure à l’aide d’un nom de réseau distribué (DNN), la configuration d’un groupe de disponibilité distribué au-dessus de votre groupe de disponibilité n’est pas prise en charge. Pour en savoir plus, consultez Interopérabilité de la fonctionnalité de SQL Server sur une machine virtuelle Azure avec un groupe de disponibilité et un écouteur DNN.

Définir les écouteurs de point de terminaison pour écouter toutes les adresses IP

Vérifiez que les points de terminaison peuvent communiquer entre les différents groupes de disponibilité du groupe de disponibilité distribué. Si un groupe de disponibilité est défini sur un réseau spécifique sur le point de terminaison, le groupe de disponibilité distribué ne fonctionne pas correctement. Sur chaque serveur qui héberge un réplica dans le groupe de disponibilité distribué, définissez l’écouteur pour qu’il écoute sur toutes les adresses IP (LISTENER_IP = ALL).

Créer un point de terminaison pour écouter toutes les adresses IP

Par exemple, le script suivant crée un point de terminaison d’écouteur sur le port TCP 5022 qui écoute sur toutes les adresses IP.

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

Modifier un point de terminaison pour écouter toutes les adresses IP

Par exemple, le script suivant modifie un point de terminaison d’écouteur pour qu’il écoute sur toutes les adresses IP.

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

Créer un premier groupe de disponibilité

Créer le groupe de disponibilité principal sur le premier cluster

Créer un groupe de disponibilité sur le premier cluster de basculement Windows Server (WSFC). Dans cet exemple, le groupe de disponibilité est nommé ag1 pour la base de données db1. Le réplica principal du groupe de disponibilité principal est appelé principal global dans un groupe de disponibilité distribué. Dans cet exemple, Server1 est le principal global.

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

Remarque

L’exemple précédent utilise un amorçage automatique, où SEEDING_MODE a la valeur AUTOMATIC pour les réplicas et le groupe de disponibilité distribué. Cette configuration définit les réplicas secondaires et le groupe de disponibilité secondaire pour qu’ils soient renseignés automatiquement sans qu’une sauvegarde manuelle et une restauration de base de données primaire soient nécessaires.

Joindre les réplicas secondaires au groupe de disponibilité principal

Les réplicas secondaires doivent être joints au groupe de disponibilité ALTER AVAILABILITY GROUP avec l’option JOIN . Étant donné que l’amorçage automatique est utilisé dans cet exemple, vous devez également appeler ALTER AVAILABILITY GROUP avec l’option GRANT CREATE ANY DATABASE. Ainsi, le groupe de disponibilité peut créer la base de données et commencer l’amorçage automatique à partir du réplica principal.

Dans cet exemple, les commandes suivantes sont exécutées sur le réplica secondaire server2pour rejoindre le groupe de disponibilité ag1 . Le groupe de disponibilité est ensuite autorisé à créer des bases de données sur le réplica secondaire.

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

Remarque

Quand le groupe de disponibilité crée une base de données sur un réplica secondaire, il définit le propriétaire de la base de données en tant que compte qui a exécuté l’instruction ALTER AVAILABILITY GROUP pour accorder l’autorisation de créer une base de données. Pour plus d’informations, consultez Octroyer l’autorisation de créer une base de données sur un réplica secondaire au groupe de disponibilité.

Créer un écouteur pour le groupe de disponibilité principal

Ajoutez ensuite un écouteur pour le groupe de disponibilité principal sur le premier cluster WSFC. Dans cet exemple, l’écouteur est nommé ag1-listener. Pour obtenir des instructions détaillées sur la création d’un écouteur, consultez Créer ou configurer un écouteur de groupe de disponibilité (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

Créer un second groupe de disponibilité

Puis, sur le deuxième cluster WSFC, créez un deuxième groupe de disponibilité ag2. Dans ce cas, la base de données n’est pas spécifiée, car elle est automatiquement initialisée à partir du groupe de disponibilité principal. Le réplica principal du groupe de disponibilité secondaire est appelé redirecteur dans un groupe de disponibilité distribué. Dans cet exemple, server3 est le redirecteur.

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

Remarque

Le groupe de disponibilité secondaire doit utiliser le même point de terminaison de mise en miroir de bases de données (le port 5022 dans l’exemple). Sinon, la réplication s’arrête après un basculement local.

Joindre les réplicas secondaires au groupe de disponibilité secondaire

Dans cet exemple, les commandes suivantes sont exécutées sur le réplica secondaire server4pour rejoindre le groupe de disponibilité ag2 . Le groupe de disponibilité est ensuite autorisé à créer des bases de données sur le réplica secondaire pour prendre en charge l’amorçage automatique.

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

Créer un écouteur pour le groupe de disponibilité secondaire

Ajoutez ensuite un écouteur au groupe de disponibilité secondaire sur le deuxième cluster WSFC. Dans cet exemple, l’écouteur est nommé ag2-listener. Pour obtenir des instructions détaillées sur la création d’un écouteur, consultez Créer ou configurer un écouteur de groupe de disponibilité (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

Créer un groupe de disponibilité distribué sur le premier cluster

Sur le premier cluster WSFC, créez un groupe de disponibilité distribué (nommé distributedAG dans cet exemple). Utilisez la commande CREATE AVAILABILITY GROUP avec l’option DISTRIBUTED . Le paramètre AVAILABILITY GROUP ON spécifie les groupes de disponibilité membres ag1 et ag2.

Amorçage automatique

Pour créer votre groupe de disponibilité distribué à l’aide de l’amorçage automatique, utilisez le code Transact-SQL suivant :

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

Amorçage manuel

Pour créer votre groupe de disponibilité distribué à l’aide de l’amorçage manuel, utilisez le code Transact-SQL suivant :

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

Remarque

LISTENER_URL spécifie l’écouteur pour chaque groupe de disponibilité, ainsi que le point de terminaison de mise en miroir de bases de données du groupe de disponibilité. Dans cet exemple, il s’agit du port 5022 (et non du port 60173 qui a permis de créer l’écouteur). Si vous utilisez un équilibreur de charge, par exemple dans Azure, ajoutez une règle d’équilibrage de charge pour le port du groupe de disponibilité distribué. Ajoutez la règle pour le port d’écoute, en plus du port de l’instance SQL Server.

Annuler l’amorçage automatique du redirecteur

Si, pour une raison ou une autre, il est nécessaire d’annuler l’initialisation du redirecteur avant que les deux groupes de disponibilité soient synchronisés, modifiez le groupe de disponibilité distribué avec ALTER en définissant le paramètre SEEDING_MODE du redirecteur sur MANUAL et annulez immédiatement l’amorçage. Exécutez la commande sur la base de données 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 ​ ); ​

Joindre un groupe de disponibilité distribué sur le second cluster

Joignez ensuite le groupe de disponibilité distribué au deuxième cluster WSFC.

Amorçage automatique

Pour rejoindre votre groupe de disponibilité distribué à l’aide de l’amorçage automatique, utilisez le code Transact-SQL suivant :

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

Amorçage manuel

Pour rejoindre votre groupe de disponibilité distribué à l’aide de l’amorçage manuel, utilisez le code Transact-SQL suivant :

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

Si l’amorçage manuel est utilisé pour créer la base de données sur le redirecteur, effectuez une sauvegarde complète et une sauvegarde du journal des transactions à partir du serveur principal global, puis restaurez-les sur le redirecteur avec l’option NONRECOVERY. Exemple :

Pour sauvegarder sur le serveur principal global :

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

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

Pour effectuer une restauration sur le redirecteur :

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

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

Après cela, exécutez ce qui suit sur le transmetteur :

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

Joindre la base de données sur le réplica secondaire du deuxième groupe de disponibilité

Si le deuxième groupe de disponibilité a été configuré pour utiliser l’amorçage automatique, passez à l’étape 2.

1. Si le deuxième groupe de disponibilité utilise l’amorçage manuel, restaurez la sauvegarde que vous avez effectuée sur le principal global sur le secondaire du deuxième groupe de disponibilité :

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

2. Quand la base de données qui se trouve sur le réplica secondaire du deuxième groupe de disponibilité est en restauration, vous devez la joindre manuellement au groupe de disponibilité.

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

Basculer un groupe de disponibilité distribué

Depuis que SQL Server 2022 (16.x) a introduit la prise en charge des groupes de disponibilité distribuée pour le paramètre REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT, les instructions pour basculer sur une disponibilité distribuée sont différentes pour SQL Server 2022 et les versions ultérieures que pour SQL Server 2019 et les versions antérieures.

Pour un groupe de disponibilité distribué, le seul type de basculement pris en charge est un basculement manuel initié par l'utilisateur FORCE_FAILOVER_ALLOW_DATA_LOSS. Par conséquent, pour éviter toute perte de données, vous devez prendre des mesures supplémentaires (décrites en détail dans cette section) pour vous assurer que les données sont synchronisées entre les deux réplicas avant d'initier le basculement.

En cas d'urgence, lorsque la perte de données est acceptable, vous pouvez lancer un basculement sans assurer la synchronisation de données :

ALTER AVAILABILITY GROUP distributedAG FORCE_FAILOVER_ALLOW_DATA_LOSS;

Vous pouvez utiliser la même commande pour basculer vers le redirecteur, ainsi que pour basculer vers le réplica principal global.

SQL Server 2022 et versions ultérieures

Sur SQL Server 2022 (16.x) et les versions ultérieures, vous pouvez configurer le paramètre REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT pour un groupe de disponibilité distribué, qui est conçu pour garantir la non perte de données en cas de défaillance d'un groupe de disponibilité distribué. Si ce paramètre est configuré, suivez les étapes de cette section pour basculer votre groupe de disponibilité distribué. Si vous ne souhaitez pas utiliser le paramètre REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT, suivez les instructions pour basculer sur un groupe de disponibilité distribué dans SQL Server 2019 et les versions antérieures.

Remarque

Définir REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT à 1 signifie que le réplica principal attend que les transactions soient validées sur le réplica secondaire avant qu’elles ne soient validées sur le réplica principal, ce qui peut dégrader les performances. Bien que la limitation ou l’arrêt des transactions sur le principal global n’est pas nécessaire pour que le groupe de disponibilité distribué se synchronise dans SQL Server 2022 (16.x), cela peut améliorer les performances pour les transactions utilisateur et la synchronisation de groupe de disponibilité distribué avec REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT défini sur 1.

Étapes pour vous assurer qu’il n’y a aucune perte de données

Pour vous assurer qu’il n’existe aucune perte de données, vous devez d’abord configurer le groupe de disponibilité distribué pour qu’il ne supporte aucune perte de données en procédant comme suit :

1. Pour préparer le basculement, vérifiez que le principal global et le redirecteur global sont en mode SYNCHRONOUS_COMMIT. Si ce n’est pas le cas, définissez-les sur SYNCHRONOUS_COMMIT en utilisant ALTER AVAILABILITY GROUP.
2. Définissez le groupe de disponibilité distribué sur la validation synchrone sur à la fois le principal global et le redirecteur.
3. Attendez que le groupe de disponibilité distribué soit synchronisé.
4. Sur le principal global, définissez le paramètre REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT du groupe de disponibilité distribué sur 1 en utilisant ALTER AVAILABILITY GROUP.
5. Vérifiez que tous les réplicas dans les groupes de disponibilité locaux et le groupe de disponibilité distribué sont intègres et que ce dernier est SYNCHRONISÉ.
6. Sur le réplica principal global, définissez le rôle du groupe de disponibilité distribué sur SECONDARY, ce qui rend le groupe de disponibilité distribué indisponible.
7. Sur le redirecteur (le nouveau principal prévu), basculez le groupe de disponibilité distribué à l'aide de ALTER AVAILABILITY GROUP avec FORCE_FAILOVER_ALLOW_DATA_LOSS.
8. Sur la nouvelle réplique secondaire (l'ancienne réplique principale globale), paramétrez le groupe de disponibilité distribué REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT à 0.
9. Facultatif : si les groupes de disponibilité se trouvent sur une distance géographique qui provoque une latence, remplacez le mode de disponibilité par ASYNCHRONOUS_COMMIT. Cela annule la modification de la première étape, si nécessaire.

Exemple T-SQL

Cette section fournit les étapes d'un exemple détaillé de basculement du groupe de disponibilité distribué nommé distributedAG à l’aide de Transact-SQL. L’exemple d’environnement a un total de 4 nœuds pour le groupe de disponibilité distribué. Le principal global N1 et N2 hébergent le groupe de disponibilité ag1, tandis que le principal global N3 et N4ag2 héberge le groupe de disponibilité . Le groupe de disponibilité distribué distributedAG envoie les modifications de ag1 à ag2.

1. Requête pour vérifier SYNCHRONOUS_COMMIT sur les principaux des groupes de disponibilité locaux qui forment le groupe de disponibilité distribué. Exécutez le T-SQL suivant directement sur le redirecteur global et principal global :

   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. Définissez le groupe de disponibilité distribué sur la validation synchrone en exécutant le code suivant sur à la fois le principal global et le redirecteur :

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

   Remarque

   Dans un groupe de disponibilité distribué, l’état de synchronisation entre les deux groupes de disponibilité dépend du mode de disponibilité des deux réplicas. Pour le mode de validation synchrone, le groupe de disponibilité principal et le groupe de disponibilité secondaire doivent tous deux présenter le mode de disponibilité SYNCHRONOUS_COMMIT. Pour cette raison, vous devez exécuter ce script à la fois sur le réplica principal global et sur le redirecteur :

3. Attendez que l’état du groupe de disponibilité distribué passe à SYNCHRONIZED. Exécutez la requête suivante sur le principal global :

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

   Continuez une fois que le groupe de disponibilité synchronization_state_desc est SYNCHRONIZED.

4. Pour SQL Server 2022 (16.x) et versions ultérieures, sur le primaire global, définissez REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT sur 1 à l’aide du T-SQL suivant :

   ALTER AVAILABILITY GROUP distributedAG SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);
   

5. Vérifiez que vos groupes de disponibilité sont intègres sur tous les réplicas en interrogeant le principal global et le redirecteur :

   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. Sur le principal global, définissez le rôle du groupe de disponibilité distribué sur SECONDARY. À ce stade, le groupe de disponibilité distribué n’est pas disponible. Une fois cette étape terminée, vous ne pouvez pas basculer tant que les autres étapes n’ont pas été effectuées.

   ALTER AVAILABILITY GROUP distributedAG SET (ROLE = SECONDARY);
   

7. Basculez à partir du principal global en exécutant la requête suivante sur le redirecteur pour transférer les groupes de disponibilité et réactiver le groupe de disponibilité distribué :

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

   Après cette étape :

   • Le principal global passe de N1 à N3.
   • Le redirecteur global passe de N3 à N1.
   • Le groupe de disponibilité distribué est disponible.

8. Sur le nouveau redirecteur (principal global précédent, N1), effacez la propriété du groupe de disponibilité distribué REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT en la définissant sur 0 :

   ALTER AVAILABILITY GROUP distributedAG SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0);
   

9. FACULTATIF : si les groupes de disponibilité se trouvent sur une distance géographique qui provoque une latence, envisagez de revenir au mode de disponibilité en ASYNCHRONOUS_COMMIT sur à la fois le principal global et le redirecteur. Cela rétablit la modification apportée à la première étape, si nécessaire.

    -- 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 et versions antérieures

Les instructions de cette section s'appliquent si REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT n'est pas défini pour le groupe de disponibilité distribué, comme les versions antérieures à SQL Server 2022 (16.x), car elles ne le prennent pas en charge pour les groupes de disponibilité distribués.

Étapes pour vous assurer qu’il n’y a aucune perte de données

Pour vous assurer qu’il n’y a aucune perte de données, procédez comme suit :

1. Arrêtez toutes les transactions en cours d’exécution sur les bases de données du groupe de disponibilité principal global.
2. Vérifiez que le primaire global et le redirecteur global sont en mode SYNCHRONOUS_COMMIT. Si ce n’est pas le cas, définissez-les sur SYNCHRONOUS_COMMIT en utilisant ALTER AVAILABILITY GROUP.
3. Définissez le groupe de disponibilité distribué sur la validation synchrone sur le principal global et le redirecteur.
4. Attendez que le groupe de disponibilité distribué soit synchronisé et présente le même last_hardened_lsn par base de données. Attendez que le last_hardened_lsn par base de données corresponde entre les réplicas.
5. Sur le réplica principal global, définissez le rôle du groupe de disponibilité distribué sur SECONDARY, ce qui rend le groupe de disponibilité distribué indisponible.
6. Testez la préparation du basculement en vérifiant que les valeurs last_hardened_lsn sont identiques sur le principal global et le redirecteur. Si elles ne correspondent pas, revenez au principal global et recommencez le processus à partir de la première étape.
7. Basculez le groupe de disponibilité principal à l’aide de ALTER AVAILABILITY GROUP avec FORCE_FAILOVER_ALLOW_DATA_LOSS.
8. Facultatif : si les groupes de disponibilité se trouvent sur une distance géographique qui provoque une latence, remplacez le mode de disponibilité par ASYNCHRONOUS_COMMIT.

Exemple T-SQL

Cette section fournit les étapes d'un exemple détaillé de basculement du groupe de disponibilité distribué nommé distributedAG à l’aide de Transact-SQL. L’exemple d’environnement a un total de 4 nœuds pour le groupe de disponibilité distribué. Le principal global N1 et N2 hébergent le groupe de disponibilité ag1, tandis que le principal global N3 et N4ag2 héberge le groupe de disponibilité . Le groupe de disponibilité distribué distributedAG transfère les modifications de ag1 à ag2.

1. Pour éviter toute perte de donnée, arrêtez toutes les transactions sur les bases de données primaires globales (c’est-à-dire les bases de données du groupe de disponibilité principal).

2. Requête pour vérifier SYNCHRONOUS_COMMIT sur les groupes de disponibilité locaux primaires qui composent le groupe de disponibilité distribué. Exécutez directement sur le transmetteur global et le serveur primaire global :

   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. Définissez le groupe de disponibilité distribué sur la validation synchrone en exécutant le code suivant sur à la fois le principal global et le redirecteur :

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

   Remarque

   Dans un groupe de disponibilité distribué, l’état de synchronisation entre les deux groupes de disponibilité dépend du mode de disponibilité des deux réplicas. Pour le mode de validation synchrone, le groupe de disponibilité principal et le groupe de disponibilité secondaire doivent tous deux présenter le mode de disponibilité SYNCHRONOUS_COMMIT. Pour cette raison, vous devez exécuter ce script à la fois sur le réplica principal global et sur le redirecteur :

4. Attendez que l’état du groupe de disponibilité distribué devienne SYNCHRONIZED et que tous les réplicas présentent le même last_hardened_lsn (par base de données). Exécutez la requête suivante sur le principal global (qui est le réplica principal du groupe de disponibilité principal) et le redirecteur pour vérifier synchronization_state_desc et last_hardened_lsn :

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

   Continuez dès lors que le groupe de disponibilité synchronization_state_desc est SYNCHRONIZED et que le last_hardened_lsn est le même par base de données à la fois sur le principal global et le redirecteur. Si synchronization_state_desc n’est pas SYNCHRONIZED ou last_hardened_lsn n’est pas identique, exécutez la commande toutes les cinq secondes jusqu’à ce qu’elle change. Pour éviter la perte de données, ne passez pas à l'étape suivante tant que les valeurs de synchronization_state_desc = SYNCHRONIZED et de last_hardened_lsn ne sont pas identiques pour chaque base de données.

5. Sur le principal global, définissez le rôle du groupe de disponibilité distribué sur SECONDARY :

   ALTER AVAILABILITY GROUP distributedAG SET (ROLE = SECONDARY);
   

   À ce stade, le groupe de disponibilité distribué n’est pas disponible.

6. Testez la disponibilité du basculement. Exécutez à nouveau la requête SELECT pour vérifier last_hardened_lsn (par base de données) sur le principal global et le redirecteur. Vérifiez les correspondances de last_hardened_lsn pour toutes les bases de données entre le principal global et le redirecteur.

7. Selon le résultat de l’étape précédente, votre étape suivante varie.

   • Si les last_hardened_lsns correspondent à la requête SELECT, basculez du groupe de disponibilité principal vers le groupe de disponibilité secondaire. Exécutez la commande ALTER AVAILABILITY GROUP sur le transiteur, le SQL Server qui héberge la réplique primaire du groupe de disponibilité secondaire.

   • Si les last_hardened_lsnsne correspondent pas à la requête SELECT après un certain temps, basculez le groupe de disponibilité distribué sur le redirecteur global d’origine (N1) en exécutant la commande de basculement sur le principal global. Redémarrez ensuite le processus à partir de la première étape.

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

   Après cette étape, le groupe de disponibilité distribué est disponible.

8. FACULTATIF : après un basculement réussi, si les groupes de disponibilité sont répartis sur une distance géographique qui souffre de latence, envisagez de changer le mode de disponibilité de nouveau en ASYNCHRONOUS_COMMIT pour rétablir la modification apportée précédemment.

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

Après avoir effectué ces étapes, le groupe de disponibilité distribué bascule sans perte de données.

Supprimer un groupe de disponibilité distribué

L’instruction Transact-SQL suivante supprime un groupe de disponibilité distribué nommé distributedAG:

DROP AVAILABILITY GROUP distributedAG;

Créer un groupe de disponibilité distribué sur des instances de cluster de basculement

Vous pouvez créer un groupe de disponibilité distribué à l’aide d’un groupe de disponibilité sur une instance de cluster de basculement (FCI). Dans ce cas, vous n’avez pas besoin d’écouteur de groupe de disponibilité. Utilisez le nom de réseau virtuel pour le réplica principal de l’instance FCI. L’exemple suivant montre un groupe de disponibilité distribué appelé SQLFCIDAG. Un des groupes de disponibilité est SQLFCIAG. SQLFCIAG a deux réplicas FCI. Le VNN pour le réplica FCI principal est SQLFCIAG-1, et celui du réplica FCI secondaire est SQLFCIAG-2. Le groupe de disponibilité distribué inclut également SQLAG-DR pour la récupération d’urgence.

Le DDL suivant crée ce groupe de disponibilité distribué :

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

L’URL de l’écouteur est le VNN de l’instance FCI principale.

Basculer manuellement FCI dans le groupe de disponibilité distribué

Pour basculer manuellement le groupe de disponibilité FCI, mettez à jour le groupe de disponibilité distribué de façon à refléter la modification de l’URL de l’écouteur. Par exemple, exécutez la DDL suivante à la fois sur le principal global du groupe de disponibilité distribué et sur le redirecteur du groupe de disponibilité distribué de SQLFCIDAG :

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

Contenu connexe

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