Remarques :

Déployer les groupes de disponibilité Always On de Microsoft SQL Server pour la récupération après sinistre sur OCI

Introduction

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

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

Cela vous permet d'atteindre des niveaux plus élevés de disponibilité, de fonctionnalités de récupération après sinistre et de distribution 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 étape par étape de la création des groupes de disponibilité Always On de Microsoft SQL Server. Pour plus d'informations, reportez-vous à Déploiement de groupes de disponibilité Always On de Microsoft SQL Server pour la haute disponibilité et la récupération après sinistre sur OCI.

Reportez-vous à la documentation officielle Microsoft suivante :

Objectifs

Prérequis

Tâche 1 : créer un groupe de disponibilité distribuée

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

Comme nous l'avons déjà mentionné, nous supposons que deux groupes de disponibilité Always On indépendants sont déjà opérationnels dans deux régions OCI différentes.

Le deuxième groupe de disponibilité Always On (marseille-aoag), le groupe de disponibilité standby, ne doit pas être associé à des bases de données. Par conséquent, pratiquement le deuxième groupe de disponibilité Always On 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. Vous pouvez ensuite supprimer cette base de données qui a été utilisée uniquement pour créer le deuxième groupe de disponibilité Always On. En effet, l'interface graphique ne peut pas créer un groupe de disponibilité Always On associé à une base de données.

  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 sql-srv1 du site Paris dans cet exemple) et exécutez les commandes SQL suivantes.

    Remarque :

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

    • Port TCP à utiliser, 5022 est le port de l'adresse et doit être utilisé. Il est généralement différent du port du processus d'écoute (1433).

    • Les noms de groupe de disponibilité doivent correspondre exactement aux 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é du deuxième groupe de disponibilité Always On.

    Connectez-vous à SQL Server sur le premier serveur du deuxième groupe de disponibilité Always On (serveur sql-srv3 du site Marseille) 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 ni de rôles dans 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 du groupe de disponibilité distribué.

    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

Remarque : pour prendre en charge la latence réseau potentielle entre les régions, nous avons configuré le groupe de disponibilité Always On principal et secondaire avec une réplication de validation asynchrone. Cela réduit la surcharge de performances sur la base de données principale. Dans chaque groupe de disponibilité Always On, nous avons opté pour la réplication de validation synchrone entre répliques afin de garantir une haute disponibilité. Toutefois, pour le basculement entre les répliques de validation asynchrone (dans le cas d'un groupe de disponibilité distribué), la réduction de la perte de données nécessite un basculement temporaire en mode de validation synchrone avant de lancer le basculement. Pour failover_mode, le seul mode disponible pour le groupe de disponibilité distribué est Manuel.

Tâche 2 : procédure de basculement pour le groupe de disponibilité distribuée

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

Suivez les étapes décrites:

  1. Exécutez les scripts suivants pour vérifier si la synchronisation est correcte, d'abord sur l'instruction SQL principale du site principal actuel, puis sur l'instruction SQL principale 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 sur la base de données principale globale et 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 en cours sur le site principal en cours.

    --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 à remplacer le rôle du groupe de disponibilité principal Toujours sur par le rôle 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. Remplacez le rôle du groupe de disponibilité Toujours sur secondaire par le rôle principal. Le script suivant effectuera ce changement 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. Désormais, sur le nouveau serveur SQL principal, annulez la définition de REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT.

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

    Rétablissez le mode de disponibilité en 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 rétablissement pour le groupe de disponibilité Always On distribué

Pour restaurer Paris en tant que site principal et Marseille en tant que site secondaire, effectuez simplement une nouvelle permutation pour inverser la synchronisation, comme indiqué dans la tâche 2.

Remerciements

Ressources de formation supplémentaires

Explorez d'autres ateliers sur docs.oracle.com/learn ou accédez à d'autres contenus de formation gratuits sur le canal Oracle Learning YouTube. De plus, visitez le site education.oracle.com/learning-explorer pour devenir un explorateur Oracle Learning.

Pour obtenir la documentation produit, consultez le site Oracle Help Center.