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

S'applique à :SQL Server

Cet article explique comment effectuer un basculement forcé (avec perte de données possible) sur un groupe de disponibilité Always On à l’aide de SQL Server Management Studio, Transact-SQL ou PowerShell dans SQL Server. Un basculement forcé est une forme de basculement manuel qui est destiné strictement à la récupération d’urgence, lorsqu’un basculement manuel planifié n’est pas possible. Si vous forcez le basculement vers un réplica secondaire qui n'est pas synchronisé, une perte de données est possible. Par conséquent, nous vous recommandons vivement de forcer le basculement uniquement si vous devez immédiatement restaurer le service sur le groupe de disponibilité et si vous êtes prêt à accepter le risque de perdre des données.

Après un basculement forcé, la cible de basculement vers laquelle le groupe de disponibilité a basculé devient le nouveau réplica principal. Les bases de données secondaires dans les réplicas secondaires restants sont suspendues et vous devez les reprendre manuellement. Lorsque l'ancien réplica principal redevient disponible, il passe au rôle secondaire, ce qui fait que les anciennes bases de données primaires deviennent des bases de données secondaires et passent à l'état SUSPENDED. Avant de reprendre une base de données secondaire donnée, vous pouvez récupérer les données perdues de celle-ci. Toutefois, notez que la troncation du journal des transactions est retardée sur une base de données primaire donnée, lorsque l'une de ses bases de données secondaires est interrompue.

Effectuer un basculement forcé est nécessaire dans les cas d'urgence suivants :

• Après avoir forcé le quorum sur le cluster WSFC (quorum forcé), vous devez forcer le basculement de chaque groupe de disponibilité (avec perte de données possible). Le basculement forcé est requis, car l'état réel des valeurs de cluster WSFC peut avoir été perdu. Toutefois, vous pouvez éviter la perte de données si vous êtes en mesure de forcer le basculement sur l'instance de serveur qui hébergeait le réplica principal avant que vous ne forciez le quorum, ou sur un réplica secondaire synchronisé avant le quorum forcé. Pour plus d’informations, consultez les méthodes possibles pour éviter la perte de données après le quorum forcé, plus loin dans cet article.

  Important

  Si le quorum est restauré par des moyens naturels au lieu d’être forcé, les réplicas disponibles subissent un processus de récupération normal. Si le réplica principal reste indisponible une fois le quorum regagné, vous pouvez effectuer un basculement manuel planifié vers un réplica secondaire synchronisé.

  Pour plus d’informations sur le quorum forcé, consultez Récupération d’urgence WSFC par le quorum forcé (SQL Server). Pour découvrir pourquoi le basculement forcé est nécessaire après avoir forcé le quorum, consultez Basculement et modes de basculement (groupes de disponibilité Always On).

• Si la réplique principale devient indisponible alors que le cluster WSFC a un quorum valide, vous pouvez forcer le basculement (avec perte de données possible) vers une réplique dont le rôle est dans l'état SECONDARY ou dans l'état RESOLVING. Si possible, forcez le basculement vers un réplica secondaire avec validation synchrone qui était synchronisé lorsque le réplica principal a été perdu.

  Conseil

  Lorsque le cluster WSFC possède un quorum sain, si vous exécutez une commande de basculement forcé sur un réplica secondaire synchronisé, le réplica effectue un basculement manuel planifié.

Pour plus d’informations sur les prérequis et les recommandations pour forcer le basculement et pour un exemple de scénario qui utilise un basculement forcé pour récupérer à partir d’une défaillance catastrophique, consultez Exemple de scénario : Utiliser un basculement forcé pour effectuer une récupération à partir d’une défaillance catastrophique, plus loin dans cet article.

Limites

• La seule fois où vous ne pouvez pas effectuer de basculement forcé est lorsque le cluster WSFC (Clustering de basculement Windows Server) n’a pas de quorum.

