Basculement et modes de basculement (groupes de disponibilité Always On)

S'applique à :SQL Server

Cet article décrit le basculement et les modes de basculement pour les groupes de disponibilité Always On de SQL Server.

Aperçu

Dans le contexte d'un groupe de disponibilité, le rôle principal et le rôle secondaire des réplicas de disponibilité sont généralement interchangeables au moyen d'un processus appelé basculement. Trois formes de basculement existent : basculement automatique (sans perte de données), basculement manuel planifié (sans perte de données) et basculement manuel forcé (avec perte de données possible), ce dernier étant généralement appelé basculement forcé. Le basculement automatique et le basculement manuel planifié conservent toutes vos données. Un groupe de disponibilité bascule au niveau d'un réplica de disponibilité. Autrement dit, un groupe de disponibilité bascule vers l’un de ses réplicas secondaires ( cible de basculementactuelle).

Pendant le basculement, la cible de basculement adopte le rôle principal, récupère ses bases de données et les met en ligne en tant que nouvelles bases de données primaires. Le réplica principal précédent, lorsqu'il est disponible, bascule vers le rôle secondaire, et ses bases de données deviennent des bases de données secondaires. Ces rôles peuvent éventuellement basculer plusieurs fois (ou vers une cible de basculement différente), soit en réponse à plusieurs défaillances, soit pour des raisons administratives.

Les formes de basculement qu’un réplica de disponibilité donné prend en charge sont spécifiées par la propriété du mode de basculement . Pour une réplique de disponibilité donnée, les modes de basculement possibles dépendent du mode de disponibilité de la réplique, comme suit :

• Les réplicas avec validation synchrone prennent en charge deux paramètres : automatique ou manuel. Le paramètre « automatic » prend en charge le basculement automatique et le basculement de manuel. Pour empêcher la perte de données, le basculement automatique et le basculement planifié requièrent que la cible de basculement soit un réplica secondaire avec validation synchrone et présente un état de synchronisation intègre (cela indique que chaque base de données secondaire sur la cible de basculement est synchronisée avec sa base de données primaire correspondante). Chaque fois qu'une réplique secondaire ne répond pas à ces deux conditions, elle ne prend en charge que le basculement forcé. Le basculement forcé est également pris en charge sur les répliques dans un état de résolution.

• Lesréplicas avec validation asynchrone prennent en charge uniquement le mode de basculement manuel. Puisqu'ils ne sont jamais synchronisés, ils ne supportent que le basculement forcé.

Modifications de SQL Server 2025

SQL Server 2025 présente les modifications suivantes :

Basculement rapide pour les problèmes de santé du système persistants

Dans un environnement de groupe de disponibilité Always On, le cluster de basculement Windows surveille l’intégrité du groupe de disponibilité et de ses réplicas. Lorsqu’un problème de santé est détecté sur le réplica principal, le cluster WSFC déclenche une séquence d’actions correctives. Par défaut, WSFC redémarre la ressource de groupe de disponibilité sur le réplica actuel. Si le cluster WSFC ne peut pas réactiver la ressource, le cluster WSFC bascule la ressource du groupe de disponibilité sur un autre réplica. Bien que cette séquence d’actions correctives soit efficace pour les défaillances temporaires, cela peut entraîner des retards de basculement pour les défaillances nontransientes.

Le comportement de basculement du WSFC est contrôlé par la valeur RestartThreshold. Par défaut, RestartThreshold est réglé sur 1 pour un groupe de disponibilité Always On, indiquant que WSFC tente de redémarrer la ressource sur le nœud actuel avant de procéder à un basculement.

À partir de SQL Server 2025 (17.x), vous pouvez définir la valeur de RestartThreshold pour un groupe de disponibilité Always On sur 0, ce qui indique au WSFC d'effectuer immédiatement la bascule de la ressource du groupe de disponibilité lorsque un problème d’intégrité persistant est détecté. Cela est utile dans des scénarios où vous souhaitez minimiser les temps d'arrêt et garantir que le groupe de disponibilité est toujours actif sur une réplique en bon état.

Il y a un compromis évident :

• En définissant RestartThreshold sur 1, votre groupe de disponibilité est plus tolérant aux défaillances temporaires et revient en ligne plus rapidement. Toutefois, le basculement et le temps d’arrêt peuvent être plus longs pour les défaillances persistantes.
• En définissant RestartThreshold sur 0, votre groupe de disponibilité est moins tolérant aux défaillances temporaires. Par conséquent, il peut basculer inutilement. Toutefois, le basculement et le temps d'arrêt peuvent être plus courts en cas de défaillances persistantes.

Vous pouvez utiliser le Gestionnaire du cluster de basculement ou PowerShell pour définir la ressource RestartThreshold d’un groupe de disponibilité Always On.

