Effectuer un basculement manuel planifié d’un groupe de disponibilité Always On (SQL Server)

Article
04/26/2023

S'applique à : SQL Server

Cette rubrique explique comment effectuer un basculement manuel sans perte de données ( basculement manuel planifié) sur un groupe de disponibilité Always On à l'aide de SQL Server Management Studio, de Transact-SQL ou de PowerShell dans SQL Server. Un groupe de disponibilité bascule au niveau d'un réplica de disponibilité. Un basculement manuel planifié, comme un basculement de groupe de disponibilité Always On, transfère le rôle principal à un réplica secondaire. En même temps, le basculement transfère l’ancien réplica principal sur le rôle secondaire.

Un basculement manuel planifié est pris en charge seulement quand le réplica principal et le réplica secondaire cible s’exécutent en mode de validation synchrone et sont synchronisés. Il conserve toutes les données dans les bases de données secondaires qui sont jointes au groupe de disponibilité sur le réplica secondaire cible. Une fois que le réplica principal précédent transfère le rôle secondaire, ses bases de données deviennent des bases de données secondaires. Puis, elles commencent à se synchroniser avec les nouvelles bases de données primaires. Une fois que toutes ont passé à l'état SYNCHRONIZED, le nouveau réplica secondaire devient éligible pour servir de cible d'un futur basculement manuel planifié.

Notes

Si les réplicas principal et secondaire sont tous les deux configurés pour le mode de basculement automatique, une fois que le réplica secondaire est synchronisé, il peut également servir de cible à un basculement automatique. Pour plus d’informations, consultez Modes de disponibilité (Groupes de disponibilité Always On).

Avant de commencer

Important

Il existe des procédures spécifiques pour basculer un groupe de disponibilité avec échelle lecture sans gestionnaire de cluster. Quand un groupe de disponibilité a CLUSTER_TYPE = NONE, suivez les procédures sous Basculer le réplica principal sur un groupe de disponibilité avec échelle lecture.

Limitations et restrictions

Une commande de basculement retourne dès que le réplica secondaire cible a accepté la commande. Toutefois, la récupération de la base de données est asynchrone après que le basculement du groupe de disponibilité est terminé.
La cohérence entre les bases de données sur plusieurs bases de données dans le groupe de disponibilité peut ne pas être conservée lors d’un basculement.

Notes

La prise en charge des transactions distribuées et entre les bases de données varie selon les versions de système d’exploitation et SQL Server. Pour plus d’informations, consultez Transactions entre bases de données et transactions distribuées pour des groupes de disponibilité Always On et la mise en miroir de bases de données (SQL Server).

Prérequis et restrictions

Le réplica secondaire cible et le réplica principal doivent tous les deux s’exécuter en mode de disponibilité avec validation synchrone.
Le réplica secondaire cible doit être actuellement synchronisé avec le réplica principal. Toutes les bases de données secondaires de ce réplica secondaire doivent être jointes au groupe de disponibilité. Elles doivent également être synchronisées avec leurs bases de données primaires correspondantes (autrement dit, les bases de données secondaires locales doivent être SYNCHRONISÉES).

Conseil

Pour déterminer si le basculement d’un réplica secondaire est prêt, interrogez la colonne is_failover_ready dans la vue de gestion dynamique sys.dm_hadr_database_replica_cluster_states. Vous pouvez aussi consulter la colonne Disponibilité du basculement du tableau de bord du groupe Always On.
Cette tâche est prise en charge uniquement sur le réplica secondaire cible. Vous devez être connecté à l'instance de serveur qui héberge le réplica secondaire cible.

Sécurité

Autorisations

L’autorisation ALTER AVAILABILITY GROUP est obligatoire sur le groupe de disponibilité. L’autorisation CONTROL AVAILABILITY GROUP, l’autorisation ALTER ANY AVAILABILITY GROUP ou l’autorisation CONTROL SERVER sont également obligatoires.

Utilisez SQL Server Management Studio.

Pour basculer manuellement un groupe de disponibilité :

Dans l’Explorateur d’objets, connectez-vous à une instance de serveur qui héberge un réplica secondaire du groupe de disponibilité qui doit être basculé. Développez l'arborescence du serveur.
Développez le nœud Haute disponibilité AlwaysOn et le nœud Groupes de disponibilité .
Cliquez avec le bouton droit sur le groupe de disponibilité à basculer et sélectionnez Basculement.
L’Assistant Basculer le groupe de disponibilité commence. Pour plus d’informations, consultez Utiliser l’Assistant Basculer le groupe de disponibilité (SQL Server Management Studio).