• Une perte de données est possible pendant le basculement forcé d'un groupe de disponibilité. En outre, si le réplica principal s'exécute lorsque vous démarrez un basculement forcé, les clients risquent de toujours être connectés aux bases de données primaires précédentes. En conséquence, nous vous recommandons vivement d’imposer un basculement uniquement si le réplica principal ne fonctionne plus et si vous êtes prêt à accepter le risque de perte de données pour restaurer l'accès aux bases de données dans le groupe de disponibilité.

• Lorsqu'une base de données secondaire est dans l'état REVERTING ou l'état INITIALIZING, un basculement forcé entraînerait l'échec du démarrage de la base de données en tant que primaire. Si la base de données était dans l’état INITIALIZING , vous devez appliquer les enregistrements de journal manquants à partir d’une sauvegarde de base de données ou restaurer entièrement la base de données à partir de zéro. Si la base de données était dans l’état REVERTING , vous devez restaurer entièrement la base de données à partir de sauvegardes.

• Une commande de basculement est retournée dès que la cible de basculement 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 - Groupes de disponibilité et mise en miroir de bases de données.

Prérequis

• Le cluster WSFC possède un quorum. Si le cluster n’a pas de quorum, consultez Récupération d’urgence WSFC par le quorum forcé (SQL Server).

• Vous devez être en mesure de vous connecter à une instance de serveur qui héberge un réplica dont le rôle est dans l’état SECONDARY ou RESOLVING.

Recommandations

• Ne forcez pas le basculement tant que le réplica principal est encore en cours d’exécution.

• Si possible, forcez le basculement uniquement vers une cible de basculement dont les bases de données secondaires sont dans l’état NOT SYNCHRONIZED, SYNCHRONIZED ou SYNCHRONIZING. Pour des informations sur les implications du forçage de basculement lorsqu'une base de données secondaire est dans l'état INITIALIZING ou dans l'état REVERTING, consultez Limitations plus haut dans cet article.

• En général, la latence d'une base de données secondaire donnée, par rapport à la base de données primaire, doit être similaire sur les différents réplicas secondaires de validation asynchrone. Toutefois, lors d'un basculement forcé, une perte de données peut constituer un souci majeur. Par conséquent, prenez le temps de déterminer la latence relative des copies des bases de données sur les différents réplicas secondaires. Pour déterminer quelle copie d'une base de données secondaire donnée présente la latence la plus faible, comparez leurs numéros séquentiels LSN de fin de journal. Plus ce numéro LSN de fin de journal est élevé, plus la latence est faible.

  Conseil

  Pour comparer les LSN de fin de journal, connectez-vous à chaque réplica secondaire en ligne, puis interrogez sys.dm_hadr_database_replica_states pour obtenir la end_of_log_lsn valeur de chaque base de données secondaire locale. Puis, comparez les numéros séquentiels LSN de fin de journal des différentes copies de chaque base de données. Différentes bases de données peuvent avoir leurs LSN les plus élevés sur différentes répliques secondaires. Dans ce cas, la cible de basculement la plus appropriée dépend de l'importance relative que vous accordez aux données dans les différentes bases de données. Autrement dit, pour quelle base de données souhaitez-vous minimiser la possible perte de données ?

• Si les clients peuvent se connecter au réplica principal d'origine, un basculement forcé entraîne un risque de comportement de fractionnement des partitions. Avant de forcer le basculement, nous vous recommandons fortement d'empêcher les clients d'accéder au réplica principal d'origine. Autrement, une fois le basculement forcé, les bases de données primaires d'origine et les bases de données primaires actuelles risquent d'être mises à jour indépendamment les unes des autres.

Moyens potentiels d’éviter la perte de données après le quorum est forcé

Dans certaines conditions d’échec après la perte du quorum, vous pouvez empêcher la perte de données comme suit :

• Si le réplica principal d'origine est mis en ligne

  Si le quorum est perdu et l'application forcée d'un quorum WSFC restaure le nœud de cluster qui héberge le réplica principal d'un groupe de disponibilité, vous pouvez empêcher la perte de données de ce groupe de disponibilité. Connectez-vous au réplica principal et effectuez un basculement forcé (FAILOVER_ALLOW_DATA_LOSS). Cela remet le réplica principal en ligne. Étant donné que vous effectuez le basculement forcé vers le réplica principal d’origine, il n’y a aucune perte de données.