Par exemple, pour définir la RestartThreshold valeur 0 pour le groupe de disponibilité nommé ag1, utilisez la commande suivante :

(Get-ClusterResource -Name "ag1").RestartThreshold = 0

Vous pouvez vérifier votre paramètre actuel RestartThreshold en exécutant la commande suivante :

Get-ClusterResource -Name "ag1" | Format-List *

Amélioration de la distribution des requêtes de page asynchrones

Lorsqu’un groupe de disponibilité bascule, chaque réplica doit synchroniser en trouvant un point de récupération commun. Le point de récupération maintient le groupe de disponibilité stable afin qu’il puisse continuer à expédier des modifications. L’annulation de la restauration automatique fait partie de ce processus de synchronisation. Undo-of-redo se produit lorsqu’un réplica secondaire doit rétablir les transactions pour accéder au point de récupération commun. L’annulation de la restauration automatique est la plus courante lors du basculement de récupération d’urgence (DR) vers un réplica asynchrone avec FAILOVER_ALLOW_DATA_LOSS.

Dans certaines situations, avec un basculement de récupération d’urgence, à mesure que la réplique secondaire passe en réplique principale, la nouvelle réplique principale souffre de latence réseau par rapport à la réplique principale d’origine (nouvelle secondaire), ce qui ralentit l’annulation du redo sur la nouvelle réplique secondaire.

Pour améliorer l’annulation de restauration automatique pour ce scénario, SQL Server 2025 (17.x) introduit une mise à jour du mécanisme de synchronisation afin que le groupe de disponibilité effectue désormais des demandes de page de manière asynchrone et par lots.

Tenez compte des éléments suivants :

• L’amélioration du mécanisme de synchronisation est activée par défaut. Pour désactiver l’amélioration et rétablir le comportement par défaut, activez le trace flag 12348 sur tous les réplicas d’un groupe de disponibilité qui sont actuellement des réplicas secondaires, ou qui pourraient être secondaires à l’avenir.
• Si les réplicas du groupe de disponibilité n’ont pas de latence réseau, cette amélioration peut ne pas améliorer l’annulation de restauration automatique.

Les bases de données basculent vers l’état de résolution après un échec

Dans de rares cas, une ou plusieurs bases de données d’un groupe de disponibilité peuvent rester dans un état non synchronisant une fois qu’un groupe de disponibilité est hors connexion pendant une courte période en raison d’une perte de quorum WSFC temporaire, par exemple à partir d’une déconnexion réseau temporaire ou de la majorité des nœuds de cluster redémarrant. La mise à jour de la logique de récupération du groupe de disponibilité introduite dans SQL Server 2025 (17.x) améliore la tolérance interne à ce type de perte de quorum de cluster et empêche les bases de données de groupe de disponibilité de se bloquer dans l’état non synchronisant après le retour en ligne du groupe de disponibilité.

Termes et définitions

Basculement automatique
Basculement qui se produit automatiquement à la perte du réplica principal. Le basculement automatique est pris en charge uniquement lorsque le réplica principal actuel et un réplica secondaire sont tous les deux configurés en mode de basculement AUTOMATIQUE et que le réplica secondaire est actuellement synchronisé. Si le mode de basculement du réplica principal ou secondaire est MANUEL, le basculement automatique ne peut pas avoir lieu.

