Effectuer un basculement manuel forcé d'un groupe de disponibilité (SQL Server)

  • Article

Cette rubrique explique comment effectuer un basculement forcé (avec perte de données potentielle) sur un groupe de disponibilité AlwaysOn à l'aide de SQL Server Management Studio, Transact-SQL ou de PowerShell dans SQL Server 2012. Un basculement forcé est une forme du basculement manuel qui est destiné exclusivement à 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 fortement de forcer le basculement uniquement si vous devez restaurer immédiatement un service dans le groupe de disponibilité et si vous êtes prêt à prendre 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 suspendue et vous devez les reprendre manuellement. Lorsque l'ancien réplica principal devient disponible, il adopte le rôle secondaire, et les anciennes bases de données principales deviennent les 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 différée sur une base de données principale donnée, lorsque l'une de ses bases de données secondaires est interrompue.

Important

La synchronisation des données avec la base de données principale n'est pas effectuée tant que la reprise de la base de données secondaire n'a pas eu lieu. Pour plus d'informations sur la reprise d'une base de données secondaire, consultez Tâches essentielles après un basculement forcé, plus loin dans cet article.

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 possible perte de données). 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 pouvez forcer le basculement sur l'instance de serveur qui hébergeait un réplica qui était le réplica principal avant d'avoir forcé le quorum ou un réplica secondaire qui était synchronisé avant d'avoir forcé le quorum. Pour plus d'informations, consultez Méthodes possibles pour éviter la perte de données après un quorum forcé, plus loin dans cette rubrique.

    Important

    Si le quorum est regagné par des moyens naturels au lieu d'être forcé, les réplicas de disponibilité seront récupérés normalement. 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 plus d'informations sur les raisons pour lesquelles le basculement forcé est requis après avoir forcé le quorum, consultez Basculement et modes de basculement (groupes de disponibilité AlwaysOn).

  • Si le réplica principal devient indisponible lorsque le cluster WSFC possède un quorum sain, vous pouvez forcer le basculement (avec perte de données possible), vers tout réplica dont le rôle est dans l'état SECONDARY ou 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.

    ConseilConseil

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

[!REMARQUE]

Pour plus d'informations sur les conditions préalables requises et les recommandations pour forcer un basculement et pour obtenir un exemple de scénario qui utilise un basculement forcé pour effectuer une récupération suite à une défaillance irrémédiable, consultez Exemple de scénario : utilisation d'un basculement forcé pour effectuer une récupération suite à une défaillance irrémédiable, plus loin dans cette rubrique.

  • Avant de commencer :  

    Limitations et restrictions

    Configuration requise

    Recommandations

    Méthodes possibles pour éviter la perte de données après un quorum forcé

    Sécurité

  • Pour forcer le basculement (avec possible perte de données), à l'aide de :  

    SQL Server Management Studio

    Transact-SQL

    PowerShell

  • Suivi :  Tâches essentielles après un basculement forcé

  • Exemple de scénario :  Utilisation d'un basculement forcé pour effectuer une récupération suite à une défaillance catastrophique

  • Tâches associées

  • Contenu connexe

Avant de commencer

Limitations et restrictions

  • Le seul cas où vous ne pouvez pas effectuer un basculement forcé est lorsque le cluster de clustering de basculement Windows Server (WSFC) ne dispose 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. Par conséquent, nous vous recommandons vivement de forcer le basculement uniquement si le réplica principal n'est plus exécuté et si vous êtes prêt à prendre le risque de perdre des données afin de restaurer l'accès aux bases de données dans le groupe de disponibilité.

  • Lorsqu'une base de données secondaire se trouve dans l'état REVERTING ou INITIALIZING, forcer le basculement entraîne l'impossibilité pour la base de données de démarrer en tant que base de données primaire. Si la base de données se trouvait dans un état INTIAILIZING, vous devez appliquer les enregistrements de journal manquants d'une sauvegarde de base de données ou restaurer entièrement la base de données. Si la base de données se trouvait dans un é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 bases de données sur plusieurs bases de données dans le groupe de disponibilité n'est pas conservée lors d'un basculement.

    [!REMARQUE]

    Les transactions entre bases de données et les transactions distribuées ne sont pas prises en charge par Groupes de disponibilité AlwaysOn. Pour plus d'informations, consultez Transactions entre bases de données non prises en charge pour la mise en miroir de bases de données ou les groupes de disponibilité AlwaysOn (SQL Server).