• Si un réplica secondaire synchronisé avec validation synchrone est mis en ligne

  Si le quorum est perdu et l'application forcée d'un quorum WSFC restaure un nœud de cluster qui héberge un réplica secondaire synchronisé d'un groupe de disponibilité, vous serez à même d'empêcher la perte de données de ce groupe de disponibilité. Si le nœud restauré était en fonctionnement au moment où le quorum a été perdu, vous pouvez déterminer si une perte de données pourrait se produire pour une base de données donnée en interrogeant la colonne is_failover_ready de la vue de gestion dynamique sys.dm_hadr_database_replica_cluster_states. Par exemple, pour une instance de serveur nommée sql108w2k8r22, exécutez la requête suivante :

  SELECT *
  FROM sys.dm_hadr_database_replica_cluster_states
  WHERE replica_id = (
      SELECT replica_id
      FROM sys.availability_replicas
      WHERE replica_server_name = 'sql108w2k8r22'
  );
  

  Attention

  Si le nœud restauré n'était pas opérationnel au moment où le quorum a été perdu, is_failover_ready il se peut que cela ne reflète pas l'état réel du système au moment où le réplica principal est passé hors ligne. Par conséquent, la valeur is_failover_ready est correcte uniquement si le nœud hôte était actif au moment de l’échec. Pour plus d’informations, consultez « Raisons pour lesquelles le basculement forcé est requis après avoir forcé le quorum » dans Basculement et modes de basculement (groupes de disponibilité Always On).

  Si is_failover_ready = 1, la base de données est marquée comme synchronisée dans le cluster et est prête pour une reprise après panne. Si is_failover_ready = 1 est sur toutes les bases de données d'un réplica secondaire donné, vous pouvez effectuer un basculement forcé (FORCE_FAILOVER_ALLOW_DATA_LOSS) sans perte de données sur ce réplica secondaire. Le réplica secondaire synchronisé est mis en ligne dans le rôle principal, c.-à-d., comme nouveau réplica principal, avec toutes les données intactes.

  Si is_failover_ready = 0, la base de données n’est pas marquée comme synchronisée dans le cluster et n’est pas prête pour un basculement manuel planifié. Si vous forcez le basculement vers le réplica secondaire hôte, les données sont perdues sur cette base de données.

  Notes

  Lorsque vous forcez le basculement vers un réplica secondaire, la quantité de perte de données dépend de la distance entre la cible de basculement et le réplica principal. Malheureusement, lorsque le cluster WSFC ne dispose pas du quorum ou du quorum a été forcé, vous ne pouvez pas évaluer la quantité de perte de données potentielle. Notez, toutefois, qu'une fois que le cluster WSFC a regagné un quorum sain, vous pouvez commencer à suivre la perte potentielle de données. Pour plus d’informations, consultez « Suivi de la perte de données potentielle » dans Basculement et modes de basculement (groupes de disponibilité Always On).

Autorisations

Nécessite ALTER AVAILABILITY GROUP une autorisation sur le groupe de disponibilité, CONTROL AVAILABILITY GROUP l’autorisation, ALTER ANY AVAILABILITY GROUP l’autorisation ou CONTROL SERVER l’autorisation.

Utiliser SQL Server Management Studio

1. Dans l’Explorateur d’objets, connectez-vous à une instance de serveur qui héberge un réplica dont le rôle se trouve dans l’état SECONDARY ou RESOLVING dans le groupe de disponibilité pour lequel le basculement est nécessaire, et développez l’arborescence du serveur.

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

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

4. Cette commande lance l'Assistant Basculer le groupe de disponibilité. Pour plus d’informations, consultez Utiliser l’Assistant Basculer le groupe de disponibilité (SQL Server Management Studio).

5. Après avoir forcé un groupe de disponibilité à basculer, effectuez les étapes de suivi nécessaires. Pour plus d’informations, consultez Suivi : Tâches essentielles après un basculement forcé, plus loin dans cet article.

Utiliser Transact-SQL