Basculement manuel planifié (sans perte de données)
Le basculement manuel planifié, ou basculement manuel, est un basculement qui est initié par un administrateur de base de données, en général pour des raisons administratives. Un basculement manuel planifié est pris en charge uniquement si le réplica principal et le réplica secondaire sont configurés en mode de validation synchrone et que les deux réplicas, principal et secondaire, sont actuellement synchronisés (dans l'état SYNCHRONIZED). Lorsque le réplica secondaire cible est synchronisé, un basculement manuel (sans perte de données) est possible même si le réplica principal est hors service car les bases de données secondaires sont prêtes pour le basculement. C'est l'administrateur de base de données qui initie manuellement un basculement manuel.

Basculement forcé (avec possible perte de données)
Basculement pouvant être initié par un administrateur de base de données lorsqu'aucune réplique secondaire n'est synchronisée avec la réplique principale ou lorsque la réplique principale n'est pas en fonctionnement et qu'aucune réplique secondaire n'est prête pour le basculement. Le basculement forcé présente un risque de perte des données et est exclusivement recommandé dans le cas d'une récupération d'urgence. Le basculement forcé est également appelé « basculement manuel forcé » car il ne peut être initié que manuellement. Il s'agit de la seule forme de basculement prise en charge en mode de disponibilité avec validation asynchrone.

Groupe Basculements automatiques

Dans un groupe de disponibilité donné, paire de réplicas de disponibilité (réplica principal actuel compris) qui est configurée pour le mode de validation synchrone avec basculement automatique, le cas échéant. Un groupe des basculements automatiques est appliqué uniquement si le réplica secondaire se trouve actuellement en mode SYNCHRONIZED avec le réplica principal.

Groupe Basculements avec validation synchrone

Dans un groupe de disponibilité donné, un groupe de deux ou trois réplicas de disponibilité (réplica principal actuel compris) qui est configuré pour le mode de validation synchrone, le cas échéant. Un groupe de basculements avec validation synchrone est appliqué uniquement si les réplicas secondaires sont configurés pour le mode de basculement manuel et qu'au moins un réplica secondaire se trouve actuellement en mode SYNCHRONIZED avec le réplica principal.

Groupe Intégralité des basculements

Dans un groupe de disponibilité donné, l'ensemble de tous les réplicas de disponibilité dont l'état opérationnel est actuellement ONLINE, quel que soit le mode de disponibilité et le mode de basculement. Le groupe de basculements devient approprié lorsqu'aucun réplica secondaire ne se trouve actuellement en mode SYNCHRONIZED avec le réplica principal.

Présentation du basculement

Le tableau ci-dessous résume les formes de basculement prises en charge dans différents modes de disponibilité et de basculement. Pour chaque jumelage, le mode de disponibilité et le mode de basculement effectifs sont déterminés par l’intersection des modes du réplica principal, ainsi que les modes d’un ou plusieurs réplicas secondaires.

¹ Si vous envoyez une commande de basculement forcé sur une copie secondaire synchronisée, la copie secondaire se comporte de la même façon que lors d'un basculement manuel.

La durée pendant laquelle la base de données n'est pas disponible lors d'un basculement dépend du type de basculement et de la raison de ce dernier.

Ensembles de basculement

Les formes de basculement possibles pour un groupe de disponibilité donné peuvent être présentées en termes de groupes de basculement. Un groupe de basculement comprend le réplica principal et les réplicas secondaires qui prennent en charge un type donné de basculement, comme suit :

• Ensemble de basculement automatique (facultatif) : dans un groupe de disponibilité donné, paire de réplicas de disponibilité (réplica principal actuel compris) qui est configurée pour le mode de validation synchrone avec basculement automatique, le cas échéant. Un groupe des basculements automatiques est appliqué uniquement si le réplica secondaire se trouve actuellement en mode SYNCHRONIZED avec le réplica principal.

• Ensemble de basculement en validation synchrone (facultatif) : dans un groupe de disponibilité donné, groupe de deux ou trois réplicas de disponibilité (réplica principal actuel compris) qui est configuré pour le mode de validation synchrone, le cas échéant. Un groupe de basculements avec validation synchrone est appliqué uniquement si les réplicas secondaires sont configurés pour le mode de basculement manuel et qu'au moins un réplica secondaire se trouve actuellement en mode SYNCHRONIZED avec le réplica principal.

• Ensemble de basculement complet : dans un groupe de disponibilité donné, ensemble de tous les réplicas de disponibilité dont l’état opérationnel est actuellement ONLINE, quels que soient le mode de disponibilité et le mode de basculement. Le groupe de basculements devient approprié lorsqu'aucun réplica secondaire ne se trouve actuellement en mode SYNCHRONIZED avec le réplica principal.

Lorsque vous configurez un réplica de disponibilité en tant que validation synchrone avec basculement automatique, le réplica de disponibilité devient partie intégrante du groupe des basculements automatiques. Toutefois, l'entrée en vigueur de l'ensemble dépend du réplica principal actuel. Les formes de basculement qui sont en fait possibles à un moment donné dépendent des ensembles de basculement actuellement en vigueur.

Prenons par exemple un groupe de disponibilité qui dispose de quatre réplicas de disponibilité, comme suit :

Le comportement du basculement pour chaque réplica secondaire dépend du réplica de disponibilité qui correspond actuellement au réplica principal. En principe, pour un réplica secondaire donné, le comportement de basculement est le pire cas pour le réplica principal actuel. La figure suivante montre comment le comportement de basculement des réplicas secondaires varie en fonction du réplica principal actuel et indique s’il est configuré pour le mode de validation asynchrone (avec uniquement le basculement forcé) ou le mode de validation synchrone (avec ou sans basculement automatique).

Basculement automatique

Un basculement automatique entraîne la transition automatique d'un réplica secondaire qualifié vers le rôle principal une fois que le réplica principal n'est plus disponible. Le basculement automatique convient idéalement lorsque le nœud WSFC qui héberge le réplica principal est local au nœud qui héberge le réplica secondaire. Cela est dû au fait que la synchronisation des données fonctionne mieux avec une faible latence de message entre les ordinateurs et parce que les connexions clientes peuvent rester locales.

Dans cette section :

• Conditions requises pour un basculement automatique

• Fonctionnement du basculement automatique

• Pour activer le basculement automatique

Conditions requises pour un basculement automatique

Le basculement automatique intervient uniquement dans les conditions suivantes :

• Il existe un groupe de basculements automatiques. Ce groupe se compose d’un réplica principal et d’un réplica secondaire (la cible du basculement automatique) qui sont tous les deux configurés pour le mode de validation synchrone et sont définis en mode de basculement automatique (AUTOMATIC). Si le réplica principal est défini sur le basculement manuel, le basculement automatique ne peut pas se produire, même si un réplica secondaire est défini sur basculement automatique.

  Pour plus d’informations, consultez Modes de disponibilité (groupes de disponibilité Always On).

• L'état de synchronisation de la cible de basculement automatique est sain (cela indique que chaque base de données secondaire sur la cible de basculement est synchronisée avec sa base de données primaire correspondante).

  Conseil

  Les groupes de disponibilité Always On surveillent l’intégrité des deux réplicas dans un ensemble de basculements automatiques. Si l'un ou l'autre réplica échoue, l'état d'intégrité du groupe de disponibilité est défini comme critique (CRITICAL). Si le réplica secondaire échoue, le basculement automatique n’est pas possible, car la cible de basculement automatique n’est pas disponible. Si le réplica principal échoue, le groupe de disponibilité bascule vers le réplica secondaire. Tant que le réplica principal précédent n'est pas à nouveau en ligne, il n'existe aucune cible de basculement automatique. Dans l'un et l'autre cas, pour garantir la disponibilité, dans le cas improbable d'une erreur de séquence, il est recommandé de configurer un réplica secondaire différent comme cible de basculement automatique.

  Pour plus d’informations, consultez Utiliser les stratégies Always On pour afficher l’intégrité d’un groupe de disponibilité (SQL Server) et Modifier le mode de basculement d’un réplica de disponibilité (SQL Server).

• Le cluster de basculement Windows Server (WSFC) a le quorum. Pour plus d’informations, consultez Modes de quorum WSFC et configuration de vote (SQL Server).

• Le réplica principal est devenu indisponible et les niveaux de condition de basculement définis par votre stratégie de basculement flexible ont été remplis. Pour plus d’informations sur les niveaux de condition de basculement, consultez Stratégie flexible pour le basculement automatique d’un groupe de disponibilité (SQL Server).

Fonctionnement du basculement automatique

Un basculement automatique initie la série d'actions suivante :

1. Si l'instance de serveur qui héberge le réplica principal actuel est encore en cours d'exécution, elle modifie l'état des bases de données primaires en DISCONNECTED et déconnecte tous les clients.

2. Si des enregistrements de journal sont en attente dans les files de récupération sur le réplica secondaire cible, le réplica secondaire applique les enregistrements de journal restants afin de terminer la restauration par progression des bases de données secondaires.

   Notes

   Le temps nécessaire pour appliquer le journal à une base de données particulière dépend de la vitesse du système, de la charge de travail récente et de la quantité de journal dans la file de récupération

3. Le réplica secondaire précédent joue alors le rôle principal. Ses bases de données deviennent les bases de données primaires. Le nouveau réplica principal restaure toutes les transactions non validées (phase de restauration de récupération) le plus rapidement possible. Les verrous isolent ces transactions non validées, ce qui permet une restauration en arrière-plan pendant que les clients utilisent la base de données. Ce processus ne restaure pas les transactions validées.

   Tant qu’une base de données secondaire donnée n’est pas connectée, elle est brièvement marquée comme NOT_SYNCHRONIZED. Avant le démarrage de la récupération de restauration, les bases de données secondaires peuvent se connecter aux nouvelles bases de données primaires et passer rapidement à l'état SYNCHRONIZED. Le meilleur cas est généralement celui où un troisième réplica avec validation synchrone reste dans le rôle secondaire après le basculement.

4. Par la suite, lorsque l'instance de serveur qui héberge le réplica principal précédent redémarre, il identifie qu'un autre réplica de disponibilité joue maintenant le rôle principal. Le réplica principal précédent joue à présent le rôle secondaire, et ses bases de données deviennent des bases de données secondaires. Le nouveau réplica secondaire se connecte au réplica principal actuel et rattrape sa base de données pour qu'elle soit au niveau des bases de données primaires actuelles le plus rapidement possible. Dès que le nouveau réplica secondaire a resynchronisé ses bases de données, le basculement est à nouveau possible, mais en sens inverse.

Pour configurer un basculement automatique

Un réplica de disponibilité peut être configuré pour prendre en charge le basculement automatique à tout moment.

Pour configurer un basculement automatique

1. Vérifiez que le réplica secondaire est configuré pour utiliser le mode de disponibilité avec validation synchrone. Pour plus d’informations, consultez Modifier le mode de disponibilité d’un réplica de disponibilité (SQL Server).

2. Définissez le basculement en mode automatique. Pour plus d’informations, consultez Modifier le mode de basculement d’un réplica de disponibilité (SQL Server).

3. Si vous le souhaitez, modifiez la stratégie de basculement flexible du groupe de disponibilité pour spécifier les types d'échecs qui peuvent déclencher un basculement automatique. Pour plus d’informations, consultez Configurer la stratégie de basculement flexible pour contrôler les conditions du basculement automatique (groupes de disponibilité Always On) et Stratégie de basculement pour les instances de cluster de basculement.

Basculement manuel planifié (sans perte de données)

Un basculement manuel provoque la transition d'un réplica secondaire synchronisé vers le rôle principal après qu'un administrateur de base de données a émis une commande de basculement manuel sur l'instance de serveur qui héberge le réplica secondaire cible. Pour prendre en charge le basculement manuel, le réplica secondaire et le réplica principal actuel doivent tous deux être configurés pour le mode de validation synchrone, le cas échéant. Chaque base de données secondaire sur le réplica de disponibilité doit être jointe au groupe de disponibilité et être synchronisée avec sa base de données primaire correspondante (autrement dit, le réplica secondaire doit être synchronisé). Cela garantit que chaque transaction validée sur une base de données primaire précédente a également été validée sur la nouvelle base de données primaire. Par conséquent, les nouvelles bases de données primaires sont identiques aux anciennes bases de données primaires.

L'illustration suivante montre les étapes d'un basculement planifié :

1. Avant le basculement, le réplica principal est hébergé par l'instance de serveur sur Node01.

2. C'est l'administrateur de base de données qui initie un basculement planifié. La cible de basculement est le réplica de disponibilité hébergé par l'instance de serveur sur Node02.

3. La cible de basculement (sur Node02) devient le nouveau réplica principal. Comme il s'agit d'un basculement planifié, le réplica principal précédent passe sur le rôle secondaire pendant le basculement et met immédiatement ses bases de données en ligne comme bases de données secondaires.

Dans cette section :

• Conditions requises pour un basculement manuel

• Fonctionnement du basculement manuel

• Maintien de la disponibilité lors des mises à niveau

Conditions requises pour un basculement manuel

Pour prendre en charge un basculement manuel, le réplica principal actuel doit être défini sur le mode de validation synchrone et un réplica secondaire doit être :

• configuré pour le mode de validation synchrone ;

• actuellement synchronisé avec le réplica principal.

Pour basculer manuellement un groupe de disponibilité, vous devez être connecté au réplica secondaire qui va devenir le nouveau réplica principal.

Fonctionnement d'un basculement manuel planifié

Un basculement manuel planifié, qui doit être initié sur le réplica secondaire cible, démarre la séquence d'actions suivante :

1. Pour vous assurer qu'aucune nouvelle transaction utilisateur ne se produira sur les bases de données primaires d'origine, le cluster WSFC envoie une demande de mise hors connexion au réplica principal.

2. Si un journal est en attente dans la file de récupération d'une base de données secondaire, le réplica secondaire termine la restauration par progression de cette base de données secondaire. Le temps requis pour cette opération dépend de la vitesse du système, de la charge de travail récente et de la quantité de journal dans la file de récupération. Pour connaître la taille actuelle de la file de récupération, utilisez le compteur de performance File de récupération . Pour plus d’informations, consultez SQL Server, réplica de base de données.

   Notes

   La durée de basculement peut être régulée en limitant la taille de la file de récupération. Cependant, cela peut entraîner un ralentissement du réplica principal afin de permettre au réplica secondaire de suivre.

3. Le réplica secondaire devient le nouveau réplica principal, tandis que le réplica principal précédent devient le nouveau réplica secondaire.

4. Le nouveau réplica principal annule toutes les transactions non validées et met ses bases de données en ligne comme bases de données principales. Toutes les bases de données secondaires sont brièvement marquées comme NOT SYNCHRONIZED jusqu’à ce qu’elles se connectent et resynchronisent aux nouvelles bases de données primaires. Ce processus ne restaure pas les transactions validées.

5. Lorsque le réplica principal précédent revient en ligne, il prend le rôle secondaire, et la base de données primaire précédente devient la base de données secondaire. Le nouveau réplica secondaire resynchronise rapidement les nouvelles bases de données secondaires avec les bases de données primaires correspondantes.

   Notes

   Dès que le nouveau réplica secondaire a resynchronisé les bases de données, le basculement est à nouveau possible, mais en sens inverse.

Après le basculement, les clients doivent se reconnecter à la base de données primaire actuelle. Pour plus d’informations, consultez Écouteurs de groupe de disponibilité, connectivité client et basculement d’application (SQL Server).

Maintien de la disponibilité lors des mises à niveau

L'administrateur de base de données de vos groupes de disponibilité peut faire appel à des basculements manuels pour maintenir la disponibilité de la base de données lorsque vous mettez à niveau le matériel ou le logiciel. Pour utiliser un groupe de disponibilité pour les mises à niveau logicielles, l'instance de serveur et/ou le nœud ordinateur qui héberge le réplica secondaire cible doivent avoir déjà reçu les mises à niveau. Pour plus d’informations, consultez Mise à niveau d’instances de réplica d’un groupe de disponibilité Always On.

Basculement forcé (avec possible perte de données)

Forcer le basculement d’un groupe de disponibilité (avec perte de données possible) est une méthode de récupération d’urgence qui vous permet d’utiliser une réplique secondaire comme serveur de secours chaud. Étant donné que le basculement forcé risque de perte de données, il doit être utilisé avec prudence et parcimonie. Nous recommandons de forcer le basculement uniquement si vous devez restaurer immédiatement le service sur vos base de données de disponibilité et que vous êtes prêt à courir le risque de perdre des données. Pour plus d’informations sur les prérequis et sur les recommandations pour un basculement forcé, ainsi que pour obtenir un exemple de scénario de basculement forcé afin d’effectuer une récupération suite à une défaillance irrémédiable, consultez Effectuer un basculement manuel forcé d’un groupe de disponibilité (SQL Server).

Dans cette section :

• Fonctionnement du basculement forcé

• Risques posés par le basculement forcé

• Raisons pour lesquelles le basculement forcé est requis après avoir forcé le quorum

• Suivi de la perte de données potentielle

• Gestion de la perte de données potentielle

Fonctionnement du basculement forcé

Le fait de forcer le basculement initie la transition du rôle principal sur un réplica cible dont le rôle est dans l'état SECONDARY ou RESOLVING. La cible de basculement devient le nouveau réplica principal et sert immédiatement ses copies de base de données aux clients. Lorsque l’ancien réplica principal devient disponible, il passe au rôle secondaire et ses bases de données deviennent des bases de données secondaires.

Toutes les bases de données secondaires (y compris les anciennes bases de données primaires, lorsqu'elles deviennent disponibles) sont interrompues (SUSPENDED). En fonction de l'état précédent de synchronisation des données d'une base de données secondaire interrompue, il peut convenir pour récupérer des données validées manquantes pour cette base de données primaire. Sur un réplica secondaire configuré pour autoriser l'accès en lecture seule, vous pouvez interroger les bases de données secondaires afin de découvrir manuellement des données manquantes. Vous pouvez ensuite émettre des instructions Transact-SQL sur les nouvelles bases de données primaires pour effectuer les modifications nécessaires.

Risques posés par le basculement forcé

Il est essentiel de comprendre que le basculement forcé peut entraîner une perte de données. La perte de données est possible, car le réplica cible ne peut pas communiquer avec le réplica principal et, par conséquent, ne peut pas garantir que les bases de données sont synchronisées. Le basculement forcé démarre un nouveau point de branchement de récupération. Étant donné que les bases de données primaires d’origine et les bases de données secondaires se trouvent sur des forks de récupération différents, chacun d’eux contient désormais des données que l’autre base de données ne contient pas : chaque base de données primaire d’origine contient les modifications qui n’ont pas encore été envoyées de sa file d’attente d’envoi à l’ancienne base de données secondaire (le journal non envoyé) ; les anciennes bases de données secondaires contiennent les modifications qui se produisent après le basculement forcé.

Si le basculement est forcé parce que le réplica principal avait échoué, la perte de données potentielle dépend de l'envoi ou non des journaux de transactions au réplica secondaire avant l'échec. En mode de validation asynchrone, une accumulation du journal non envoyé est toujours possible. En mode de validation synchrone, cela est possible uniquement tant que les bases de données secondaires ne sont pas synchronisées.

Le tableau suivant résume la possibilité de perte de données pour une base de données particulière sur le réplica vers lequel vous forcez le basculement.

Les bases de données secondaires suivent uniquement deux branchements de récupération. Par conséquent, si vous exécutez plusieurs basculements forcés, il est possible que certaines bases de données secondaires qui ont démarré la synchronisation des données avec le basculement forcé précédent, ne puissent pas être reprises. Si cela se produit, toutes les bases de données secondaires qui ne peuvent pas être reprise doivent être supprimées du groupe de disponibilité, restaurées à un point correct dans le temps et jointes au groupe de disponibilité. L’erreur 1408 avec état 103 peut être observée dans ce scénario (erreur : 1408, gravité : 16, état : 103). Une restauration ne fonctionnera pas entre plusieurs branchements de récupération, par conséquent, vous devez veiller à sauvegarder le journal après l'exécution de plus d'un basculement forcé.

Raisons pour lesquelles le basculement forcé est requis après avoir forcé le quorum

Une fois le quorum forcé sur le cluster WSFC, vous devez effectuer un basculement forcé (avec perte de données possible) sur chaque groupe de disponibilité. Le basculement forcé est requis, car l'état réel des valeurs de cluster WSFC peut avoir été perdu. Il est nécessaire d’empêcher les basculements normaux après un quorum forcé en raison de la possibilité qu’une réplique secondaire non synchronisée apparaisse comme synchronisée sur le cluster WSFC reconfiguré.

Prenons l’exemple d’un cluster WSFC qui héberge un groupe de disponibilité sur trois nœuds : le nœud A héberge le réplica principal, et les nœuds B et C hébergent un réplica secondaire. Le nœud C est déconnecté du cluster WSFC tandis que le réplica secondaire local est SYNCHRONIZED. Mais le nœud A et le nœud B conservent un quorum sain et le groupe de disponibilité reste en ligne. Sur le nœud A, le réplica principal continue d'accepter les mises à jour, et sur le nœud B, le réplica secondaire continue d'être synchonisé avec le réplica principal. Le réplica secondaire sur le nœud C n'est plus synchronisé et passe de plus en plus derrière le réplica principal. Toutefois, étant donné que le nœud C est déconnecté, le réplica reste incorrectement dans l'état SYNCHRONIZED.

Si le quorum est perdu et s’il est ensuite forcé sur le nœud A, l’état de synchronisation du groupe de disponibilité sur le cluster WSFC devrait être correct, et le réplica secondaire sur le nœud C apparaît comme UNSYNCHRONIZED. Toutefois, si le quorum est forcé sur le nœud C, la synchronisation du groupe de disponibilité sera incorrecte. L’état de synchronisation sur le cluster retrouve le même niveau que lorsque le nœud C a été déconnecté, et le réplica secondaire sur le nœud C apparaît incorrectement comme SYNCHRONIZED. Étant donné que les basculements manuels planifiés garantissent la sécurité des données, ils sont interdits de redémarrer un groupe de disponibilité après avoir forcé le quorum.

Suivi de la perte de données potentielle

Lorsque le cluster WSFC a un quorum sain, vous pouvez estimer le risque potentiel actuel de perte de données sur les bases de données. Pour un réplica secondaire donné, le risque potentiel actuel de perte de données dépend du décalage des bases de données secondaires par rapport aux bases de données primaires correspondantes. Étant donné que le décalage varie dans le temps, nous vous recommandons de suivre régulièrement la perte de données potentielle de vos bases de données secondaires non synchronisées. Le suivi du décalage implique de comparer le LSN de dernière validation et l'Heure de dernière validation de chaque base de données primaire avec ses bases de données secondaires, comme suit :

1. Connectez-vous au réplica principal.

2. Interrogez les colonnes last_commit_lsn (LSN de la dernière transaction validée) et last_commit_time (heure de la dernière validation) de la vue de gestion dynamique sys.dm_hadr_database_replica_states .

3. Comparez les valeurs retournées pour chaque base de données primaire et pour chacune de ses bases de données secondaires. La différence entre leurs LSN de dernière validation indique le niveau du décalage.

4. Vous pouvez déclencher une alerte lorsque le niveau de décalage de la base de données, ou d'un ensemble de bases de données, dépasse le décalage maximal autorisé pour une période donnée. Par exemple, la requête peut être exécutée par une tâche qui s'exécute toutes les minutes sur chaque base de données primaire. Si la différence entre la valeur last_commit_time d’une base de données primaire et de chacune de ses bases de données secondaires dépasse l’objectif de point de récupération (par exemple, 5 minutes) depuis la dernière exécution du travail, celui-ci peut déclencher une alerte.

Gestion de la perte de données potentielle

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.

Une fois l'ancien réplica principal disponible, en supposant que ses bases de données ne soient pas endommagées, vous pouvez tenter de gérer la perte de données potentielle. L'approche disponible pour gérer la perte de données potentielle varie selon que le réplica principal d'origine s'est connecté au nouveau réplica principal. En supposant que le réplica principal d'origine puisse accéder à la nouvelle instance principale, la reconnexion se produit automatiquement et de manière transparente.

Le réplica principal d'origine s'est reconnecté

En général, après une défaillance, lorsque le réplica principal d'origine redémarre, il se reconnecte rapidement à son partenaire. Lors de la reconnexion, le réplica principal d'origine devient le réplica secondaire. Ses bases de données deviennent les bases de données secondaires et entrent dans l’état SUSPENDED. Les nouvelles bases de données secondaires ne seront pas annulées, sauf si vous les redémarrez.

Toutefois, les bases de données suspendues sont inaccessibles. Vous ne pouvez donc pas les inspecter pour évaluer les données qui seraient perdues si vous deviez reprendre une base de données donnée. Par conséquent, la décision de reprendre ou de supprimer une base de données secondaire dépend de la volonté d’accepter une perte de données, comme suit :

• Si la perte de données est inacceptable, vous devez supprimer les bases de données du groupe de disponibilité afin de les sauver.

  L'administrateur de base de données peut maintenant récupérer les bases de données primaires précédentes et tenter de récupérer les données qui auraient sinon été perdues. Toutefois, lorsqu’une ancienne base de données primaire est en ligne, elle diffère de la base de données primaire actuelle. Par conséquent, l’administrateur de la base de données doit rendre la base de données supprimée ou la base de données primaire actuelle inaccessible aux clients afin d’éviter une autre divergence des bases de données et d’éviter les problèmes de basculement du client.

• Si la perte de données est acceptable dans le cadre de vos objectifs professionnels, vous pouvez rétablir les bases de données secondaires.

  La reprise d'une nouvelle base de données secondaire entraîne sa restauration en guise de première étape vers la synchronisation de la base de données. Si des enregistrements de journal se trouvaient dans la file d'attente d'envoi au moment de la défaillance, les transactions correspondantes sont perdues, même si elles ont été validées.

La réplique principale d’origine n'a pas rétabli la connexion

Si vous pouvez empêcher momentanément le réplica principal d'origine de se reconnecter par le biais du réseau au nouveau réplica principal, vous pouvez inspecter les bases de données primaires d'origine afin d'évaluer les données qui seraient perdues en cas de reprise.

• Si la perte de données potentielle est acceptable

  Permettez au réplica principal d'origine se reconnecter au nouveau réplica principal. La reconnexion provoque l'interruption des nouvelles bases de données secondaires. Pour démarrer la synchronisation des données sur une base de données, il suffit de reprendre cette dernière. Le nouveau réplica secondaire supprime le branchement de récupération d'origine de cette base de données, ce qui entraîne la perte des transactions qui n'ont jamais été ni reçues ni envoyées par l'ancien réplica secondaire.

• Si la perte de données est inacceptable

  Si la base de données primaire d'origine contient des données stratégiques qui seront perdues si vous rétablissez la base de données interrompue, vous pouvez préserver les données sur la base de données primaire d'origine en la supprimant du groupe de disponibilité. Cela fait passer la base de données à l'état RESTORING. À ce stade, nous vous recommandons d'essayer de sauvegarder la fin du journal de la base de données supprimée. Ensuite, vous pouvez mettre à jour le réplica principal actuel (l'ancienne base de données secondaire) en exportant les données que vous souhaitez sauver à partir de la base de données primaire d'origine et en les important dans la base de données primaire actuelle. Nous vous recommandons d'effectuer aussi rapidement que possible une sauvegarde complète de la base de données primaire mise à jour.

  Puis, sur l'instance de serveur qui héberge le nouveau réplica secondaire, vous pouvez supprimer la base de données secondaire interrompue et créer une nouvelle base de données secondaire en restaurant cette sauvegarde (et au moins une sauvegarde de fichier journal suivante) à l'aide de RESTORE WITH NORECOVERY. Nous vous recommandons de retarder les sauvegardes de fichiers journaux supplémentaires des bases de données primaires actuelles jusqu'à ce que les bases de données secondaires correspondantes soient rétablies.

Contenu connexe

• Vue d’ensemble des groupes de disponibilité Always On (SQL Server)
• Modes de disponibilité (Groupes de disponibilité Always On)
• Clustering de basculement Windows Server (WSFC) avec SQL Server
• 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)
• Stratégie de basculement pour les instances de cluster de basculement
• Stratégie flexible pour le basculement automatique d’un groupe de disponibilité (SQL Server)

Tâches associées

Configurer le comportement de basculement

• Modifier le mode de disponibilité d'un réplica de disponibilité (SQL Server)
• Modifier le mode de basculement d'un réplica de disponibilité (SQL Server)
• Configurer la stratégie de basculement flexible pour contrôler les conditions du basculement automatique (groupes de disponibilité Always On)

Effectuer un basculement manuel

• Effectuer un basculement manuel planifié d'un groupe de disponibilité (SQL Server)
• Effectuer un basculement manuel forcé d'un groupe de disponibilité (SQL Server)
• Utiliser l’Assistant Basculement d’un groupe de disponibilité (SQL Server Management Studio)
• Gestion des connexions et des travaux pour les bases de données d'un groupe de disponibilité (SQL Server)

Configurer la configuration du quorum WSFC

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