Note :

Déployer Microsoft SQL Server distribué toujours sur les groupes disponibles pour la reprise après sinistre sur OCI

Présentation

Distributed Always On Availability Group (Groupe de disponibilité distribuée) est une fonctionnalité puissante de Microsoft SQL Server qui étend les capacités du groupe de disponibilité traditionnel pour SQL Server.

Les groupes de disponibilité répartis vous permettent de créer une solution de récupération après sinistre qui couvre plusieurs grappes de basculement Windows Server (WSFC) exécutées dans différentes régions Oracle Cloud Infrastructure (OCI).

Cela vous permet d'atteindre des niveaux plus élevés de disponibilité, de capacités de récupération après sinistre et de répartition géographique pour vos bases de données SQL Server critiques exécutées sur OCI.

Exclusions pour ce tutoriel

Dans ce tutoriel, nous ne traiterons pas de la création étape par étape du seul groupe de disponibilité Microsoft SQL Server Always On. Pour plus d'informations, voir Déployer Microsoft SQL Server toujours activé sur les groupes de disponibilité pour haute disponibilité et reprise après sinistre sur OCI.

Veuillez consulter la documentation officielle Microsoft suivante :

Objectifs

Préalables

Tâche 1 : Créer un groupe de disponibilité répartie

Créez un groupe de disponibilité distribué (distributed-aoag) composé des deux groupes de disponibilité sous-jacents qui sont déjà en cours d'exécution.

Comme déjà mentionné, nous supposons que deux groupes de disponibilité Always On indépendants sont déjà en cours d'exécution dans deux régions OCI différentes.

Le deuxième groupe de disponibilité Toujours activé (marseille-aoag), le groupe de disponibilité de secours, ne doit avoir aucune base de données associée, de sorte que pratiquement le deuxième groupe de disponibilité Toujours activé doit être vide avant la création du groupe de disponibilité distribué, de sorte qu'aucune base de données de disponibilité n'est associée. Vous pouvez créer le deuxième groupe de disponibilité Always On comme d'habitude avec une base de données initiale associée, puis supprimer cette base de données qui n'a été utilisée que pour créer le deuxième groupe de disponibilité Always On. En effet, l'interface graphique n'est pas possible de créer un groupe de disponibilité Always On auquel aucune base de données n'est associée.

  1. Créez un groupe de disponibilité distribué sur le premier groupe de disponibilité Always On.

    Connectez-vous à SQL Server sur le premier serveur (noeud du site Paris sql-srv1 dans cet exemple) et exécutez les commandes SQL suivantes.

    Note :

    • Les noms de module d'écoute sont paris-sql-list et mars-sql-list.

    • Port TCP à utiliser, 5022 est le port du point d'extrémité et doit être utilisé. Cela diffère généralement du port du module d'écoute (1433).

    • Les noms de groupe de disponibilité doivent être exactement les noms utilisés par le groupe de disponibilité Always On déjà en cours d'exécution.

    USE MASTER;
CREATE AVAILABILITY GROUP [distributed-aoag]  
   WITH (DISTRIBUTED)   
   AVAILABILITY GROUP ON  
      'paris-aoag' WITH    
      (   
         LISTENER_URL = 'tcp://paris-sql-list.acme.corp:5022',    
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
         FAILOVER_MODE = MANUAL,   
         SEEDING_MODE = AUTOMATIC   
      ),   
      'marseille-aoag' WITH    
      (   
         LISTENER_URL = 'tcp://mars-sql-list.acme.corp:5022',   
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
         FAILOVER_MODE = MANUAL,   
         SEEDING_MODE = AUTOMATIC   
      );    
GO

  2. Rejoignez le groupe de disponibilité distribué sur le deuxième groupe de disponibilité Always On.

    Connectez-vous à SQL Server sur le premier serveur du deuxième groupe de disponibilité Always On (serveur du site de Marseille sql-srv3) et exécutez les commandes SQL suivantes.

    USE MASTER;
ALTER AVAILABILITY GROUP [distributed-aoag]   
   JOIN   
   AVAILABILITY GROUP ON  
      'paris-aoag' WITH    
      (   
         LISTENER_URL = 'tcp://paris-sql-list.acme.corp:5022',    
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
         FAILOVER_MODE = MANUAL,   
         SEEDING_MODE = AUTOMATIC   
      ),   
      'marseille-aoag' WITH    
      (   
         LISTENER_URL = 'tcp://mars-sql-list.acme.corp:5022',   
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
         FAILOVER_MODE = MANUAL,   
         SEEDING_MODE = AUTOMATIC   
      );    
GO

  3. Il est important de comprendre que, contrairement aux groupes de disponibilité traditionnels, les groupes de disponibilité distribués ne nécessitent pas de groupes de ressources ou de rôles dans le WSFC. Toutes les métadonnées sont gérées dans SQL Server. Cela signifie que même SQL Server Management Studio n'affiche pas directement les noms des bases de données dans le groupe de disponibilité distribuée.

    Pour afficher ces informations, exécutez le script Transact-SQL suivant.

    --View metadata and status of the Distributed Availability Group
