SQL Server 2016–Failover d’un groupe de disponibilité distribué

Dans le précédent article, afin de pouvoir bénéficier d’un groupe de disponibilité distribué entre 2 sites, nous avons créé 2 clusters. Chaque cluster, et donc chaque groupe de disponibilité assurait la HA localement sur un site. Le groupe de disponibilité distribué, lui, assurait le Disaster Recovery en cas de perte de l’un des sites.

Pour faire suite, donc à ce première article, je vous propose donc une petite procédure permettant de basculer sur le site de secours, de manière planifiée.

Encore une fois, rien de vraiment complexe au niveau des scripts. Mais il convient d’être méticuleux et patient, de ne pas basculer trop tôt sur le site de DR sans avoir attendu que la synchronisation des données soit terminée avant de rendre le site actif.

Dans un premier temps, il faut basculer en mode synchrone le réplica secondaire du DAG, correspondant au Listener de l’AG local au site 2.

$tSQL = "
ALTER AVAILABILITY GROUP [distributedag]  
   MODIFY   
   AVAILABILITY GROUP ON  
      'DC1-AG' WITH    
   (   
         LISTENER_URL = 'tcp://DC1-AG-VIP.demo.local:5022',    
          AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT
      ),   
      'DC2-AG' WITH    
      (   
         LISTENER_URL = 'tcp://DC2-AG-VIP.demo.local:5022',   
         AVAILABILITY_MODE = SYNCHRONOUS_COMMIT
      );    
"
Write-Host $tSQL 
Invoke-SqlCmd -Query $tSQL -Serverinstance "DC1-SQL1"

Il faut alors attendre que la synchronisation soit totalement effectuée pour s’assurer qu’il n’y aura pas de perte de donnée. La requête suivante affiche l’état de synchronisation des différentes réplicas des AG et du DAG. Ainsi, tant que le réplica primaire du site secondaire n’est pas SYNCHRONIZED, il convent d’attendre.

tSQL = "
SELECT   ar.replica_server_name
       , ag.name as availabilitygroup_name
       , ag.is_distributed
       , DB_NAME(drs.database_id) As database_name
       , drs.is_primary_replica
       , drs.synchronization_state_desc
       , drs.synchronization_health_desc
       , drs.log_send_queue_size
       , drs.redo_queue_size
       , drs.end_of_log_lsn 
       , drs.last_sent_lsn
       , drs.last_received_lsn
       , drs.last_hardened_lsn
       , drs.last_redone_lsn
       , drs.secondary_lag_seconds
FROM sys.dm_hadr_database_replica_states drs 
INNER JOIN sys.availability_groups ag ON drs.group_id = ag.group_id
inner join sys.availability_replicas ar on ar.replica_id = drs.replica_id

"
Write-Host $tSQL 
Invoke-SqlCmd -Query $tSQL -Serverinstance "DC1-SQL1" | Out-GridView

Pour effectuer ne bascule vers le site de secours, il faut ensuite spécifier au site 1 qui set primaire qu’il prend le rôle de secondaire.

# first transform primary into secondary
$tSQL = "
ALTER AVAILABILITY GROUP [distributedag] SET (ROLE = SECONDARY);    
"
Write-Host $tSQL 
Invoke-SqlCmd -Query $tSQL -Serverinstance "DC1-SQL1"

Et ensuite de provoquer la bascule depuis le réplica primaire de l’AG du site 2.

# and then failover from a secondary
$tSQL = "
ALTER AVAILABILITY GROUP [distributedag] FORCE_FAILOVER_ALLOW_DATA_LOSS;
"
Write-Host $tSQL 
Invoke-SqlCmd -Query $tSQL -Serverinstance "DC2-SQL3"

Une fois cette manipulation terminée, on peut revenir sur un mode Asynchrone pour tous les réplicas.

$tSQL = "
ALTER AVAILABILITY GROUP [distributedag]  
   MODIFY   
   AVAILABILITY GROUP ON  
      'DC1-AG' WITH    
  (   
          LISTENER_URL = 'tcp://DC1-AG-VIP.demo.local:5022',    
           AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT
      ),   
      'DC2-AG' WITH    
      (   
         LISTENER_URL = 'tcp://DC2-AG-VIP.demo.local:5022',   
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT
      );    
"
Write-Host $tSQL 
Invoke-SqlCmd -Query $tSQL -Serverinstance "DC2-SQL3"

 

Le DAG est maintenant primaire sur le site 2.

Le Fail Back ne présente aucune difficultés. Il suffit de changer les noms de réplicas sur le script précédent.

Point important : il n’est pas possible de créer de listener sur un DAG. Les plus attentifs parmi vous auront noté que je n’en ai pas parlé dans l’article précédent. Il reste donc une opération manuelle sur un serveur DNS par exemple afin de rediriger le trafic sur le listener du second site. Il set aussi possible de passer par des Load Balancers du marché.

Happy DR !

Publicités

A propos Christophe

Consultant SQL Server Formateur certifié Microsoft MVP SQL Server MCM SQL Server 2008
Cet article, publié dans SQL Server, est tagué , , , . Ajoutez ce permalien à vos favoris.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s