1. Connectez-vous à une instance de serveur qui héberge un réplica dont le rôle est en état SECONDARY ou RESOLVING, dans le groupe de disponibilité nécessitant un basculement.

2. Utilisez l’instruction ALTER AVAILABILITY GROUP , comme suit, où group_name est le nom du groupe de disponibilité :

   ALTER AVAILABILITY GROUP <group_name> FORCE_FAILOVER_ALLOW_DATA_LOSS.

   L'exemple suivant force le basculement du groupe de disponibilité AccountsAG vers le réplica secondaire local.

   ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
   

3. Après avoir forcé un groupe de disponibilité à basculer, effectuez les étapes de suivi nécessaires. Pour plus d’informations, consultez Tâches essentielles après un basculement forcé, plus loin dans cet article.

Utiliser PowerShell

1. Accédez au répertoire (cd) d'une instance de serveur qui héberge un réplica dont le rôle est soit dans l'état SECONDARY soit dans l'état RESOLVING au sein du groupe de disponibilité qui doit être basculé.

2. Utilisez l’applet Switch-SqlAvailabilityGroup de commande avec le AllowDataLoss paramètre dans l’une des formes suivantes :

   • -AllowDataLoss

     Par défaut, -AllowDataLoss le paramètre Switch-SqlAvailabilityGroup vous invite à vous rappeler que le basculement forcé peut entraîner la perte de transactions non validées et demander la confirmation. Pour continuer, entrez Y; pour annuler l’opération, entrez N.

     L’exemple suivant exécute un basculement forcé (avec perte de données possible) du groupe de disponibilité MyAg vers le réplica secondaire sur l’instance de serveur nommée SecondaryServer\InstanceName. Vous êtes invité à confirmer cette opération.

     Switch-SqlAvailabilityGroup `
        -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `
        -AllowDataLoss
     

   • -AllowDataLoss-Force

     Pour lancer un basculement forcé sans confirmation, spécifiez à la fois les paramètres -AllowDataLoss et -Force. Cela est utile si vous souhaitez inclure la commande dans un script et l'exécuter sans intervention de l'utilisateur. Toutefois, utilisez l’option -Force avec précaution, car un basculement forcé peut entraîner la perte de données provenant de bases de données participant au groupe de disponibilité.

     L’exemple suivant exécute un basculement forcé (avec perte de données possible) du groupe de disponibilité MyAg vers l’instance de serveur nommée SecondaryServer\InstanceName. L’option -Force supprime la confirmation de cette opération.

     Switch-SqlAvailabilityGroup `
        -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `
        -AllowDataLoss -Force
     

   Notes

   Pour afficher la syntaxe d’une applet de commande, utilisez l’applet Get-Help de commande dans l’environnement SQL Server PowerShell. Pour en savoir plus, voir Get Help SQL Server PowerShell.

3. Après avoir forcé un groupe de disponibilité à basculer, effectuez les étapes de suivi nécessaires. Pour plus d’informations, consultez Suivi : Tâches essentielles après un basculement forcé, plus loin dans cet article.

Configurer et utiliser le fournisseur SQL Server PowerShell

• Fournisseur SQL Server PowerShell

Suivi : étapes essentielles après un basculement forcé

1. Après un basculement forcé, le réplica secondaire vers lequel vous avez effectué le basculement devient le nouveau réplica principal. Toutefois, pour que ce réplica de disponibilité soit accessible aux clients, vous devrez peut-être reconfigurer le quorum WSFC ou ajuster la configuration du mode de disponibilité du groupe de disponibilité, comme suit :

   • Si vous avez effectué le basculement en dehors du groupe des basculements automatiques : ajustez les votes de quorum des nœuds WSFC afin de refléter la nouvelle configuration de votre groupe de disponibilité. Si le nœud WSFC qui héberge le réplica secondaire cible n’a pas de vote de quorum WSFC, vous devrez peut-être forcer le quorum WSFC.

     Un groupe des basculements automatiques existe uniquement si deux réplicas de disponibilité (réplica principal précédent inclus) sont configurés pour le mode de validation synchrone avec basculement automatique.

     Pour ajuster les votes de quorum

     • Afficher les paramètres NodeWeight pour le quorum de cluster
     • Configurer les paramètres NodeWeight pour un quorum de cluster
     • Forcer un cluster WSFC à démarrer sans quorum

   • Si vous avez effectué le basculement en dehors du groupe des basculements avec validation synchrone : Nous vous recommandons d’ajuster le mode de disponibilité et de basculement sur le nouveau réplica principal et sur les réplicas secondaires restants afin de refléter la configuration de votre choix concernant la validation synchrone et le basculement automatique.

     Notes

     Un groupe des basculements avec validation synchrone existe uniquement si le réplica principal actuel est configuré pour le mode de validation synchrone.

     Pour modifier le mode de disponibilité et de basculement

     • Modifier le mode de disponibilité d’un réplica au sein d’un groupe de disponibilité Always On
     • Modifier le mode de basculement d’une réplique au sein d’un groupe de disponibilité Always On