Utiliser Transact-SQL

Pour basculer manuellement un groupe de disponibilité :

Connectez-vous à l'instance de serveur qui héberge le réplica secondaire cible.
Utilisez l'instruction ALTER AVAILABILITY GROUP , comme suit :

ALTER AVAILABILITY GROUP nom_groupe FAILOVER

Dans l’instruction, nom_groupe correspond au nom du groupe de disponibilité.

L’exemple suivant montre un basculement manuel du groupe de disponibilité MyAg vers le réplica secondaire connecté :
```
ALTER AVAILABILITY GROUP MyAg FAILOVER;  
```

Utiliser PowerShell

Pour basculer manuellement un groupe de disponibilité :

Remplacez le répertoire (cd) par l’instance de serveur qui héberge le réplica secondaire cible.
Utilisez l’applet de commande Switch-SqlAvailabilityGroup .

Notes

Pour voir la syntaxe d’une applet de commande, utilisez l’applet de commande Get-Help dans l’environnement SQL Server PowerShell. Pour plus d’informations, consultez Obtenir de l’aide pour SQL Server PowerShell.

L’exemple suivant montre un basculement manuel du groupe de disponibilité MyAg vers le réplica secondaire dont le chemin est spécifié :
```
Switch-SqlAvailabilityGroup -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg  
```
Pour configurer et utiliser le fournisseur SQL Server PowerShell :
- Fournisseur SQL Server PowerShell
- Obtenir de l’aide pour SQL Server PowerShell

Suivi : Après avoir basculé manuellement un groupe de disponibilité

Si vous avez effectué le basculement en dehors de groupe des basculements automatiques du groupe de disponibilité, ajustez les votes de quorum des nœuds du clustering de basculement Windows Server afin de refléter la nouvelle configuration du groupe de disponibilité. Pour plus d’informations, consultez Clustering de basculement Windows Server (WSFC) avec SQL Server.

Basculer le réplica principal sur un groupe de disponibilité avec échelle lecture

Chaque groupe de disponibilité contient un seul réplica principal. Le réplica principal autorise les opérations de lecture et d’écriture. Pour changer de réplica principal, vous pouvez effectuer un basculement. Dans un groupe de disponibilité standard, le gestionnaire de cluster automatise le processus de basculement. Dans un groupe de disponibilité avec le type de cluster AUCUN, le processus de basculement est manuel.

Il existe deux façons de basculer le réplica principal dans un groupe de disponibilité avec le type de cluster AUCUN :

Basculement manuel sans perte de données
Basculement manuel forcé avec perte de données

Basculement manuel sans perte de données

Utilisez cette méthode quand le réplica principal est disponible, mais que vous devez temporairement ou définitivement changer l’instance qui héberge le réplica principal. Pour éviter toute perte de données, avant d’effectuer le basculement manuel, vérifiez que le réplica secondaire cible est à jour.

Pour effectuer un basculement manuel sans perte de données :

Faites en sorte que le réplica principal actuel et le réplica secondaire cible soient SYNCHRONOUS_COMMIT.

ALTER AVAILABILITY GROUP [AGRScale] 
     MODIFY REPLICA ON N'<node2>' 
     WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);

Pour vérifier que les transactions actives sont validées sur le réplica principal et sur au moins un réplica secondaire synchrone, exécutez la requête suivante :
```
SELECT ag.name, 
   drs.database_id, 
   drs.group_id, 
   drs.replica_id, 
   drs.synchronization_state_desc, 
   ag.sequence_number
FROM sys.dm_hadr_database_replica_states drs, sys.availability_groups ag
WHERE drs.group_id = ag.group_id; 
```
Le réplica secondaire est synchronisé quand synchronization_state_desc a pour valeur SYNCHRONIZED.
Affectez la valeur 1 à REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT.

Le script suivant définit REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT sur 1 sur un groupe de disponibilité nommé ag1. Avant d’exécuter le script suivant, remplacez ag1 par le nom de votre groupe de disponibilité :
```
ALTER AVAILABILITY GROUP [AGRScale] 
     SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);
```
Ce paramétrage garantit que chaque transaction active est validée sur le réplica principal et sur au moins un réplica secondaire synchrone.

