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

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 tout basculement d’un groupe de disponibilité Always On, fait passer un réplica secondaire au rôle principal. En même temps, le basculement fait passer l’ancienne réplique principale au 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. Un basculement manuel planifié préserve 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 l’ancienne réplique principale passe au 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 qu'elles sont toutes passées à l'état SYNCHRONISÉ, le nouveau réplica secondaire peut servir de cible à un prochain basculement manuel planifié.

Remarque

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 effectuer le basculement d’un groupe de disponibilité de mise à l’échelle en 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

Prérequis et restrictions

  • Le réplica secondaire cible et le réplica principal doivent être configurés en mode de disponibilité à validation synchrone.

  • Actuellement, la réplique secondaire cible doit être synchronisée avec la réplique principale. Toutes les bases de données secondaires de ce réplica secondaire doivent être ajoutées 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 un réplica secondaire est prêt pour le basculement, 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 n’est prise en charge que sur le réplica secondaire cible. Vous devez être connecté à l'instance de serveur hébergeant le réplica secondaire cible.

Sécurité

Autorisations

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

Utilisez SQL Server Management Studio.

Pour basculer manuellement un groupe de disponibilité :

  1. Dans l’Explorateur d’objets, connectez-vous à une instance de serveur hébergeant un réplica secondaire du groupe de disponibilité sur lequel le basculement doit être effectué. Développez l'arborescence du serveur.

  2. Développez le nœud Haute disponibilité Always On et le nœud Groupes de disponibilité.

  3. Cliquez avec le bouton droit sur le groupe de disponibilité à basculer et sélectionnez Basculement.

  4. L’Assistant Basculement de groupe de disponibilité démarre. Pour plus d’informations, consultez Utiliser l’Assistant Groupe de disponibilité de basculement (SQL Server Management Studio).

Utiliser Transact-SQL

Pour basculer manuellement un groupe de disponibilité :

  1. Connectez-vous à l'instance de serveur qui héberge le réplica secondaire cible.

  2. Utilisez l’instruction ALTER AVAILABILITY GROUP , comme suit :

    ALTER AVAILABILITY GROUP group_name BASCULEMENT

    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é :

  1. Remplacez le répertoire (cd) par l’instance de serveur qui héberge le réplica secondaire cible.

  2. Utilisez l’applet de commande Switch-SqlAvailabilityGroup .

    Remarque

    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 :

Étape suivante : Après avoir effectué manuellement le basculement d’un groupe de disponibilité

Si vous avez réalisé un basculement en dehors de l’ensemble de basculement automatique du groupe de disponibilité, ajustez les votes de quorum des nœuds du cluster de basculement Windows Server afin de refléter la nouvelle configuration de votre groupe de disponibilité. Pour plus d’informations, consultez cluster 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é comporte un seul réplica principal. La réplique principale autorise la lecture et l’écriture. Pour changer le 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 d’effectuer le basculement du réplica principal dans un groupe de disponibilité avec un type de cluster NONE :

  • 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 :

  1. Définissez le réplica principal actuel et le réplica secondaire cible comme SYNCHRONOUS_COMMIT.

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

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

    La réplique secondaire est synchronisée lorsque synchronization_state_desc a pour valeur SYNCHRONIZED.

  3. 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.

    Remarque

    Ce paramètre n’est pas spécifique au basculement et doit être défini en fonction des exigences de l’environnement.

  4. Mettez hors connexion le réplica principal et le ou les réplicas secondaires ne participant pas au basculement afin de préparer le changement de rôle :

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE

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

    ALTER AVAILABILITY GROUP AGRScale FORCE_FAILOVER_ALLOW_DATA_LOSS;

  6. Mettez à jour le rôle de l’ancien réplica principal et des autres réplicas secondaires sur SECONDARY, puis exécutez la commande suivante sur l’instance de SQL Server qui héberge l’ancien réplica principal :

    ALTER AVAILABILITY GROUP [AGRScale] 
     SET (ROLE = SECONDARY);

    Remarque

    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 du groupe de disponibilité.

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

  8. Recréez tout listener que vous avez créé pour la mise à l’échelle en lecture et qui n’est pas géré par un gestionnaire de cluster. Si le listener d’origine pointe vers l’ancien principal, supprimez-le et recréez-le pour qu’il pointe vers le nouveau 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 la réplique principale d’origine récupère après le basculement, elle reprendra le rôle principal. Pour éviter que chaque réplica se retrouve 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 complètement le groupe de disponibilité de celui-ci.

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

  1. Sur la réplique secondaire (N2), initiez le basculement forcé :

    ALTER AVAILABILITY GROUP [AGRScale] FORCE_FAILOVER_ALLOW_DATA_LOSS;

  2. Sur le nouveau réplica principal (N2), supprimez le réplica principal d’origine (N1) :

    ALTER AVAILABILITY GROUP [AGRScale]
REMOVE REPLICA ON N'N1';

  3. Vérifiez que l’ensemble du trafic de l’application est dirigé vers l’écouteur et/ou le nouveau réplica principal.

  4. 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

  5. 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.

  6. Ensuite, supprimez le groupe de disponibilité du nœud principal d’origine (N1) :

    DROP AVAILABILITY GROUP [AGRScale];

  7. Supprimer la base de données de groupe de disponibilité sur le réplica principal d’origine (N1) :

    USE [master]
GO
DROP DATABASE [AGDBRScale]
GO

  8. (Facultatif) Si vous le souhaitez, vous pouvez maintenant rajouter N1 en tant que nouveau réplica secondaire au groupe de disponibilité AGRScale.

Voir aussi

  • Last updated on