SELECT r.replica_server_name, r.endpoint_url,
rs.connected_state_desc, rs.role_desc, rs.operational_state_desc,
rs.recovery_health_desc,rs.synchronization_health_desc,
r.availability_mode_desc, r.failover_mode_desc
FROM sys.dm_hadr_availability_replica_states rs 
INNER JOIN sys.availability_replicas r
ON rs.replica_id=r.replica_id
ORDER BY r.replica_server_name

    Image

Note : Pour assurer une latence de réseau potentielle entre les régions, nous avons configuré le groupe de disponibilité Toujours activé principal et secondaire avec une réplication de validation asynchrone. Cela réduit la surcharge de performance de la base de données principale. Dans chaque groupe de disponibilité Always On, nous avons opté pour la réplication synchrone-commit entre les répliques afin d'assurer une haute disponibilité. Toutefois, pour le basculement entre les répliques asynchrones-commit (dans le cas d'un groupe de disponibilité distribué), la réduction des pertes de données nécessite un basculement temporaire vers le mode de validation synchrone avant le lancement du basculement. Pour failover_mode, le seul mode disponible pour le groupe de disponibilité répartie est manuel.

Tâche 2 : Procédure de basculement pour un groupe de disponibilité distribué

Dans cette tâche, nous allons parler de basculement entre les deux groupes de disponibilité Always On. La procédure de basculement de la base de données se compose des étapes et vérifications simples suivantes.

Voici la marche à suivre :

  1. Exécutez les scripts suivants pour vérifier si la synchronisation est correcte, d'abord sur le SQL principal actuel du site principal actuel, puis sur le SQL principal du site secondaire.

    Les résultats exécutés doivent être CONNECTED_STATE = CONNECTED et SYNCHRONIZATION_HEALTH = HEALTHY.

    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

    Image

    Image

  2. Modifiez le mode de disponibilité. Exécutez d'abord le script suivant sur le serveur SQL principal actuel du site principal actuel, puis sur le serveur SQL principal du site secondaire.

    --Run this first on the primary replica of the primary AOAG and then again on the secondary AOAG
USE MASTER;     
ALTER AVAILABILITY GROUP [distributed-aoag]     
MODIFY 
AVAILABILITY GROUP ON
'paris-aoag' WITH 
( 
   AVAILABILITY_MODE = SYNCHRONOUS_COMMIT 
), 
'marseille-aoag' WITH     
( 
   AVAILABILITY_MODE = SYNCHRONOUS_COMMIT 
);

  3. Pour éviter toute perte de données, vérifiez les résultats de cette étape. Le statut doit être SYNCHRONIZED et last_hardened_lsn doit correspondre pour chaque base de données à la fois sur la base principale globale et sur le transitaire.

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

    Image

    Image

  4. Vous êtes maintenant prêt à définir REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT sur le serveur SQL principal courant sur le site principal courant.

    --Run this script into Primary AOAG
USE MASTER;
ALTER AVAILABILITY GROUP [distributed-aoag]
SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);

    Et maintenant, vous êtes prêt à modifier le rôle du groupe de disponibilité principal Always On de primaire à secondaire.

    --Run this script into Primary AOAG, this will terminate client applications connected to the primary replica of the primary AOAG
USE MASTER;
ALTER AVAILABILITY GROUP [distributed-aoag] SET (ROLE = SECONDARY);

    Image

  5. Modifiez le rôle du groupe de disponibilité secondaire Always On de secondaire à principal. Le script suivant effectuera cette modification de rôle, permettant à la base de données d'effectuer des opérations de lecture ou d'écriture. En outre, les rôles des groupes de disponibilité Always On au sein du groupe de disponibilité distribué seront également mis à jour en conséquence.

    --Run this script into Secondary AOAG, this will terminate client applications connected to the primary replica of the primary AOAG
ALTER AVAILABILITY GROUP [distributed-aoag] FORCE_FAILOVER_ALLOW_DATA_LOSS;

    Exécutez le script suivant pour vérifier le statut.

    --check the status on the new primary (formerly standby site)
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

    Image

    Image

  6. Maintenant, sur le nouveau serveur SQL principal, désactivez REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT.

    --Run this script into Primary AOAG
ALTER AVAILABILITY GROUP [distributed-aoag] 
SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0);

    Remplacez le mode de disponibilité par le mode standard en exécutant le script suivant sur les sites principal et secondaire.

    --Run this first on the primary replica of the primary AOAG and then again on the secondary AOAG
ALTER AVAILABILITY GROUP [distributed-aoag]     
MODIFY 
AVAILABILITY GROUP ON
'paris-aoag' WITH 
( 
   AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT 
), 
'marseille-aoag' WITH     
( 
   AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT 
);

Tâche 3 : Procédure de secours pour le groupe distribué toujours activé

Pour restaurer Paris comme site principal et Marseille comme site secondaire, il suffit d'effectuer une nouvelle permutation pour inverser la synchronisation, comme indiqué dans la Tâche 2.

Confirmation

Autres ressources d'apprentissage

Explorez d'autres laboratoires sur la page docs.oracle.com/learn ou accédez à plus de contenu d'apprentissage gratuit sur le canal YouTube d'Oracle Learning. De plus, visitez education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour obtenir de la documentation sur le produit, visitez Oracle Help Center.