Configuration requise

Recommandations

  • Ne forcez pas le basculement lorsque le réplica principal est encore en exécution.

  • Si possible, forcez le basculement uniquement vers une cible de basculement dont les bases de données secondaires se trouvent dans l'état NOT SYNCHRONIZED, SYNCHRONIZED ou SYNCHRONIZING. Pour plus d'informations sur les conséquences d'un basculement forcé lorsqu'une base de données secondaire se trouve dans l'état INTIAILIZGING ou REVERTING, consultez Limitations et restrictions, plus haut dans cette rubrique.

  • En général, la latence d'une base de données secondaire donnée, par rapport à la base de données principale, 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.

    ConseilConseil

    Pour comparer des numéros séquentiels LSN de fin de journal, connectez-vous, à tour de rôle, à chacun des réplicas secondaires en ligne et interrogez sys.dm_hadr_database_replica_states pour connaître la valeur end_of_log_lsn 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. Notez que les différentes bases de données peuvent avoir leur plus haut numéro séquentiel LSN sur différents réplicas 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.

Méthodes possibles pour éviter la perte de données après un quorum 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 activé lors de la perte du quorum, vous pouvez déterminer si la perte de données a pu se produire sur une base de données 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')
    AttentionAttention

    Si le nœud restauré était désactivé lors de la perte du quorum, is_failover_ready peut ne pas refléter l'état réel du cluster lorsque le réplica principal a été mis hors connexion. Par conséquent, la valeur is_failover_ready est uniquement efficace si le nœud hôte était activé au moment de la défaillance. 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é AlwaysOn).

    Si is_failover_ready = 1, la base de données est marquée comme synchronisée dans le cluster et est prête pour le basculement. Si is_failover_ready = 1 sur chaque base de données sur 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 seront perdues sur cette base de données.

    [!REMARQUE]

    Lorsque vous forcez le basculement vers un réplica secondaire, la perte de données dépend du retard de la cible de basculement derrière le réplica principal. Malheureusement, lorsque le cluster WSFC ne dispose pas de quorum ou le quorum a été forcé, vous ne pouvez pas déterminer la perte de données. 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 la rubrique « Suivi de la perte potentielle de données » dans Basculement et modes de basculement (groupes de disponibilité AlwaysOn).

Sécurité

Autorisations

Requiert l'autorisation ALTER AVAILABILITY GROUP sur le groupe de disponibilité, l'autorisation CONTROL AVAILABILITY GROUP, l'autorisation ALTER ANY AVAILABILITY GROUP ou l'autorisation CONTROL SERVER.

Icône de flèche utilisée avec le lien Retour en haut[Haut de la page]

Utilisation de SQL Server Management Studio

Pour forcer le basculement (avec possible perte de données)

  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é devant être basculé 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 cette rubrique.

Icône de flèche utilisée avec le lien Retour en haut[Haut de la page]

Utilisation de Transact-SQL

Pour forcer le basculement (avec possible perte de données)

  1. 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é devant être basculé.

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

    ALTER AVAILABILITY GROUP group_name FORCE_FAILOVER_ALLOW_DATA_LOSS

    où group_name correspond au nom du groupe de disponibilité.

    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 Suivi : Tâches essentielles après un basculement forcé, plus loin dans cette rubrique.

Icône de flèche utilisée avec le lien Retour en haut[Haut de la page]

Utilisation de PowerShell

Pour forcer le basculement (avec possible perte de données)

  1. Changez le répertoire (cd) en 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é devant être basculé.

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

    • -AllowDataLoss

      Par défaut, avec le paramètre -AllowDataLoss, Switch-SqlAvailabilityGroup vous rappelle que le basculement forcé peut provoquer une perte de transactions non validées et vous demande confirmation. Pour continuer, entrez Y ; pour annuler l'opération, entrez N.

      L'exemple suivant exécute un basculement forcé (avec possible perte de données) 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 démarrer 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 se traduire par une perte de données des bases de données participant au groupe de disponibilité.

      L'exemple suivant exécute un basculement forcé (avec possible perte de données) 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

    [!REMARQUE]

    Pour afficher 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 sur 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 cette rubrique.