2. Après un basculement forcé, toutes les bases de données secondaires sont interrompues. Cela inclut les anciennes bases de données primaires, une fois que l’ancien réplica principal revient en ligne et découvre qu’il s’agit désormais d’un réplica secondaire. Vous devez reprendre manuellement chaque base de données interrompue individuellement sur chaque réplica secondaire.

   Lors de la reprise d'une base de données secondaire, la synchronisation de données commence avec la base de données primaire correspondante. La base de données secondaire restaure tous les enregistrements de journal qui n'ont jamais été validés sur la nouvelle base de données primaire. Par conséquent, si vous êtes préoccupé par la perte de données possible sur les bases de données primaires après basculement, vous devez tenter de créer un instantané de base de données sur les bases de données suspendues sur l’une des bases de données secondaires de validation synchrone.

   Important

   La troncation du journal des transactions est différée sur une base de données principale tant que l'une de ses bases de données secondaires est interrompue. En outre, l’intégrité de synchronisation d’une réplique secondaire d’engagement synchrone ne peut pas passer à HEALTHY tant qu’une base de données locale reste suspendue.

   Pour créer un instantané de base de données

   • Créer un instantané de base de données (Transact-SQL)

   Pour reprendre une base de données de disponibilité

   • Reprendre une base de données de disponibilité (SQL Server)

   Attention

   Après avoir réactivé toutes les bases de données secondaires, avant de tenter un nouveau basculement du groupe, attendez que chaque base de données secondaire sur la cible de basculement suivante entre dans l’état SYNCHRONIZING. Si une base de données n’est pas encore SYNCHRONIZING, cette base de données n’est pas encore en ligne en tant que base de données primaire et la resynchronisation des données pour la base de données peut nécessiter la restauration des journaux des transactions, la restauration d’une sauvegarde complète de la base de données ou le basculement vers le réplica principal précédent.

3. Si un réplica de disponibilité qui a échoué ne revient pas à l'état de réplica de disponibilité ou risque de revenir trop tard pour permettre la troncation du journal des transactions sur la nouvelle base de données primaire, envisagez de supprimer le réplica défaillant du groupe de disponibilité pour éviter d'épuiser l'espace disque destiné aux fichiers de journal.

   Pour supprimer un réplica secondaire

   • Supprimer un réplica secondaire d'un groupe de disponibilité (SQL Server)

4. Si vous suivez un basculement forcé avec un ou plusieurs basculements supplémentaires forcés, effectuez une sauvegarde de journal après chaque basculement forcé supplémentaire de la séquence. Pour plus d’informations expliquant ce phénomène, consultez « Risques posés par le basculement forcé » dans la section « Basculement manuel forcé (avec possible perte de données) » de Basculement et modes de basculement (groupes de disponibilité Always On).

   Pour effectuer une sauvegarde de fichier journal

   • Sauvegarder un journal des transactions

Exemple de scénario : Utiliser un basculement forcé pour récupérer à partir d’une défaillance catastrophique