Notes

Ce paramètre n’est pas propre au basculement et doit être défini en fonction des exigences de l’environnement.
Définissez le réplica principal et le ou les réplicas secondaires qui ne participent pas au basculement hors connexion pour préparer le changement de rôle :
```
ALTER AVAILABILITY GROUP [AGRScale] OFFLINE
```

Promouvez le réplica secondaire en réplica principal.

ALTER AVAILABILITY GROUP AGRScale FORCE_FAILOVER_ALLOW_DATA_LOSS;

Changez le rôle de l’ancien réplica principal en des secondaires par SECONDARY et exécutez la commande suivante sur l’instance SQL qui héberge l’ancien réplica principal :
```
ALTER AVAILABILITY GROUP [AGRScale] 
     SET (ROLE = SECONDARY); 
```
Notes

Pour supprimer un groupe de disponibilité, utilisez DROP AVAILABILITY GROUP. Pour un groupe de disponibilité créé avec le type de cluster NONE ou EXTERNAL, exécutez la commande sur tous les réplicas faisant partie du groupe de disponibilité.
Pour reprendre le déplacement des données, exécutez la commande suivante pour chaque base de données du groupe de disponibilité sur l’instance de SQL Server qui héberge le réplica principal :
```
ALTER DATABASE [db1]
     SET HADR RESUME
```
Recréez l’écouteur que vous avez créé à des fins d’échelle lecture et qui n’est pas géré par un gestionnaire de cluster. Si l’écouteur d’origine pointe vers l’ancien réplica principal, supprimez-le et recréez-le pour qu’il pointe vers le nouveau réplica principal.

Basculement manuel forcé avec perte de données

Si le réplica principal n’est pas disponible et ne peut pas être récupéré immédiatement, vous devez forcer un basculement vers le réplica secondaire avec perte de données. Cependant, si le réplica principal d’origine récupère après le basculement, il va assumer le rôle principal. Pour éviter que chaque réplica soit dans un état différent, supprimez le réplica principal d’origine du groupe de disponibilité après un basculement forcé avec perte de données. Une fois que le serveur principal d’origine revient en ligne, supprimez-y entièrement le groupe de disponibilité.

Pour forcer un basculement manuel avec perte de données du réplica principal N1 vers le réplica secondaire N2, effectuez les étapes suivantes :

Sur le réplica secondaire (N2), lancez le basculement forcé :

ALTER AVAILABILITY GROUP [AGRScale] FORCE_FAILOVER_ALLOW_DATA_LOSS;

Sur le nouveau réplica principal (N2), supprimez le réplica principal d’origine (N1) :
```
ALTER AVAILABILITY GROUP [AGRScale]
REMOVE REPLICA ON N'N1';
```
Vérifiez que tout le trafic d’application pointe vers l’écouteur et/ou le nouveau réplica principal.
Si le réplica principal d’origine (N1) est mis en ligne, placez immédiatement le groupe de disponibilité AGRScale hors connexion sur le réplica principal d’origine (N1) :
```
ALTER AVAILABILITY GROUP [AGRScale] OFFLINE
```
S’il existe des données ou des modifications non synchronisées, conservez ces données via des sauvegardes ou d’autres options de réplication des données qui répondent aux besoins de votre entreprise.
Ensuite, supprimez le groupe de disponibilité du réplica principal d’origine (N1) :
```
DROP AVAILABILITY GROUP [AGRScale];
```
Supprimez la base de données du groupe de disponibilité sur le réplica principal d’origine (N1) :
```
USE [master]
GO
DROP DATABASE [AGDBRScale]
GO
```
(Facultatif) Si vous le souhaitez, vous pouvez maintenant ajouter N1 comme nouveau réplica secondaire au groupe de disponibilité AGRScale.

Partager via

Effectuer un basculement manuel planifié d’un groupe de disponibilité Always On (SQL Server)

Avant de commencer

Limitations et restrictions

Prérequis et restrictions

Sécurité

Autorisations

Utilisez SQL Server Management Studio.

Utiliser Transact-SQL

Utiliser PowerShell

Suivi : Après avoir basculé manuellement un groupe de disponibilité

Basculer le réplica principal sur un groupe de disponibilité avec échelle lecture

Basculement manuel sans perte de données

Basculement manuel forcé avec perte de données

Voir aussi

Commentaires

Ressources supplémentaires