Pour configurer et utiliser le fournisseur SQL Server PowerShell

Icône de flèche utilisée avec le lien Retour en haut[Haut de la page]

Suivi : Tâches 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 :

  2. Après un basculement forcé, toutes les bases de données secondaires sont interrompues. Cela inclut les anciennes bases de données principales, une fois que l'ancien réplica principal est repassé en ligne et découvre qu'il s'agit maintenant 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 des données commence avec la base de données principale 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 principale. Par conséquent, si vous êtes inquiet de la possible perte de données sur les bases de données principales après le basculement, vous devez essayer de créer un instantané de base de données sur les bases de données interrompues sur l'une des bases de données secondaires avec 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. De même, l'état de synchronisation d'un réplica secondaire avec validation synchrone ne peut pas effectuer la transition vers l'état HEALTHY tant qu'une base de données locale reste interrompue.

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

    Pour reprendre une base de données de disponibilité

    AttentionAttention

    Après la reprise de toutes les bases de données secondaires, et avant de tenter un nouveau basculement du groupe, attendez que chaque base de données secondaire sur la cible de basculement suivante passe à l'état SYNCHRONIZING. Si une base de données ne présente encore l'état SYNCHRONIZING, cette base de données sera empêchée d'être mise en ligne en tant que base de données primaire, et le rétablissement de la synchronisation des données pour la base de données peut nécessiter la restauration des journaux de transactions, la restauration d'une sauvegarde complète de base de données ou le basculement vers le réplica principal précédent.

  3. Si un réplica de disponibilité ayant échoué ne retourne pas au réplica de disponibilité ou y retourne trop tard pour vous permettre de retarder la troncation du journal des transactions sur la nouvelle base de données primaire, supprimez le réplica défaillant du groupe de disponibilité afin d'éviter le risque de manquer d'espace sur le disque pour vos fichiers journaux.

    Pour supprimer un réplica secondaire

  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é AlwaysOn).

    Pour effectuer une sauvegarde de fichier journal

Icône de flèche utilisée avec le lien Retour en haut[Haut de la page]

Exemple de scénario : utilisation d'un basculement forcé pour effectuer une récupération suite à 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 d'un basculement forcé varie : (1) selon que vous vous attendez ou non à ce que le réplica principal reste hors connexion pendant une durée plus longue que celle tolérée par votre contrat de qualité de service (SLA), et (2) selon que vous êtes prêt à prendre le risque de perdre éventuellement des données afin de mettre les bases de données principales à disposition le plus rapidement possible. 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 requises pour utiliser un basculement forcé afin d'opérer une récupération suite à une défaillance catastrophique, cette rubrique présente un possible scénario de récupération d'urgence. 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 02 et nœud 03) et deux nœuds dans un centre de données distant (nœud 04 et nœud 05).

Topologie d'origine du groupe de disponibilité

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'impact de cette défaillance sur la topologie du groupe de disponibilité.

Topologie après la défaillance du centre de données principal

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éponse à la défaillance catastrophique du centre de données principal

  • Retour du groupe de disponibilité à sa topologie d'origine

Réponse à la défaillance 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.

Procedure de réponse à la défaillance du centre de données principal

Les étapes de cette illustration sont les suivantes :

Étape

Action

Liens

1.

L'administrateur de bases de données ou réseau s'assure que le cluster WSFC dispose d'un quorum sain. Dans cet exemple, le quorum doit être forcé.

2.

L'administrateur de bases de données se connecte à l'instance du serveur présentant la latence la plus faible (sur le nœud 04) et effectue un basculement manuel forcé. Le basculement forcé fait passer ce réplica secondaire au rôle principal et interrompt les bases de données secondaires sur le réplica secondaire restant (sur le nœud 05).

3.