Si le réplica principal échoue et qu'aucun réplica secondaire synchronisé n'est disponible, forcer le groupe de disponibilité à basculer peut constituer une réponse appropriée. La pertinence de forcer un basculement de secours dépend de : (1) si vous prévoyez que la réplique principale sera hors ligne plus longtemps que ce que tolère votre contrat de niveau de service (SLA), et (2) si vous êtes prêt à risquer une perte de données potentielle pour rendre rapidement disponibles les bases de données primaires. Si vous décidez qu'un groupe de disponibilité nécessite un basculement forcé, ce dernier ne constitue qu'une étape dans un processus plus complexe.

Pour illustrer les étapes nécessaires à l’utilisation d’un basculement forcé pour effectuer une récupération après une défaillance catastrophique, cet article présente un scénario de récupération d’urgence possible. Ce scénario d'exemple implique un groupe de disponibilité dont la topologie d'origine consiste en un centre de données principal qui héberge trois réplicas de disponibilité avec validation synchrone, y compris le réplica principal, et un centre de données distant qui héberge deux réplicas secondaires avec validation asynchrone. La figure suivante illustre la topologie d'origine de ce groupe de disponibilité d'exemple. Le groupe de disponibilité est hébergé par un cluster WSFC à plusieurs sous-réseaux avec trois nœuds dans le centre de données principal (nœud 01, nœud 02et nœud 03) et deux nœuds dans un centre de données distant (nœud 04 et nœud 05).

Le centre de données principal s'arrête de manière inattendue. Ses trois réplicas de disponibilité passent en mode hors connexion et leurs bases de données deviennent indisponibles. La figure suivante illustre l’effet de cette défaillance sur la topologie du groupe de disponibilité.

L'administrateur de base de données détermine que la meilleure réponse possible consiste à forcer le basculement du groupe de disponibilité vers l'un des réplicas secondaires distants avec validation asynchrone. Cet exemple illustre les étapes classiques impliquées lors du basculement forcé du groupe de disponibilité vers un réplica distant et, finalement, lors du retour du groupe de disponibilité à sa topologie d'origine.

La réponse à la défaillance présentée ici se décompose en deux phases, comme suit :

• Répondre à l’échec catastrophique du centre de données principal
• Renvoyer le groupe de disponibilité à sa topologie d’origine

Répondre à l’échec catastrophique du centre de données principal

La figure suivante illustre la série d'actions effectuées au niveau du centre de données distant en réponse à une défaillance catastrophique dans le centre de données principal.

Les étapes de cette illustration sont les suivantes :

Renvoyer le groupe de disponibilité à sa topologie d’origine

La figure suivante illustre la série d'actions qui permettent au groupe de disponibilité de retourner à sa topologie d'origine une fois que le centre de données principal revient en ligne et que les nœuds WSFC rétablissent la communication avec le cluster WSFC.

Les étapes de cette illustration sont les suivantes :

Tâches associées

Ajuster les votes de quorum

• Afficher les paramètres NodeWeight pour le quorum de cluster
• Configurer les paramètres NodeWeight pour un quorum de cluster
• Forcer un cluster WSFC à démarrer sans quorum

Basculement manuel planifié

• Effectuer un basculement manuel planifié d’un groupe de disponibilité Always On (SQL Server)
• Utiliser l’Assistant Basculement d’un groupe de disponibilité (SQL Server Management Studio)

Troubleshoot

• Résoudre des problèmes de configuration des groupes de disponibilité Always On (SQL Server)
• Résoudre une opération d’ajout de fichier ayant échoué (groupes de disponibilité Always On)

Contenu connexe

• Blogs de l’équipe de SQL Server Always On : Blog officiel de l’équipe de SQL Server Always On
• Blogs des ingénieurs du Service clientèle et du Support technique de SQL Server
• Guide de solutions Microsoft SQL Server Always On pour la haute disponibilité et la récupération d’urgence
• Qu’est-ce qu’un groupe de disponibilité Always On ?
• Différences entre les modes de disponibilité d’un groupe de disponibilité Always On
• Basculement et modes de basculement (groupes de disponibilité Always On)
• Types de connexions de client aux réplicas au sein d’un groupe de disponibilité Always On
• Outils pour monitorer les groupes de disponibilité AlwaysOn
• Clustering de basculement Windows Server avec SQL Server