L'administrateur de bases de données rétablit chacune des bases de données secondaires sur le réplica secondaire restant.

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

Icône de flèche utilisée avec le lien Retour en haut[Haut de la page]

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

Important

Si le quorum du cluster WSFC a été forcé, lorsque les nœuds hors connexion redémarrent, il est possible qu'ils forment un nouveau quorum si les deux conditions suivantes sont réunies : (a) il n'existe aucune connectivité de réseau entre les nœuds dans le quorum forcé défini, et (b) les nœuds qui redémarrent représentent la majorité des nœuds de cluster. Cela se traduirait par un fractionnement des partitions, condition dans laquelle le groupe de disponibilité posséderait deux réplicas principaux indépendants, un sur chaque centre de données. Avant de forcer un quorum afin de créer un quorum minoritaire défini, consultez Récupération d'urgence WSFC par le quorum forcé (SQL Server).

Procedure pour retourner le groupe à sa topologie d'origine

Les étapes de cette illustration sont les suivantes :

Étape

Liens

1.

Les nœuds du centre de données principal reviennent en ligne et rétablissent la communication avec le cluster WSFC. Leurs réplicas de disponibilité reviennent en ligne en tant que réplicas secondaires avec des bases de données interrompues et l'administrateur de bases de données doit rétablir manuellement chacune d'entre elles dans un bref délai.

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

ConseilConseil

Si vous êtes inquiet de la possible perte de données sur les bases de données principales suite au basculement, vous devez essayer de créer un instantané de base de données sur les bases de données interrompues sur l'une des bases de données secondaires avec validation synchrone. Gardez à l'esprit que la troncation du journal des transactions est différée sur une base de données principale, lorsque l'une de ses bases de données secondaires est interrompue. De même, l'état de synchronisation du réplica secondaire avec validation synchrone ne peut pas effectuer la transition vers l'état HEALTHY tant qu'une base de données locale reste interrompue.

2.

Une fois que les bases de données ont repris, l'administrateur de bases de données change le nouveau réplica principal pour qu'il passe en mode de validation synchrone de manière temporaire. Cela implique deux étapes :

  1. Modifiez un réplica de disponibilité hors connexion en mode de validation asynchrone.

  2. Modifiez le nouveau réplica principal en mode de validation synchrone.

[!REMARQUE]

Cette étape permet aux bases de données secondaires avec validation synchrone ayant repris de devenir synchronisées (SYNCHRONIZED).

Modifier le mode de disponibilité d'un réplica de disponibilité (SQL Server)

3.

Une fois que le réplica secondaire avec validation synchrone sur le nœud 03 (le réplica principal d'origine) passe à l'état de synchronisation HEALTHY, l'administrateur de bases de données effectue un basculement planifié manuel vers ce réplica, afin d'en faire à nouveau le réplica principal. Le réplica sur le nœud 04 redevient un réplica secondaire.

4.

L'administrateur de bases de données se connecte au nouveau réplica principal et :

  1. Modifie l'ancien réplica principal (dans le centre distant) pour qu'il repasse en mode de validation asynchrone.

  2. Modifie le réplica secondaire avec validation asynchrone dans le centre de données principal pour qu'il repasse en mode de validation synchrone.

Modifier le mode de disponibilité d'un réplica de disponibilité (SQL Server)

Icône de flèche utilisée avec le lien Retour en haut[Haut de la page]

Tâches associées

Pour ajuster les votes de quorum

Basculement manuel planifié :

Pour dépanner :

Icône de flèche utilisée avec le lien Retour en haut[Haut de la page]

Contenu connexe

Icône de flèche utilisée avec le lien Retour en haut[Haut de la page]

Voir aussi

Concepts

Vue d'ensemble des groupes de disponibilité AlwaysOn (SQL Server)

Modes de disponibilité (groupes de disponibilité AlwaysOn)

Basculement et modes de basculement (groupes de disponibilité AlwaysOn)

À propos de l'accès de la connexion client aux réplicas de disponibilité (SQL Server)

Surveillance des groupes de disponibilité (SQL Server)

Clustering de basculement Windows Server (WSFC) avec SQL Server