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 permutables dans le cadre 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 (l’actuelle cible de basculement).

Pendant le basculement, la cible de basculement assume le rôle principal, restaure ses bases de données et les met en ligne en tant que nouvelles bases de données primaires. L’ancienne réplique principale, lorsqu’elle est disponible, passe au 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 à validation synchrone prennent en charge deux modes : automatique ou manuel. Le paramètre « automatique » prend en charge à la fois le basculement automatique et le basculement manuel. Pour éviter toute perte de données, le basculement automatique et le basculement planifié exigent que la cible de basculement soit un réplica secondaire avec validation synchrone et dans un état de synchronisation 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). 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.

• Les réplicas à validation asynchrone prennent uniquement en charge 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
Un basculement s’effectue automatiquement en cas de perte de la réplique principale. 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 possible uniquement si le réplica principal et le réplica secondaire sont configurés en mode de validation synchrone, et si le réplica principal et le réplica 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é comporte un risque de perte de données et est strictement recommandé pour la reprise après sinistre. 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.

Ensemble de basculement automatique

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. Une configuration de basculement automatique prend effet uniquement si le réplica secondaire est actuellement synchronisé avec le réplica principal.

Ensemble de basculement à 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 ensemble de basculement à validation synchrone prend effet uniquement si les réplicas secondaires sont configurés en mode de basculement manuel et qu’au moins un réplica secondaire est actuellement à l’état SYNCHRONIZED avec le réplica principal.

Ensemble de basculement complet

Dans un groupe de disponibilité donné, l’ensemble des réplicas de disponibilité dont l’état opérationnel est actuellement ONLINE, indépendamment du mode de disponibilité et du mode de basculement. L’ensemble de basculement entre en ligne de compte lorsqu’aucun réplica secondaire n’est actuellement à l’état 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 se compose du réplica principal et des réplicas secondaires qui prennent en charge une forme donnée 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. Une configuration de basculement automatique prend effet uniquement si le réplica secondaire est actuellement synchronisé 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 ensemble de basculement à validation synchrone prend effet uniquement si les réplicas secondaires sont configurés en mode de basculement manuel et qu’au moins un réplica secondaire est actuellement à l’état 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. L’ensemble de basculement entre en ligne de compte lorsqu’aucun réplica secondaire n’est actuellement à l’état 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, la prise d’effet de ce paramètre dépend du nœud 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 de basculement de chaque réplica secondaire dépend du réplica de disponibilité qui est actuellement le réplica principal. Fondamentalement, pour un réplica secondaire donné, le comportement de basculement correspond au scénario le plus défavorable compte tenu du 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 est particulièrement adapté lorsque le nœud WSFC qui héberge le réplica principal se trouve sur le même site que le 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 nécessaires pour un basculement automatique

Le basculement automatique intervient uniquement dans les conditions suivantes :

• Un ensemble de basculement automatique existe. Cet ensemble se compose d’un réplica principal et d’un réplica secondaire (la cible de basculement automatique), tous deux configurés en mode de validation synchrone et pour le basculement AUTOMATIQUE. 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’état de santé des deux réplicas dans une configuration de basculement automatique. Si l'une des deux répliques est défaillante, l'état d'intégrité du groupe de disponibilité est défini sur 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 tombe en panne, 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 pas de cible de basculement automatique. Dans les deux cas, afin de garantir la disponibilité dans l’éventualité peu probable d’une défaillance successive, nous vous recommandons 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’état de santé 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) dispose du 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 conditions de basculement, consultez Stratégie de basculement flexible pour le basculement automatique d’un groupe de disponibilité (SQL Server).

Fonctionnement du basculement automatique

Un basculement automatique déclenche la séquence 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.

   Remarque

   Le temps nécessaire pour appliquer le journal des transactions à une base de données donnée dépend de la vitesse du système, de la charge de travail récente et du volume de journaux dans la file d’attente de récupération.

3. L’ancienne réplique secondaire devient la réplique principale. Ses bases de données deviennent les bases de données primaires. Le nouveau réplica principal annule toutes les transactions non validées (la phase d’annulation de la 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ébut de la récupération après 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ébergeait l’ancien réplica principal redémarre, elle détecte qu’un autre réplica de disponibilité détient désormais 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 met sa base de données à niveau de celle du réplica principal actuel aussi rapidement que possible. Dès que la nouvelle réplique secondaire a resynchronisé ses bases de données, le basculement est de nouveau possible, dans le sens inverse.

Pour configurer un basculement automatique

Une réplique de disponibilité peut être configurée pour prendre en charge le basculement automatique à n’importe quel 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 mode de basculement sur 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é afin de spécifier les types de défaillances pouvant 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 un basculement manuel, la réplique secondaire et la réplique principale actuelle, s’il y en a une, doivent toutes deux être configurées en mode de validation synchrone. Chaque base de données secondaire du réplica de disponibilité doit avoir rejoint le groupe de disponibilité et être synchronisée avec la 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 la réplique de disponibilité hébergée sur l'instance de serveur sur Node02.

3. La cible de basculement (sur Node02) devient la nouvelle réplique principale. Comme il s’agit d’un basculement planifié, l’ancienne réplica principale bascule vers le rôle secondaire pendant le basculement et met immédiatement ses bases de données secondaires en ligne.

Dans cette section :

• Conditions requises pour un basculement manuel

• Fonctionnement du basculement manuel

• Maintien de la disponibilité lors des mises à niveau

Conditions requises pour effectuer 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 la réplique principale.

Pour effectuer manuellement un basculement d’un groupe de disponibilité, vous devez être connecté à la réplica secondaire qui doit devenir la nouvelle réplica principale.

Fonctionnement d'un basculement manuel planifié

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

1. Afin de garantir qu’aucune nouvelle transaction utilisateur ne se produise sur les bases de données primaires d’origine, le cluster WSFC envoie à la réplique principale une demande de mise hors ligne.

2. Si un journal des transactions est en attente dans la file de récupération d’une base de données secondaire, le réplica secondaire termine l’application des journaux de transactions à 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éplique de base de données.

   Remarque

   Le temps de basculement peut être contrôlé en limitant la taille de la file d’attente de récupération. Cependant, cela peut ralentir la réplique principale afin de permettre à la réplique secondaire de suivre le rythme.

3. La réplique secondaire devient la nouvelle réplique principale, et l’ancienne réplique principale devient la nouvelle réplique 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 l’ancienne réplique principale revient en ligne, elle assume le rôle secondaire, et l’ancienne base de données principale devient la base de données secondaire. La nouvelle réplique secondaire resynchronise rapidement les nouvelles bases de données secondaires avec les bases de données primaires correspondantes.

   Remarque

   Dès que la nouvelle réplique secondaire a resynchronisé les bases de données, le basculement est de nouveau possible, mais dans le 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 groupes de disponibilité, connectivité des clients et basculement des applications (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 des 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é

• Pourquoi le basculement forcé est nécessaire après avoir imposé le quorum

• Suivi de la perte de données potentielle

• Gestion de la perte de données potentielle

Fonctionnement du basculement forcé

Le basculement forcé entraîne le transfert du rôle principal vers un réplica cible dont le rôle est à l’état SECONDARY ou RESOLVING. La cible de basculement devient le nouveau réplica principal et met immédiatement ses copies des bases de données à la disposition des 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 suspendues. 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 forçage du basculement démarre une nouvelle branche 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 le risque de perte de données pour une base de données donnée 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 sur plusieurs branches de récupération ; assurez-vous donc d’effectuer une sauvegarde du journal après avoir effectué 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 nécessaire, car l’état réel des valeurs du cluster WSFC a შესაძლოა 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 se déconnecte du cluster WSFC tandis que le réplica secondaire local est SYNCHRONISÉ. 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é, la réplique reste, à tort, dans l’état SYNCHRONIZED.

Si le quorum est perdu puis forcé sur le nœud A, l’état de synchronisation du groupe de disponibilité sur le cluster WSFC doit être correct, le réplica secondaire sur le nœud C étant affiché 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 du cluster sera revenu à celui qui existait au moment où le nœud C a été déconnecté, la réplique secondaire sur le nœud C étant incorrectement affichée 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 retard accusé par les bases de données secondaires locales 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 à la réplique principale.

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 suspendue, une par une, sur chaque réplique secondaire.

Une fois l’ancienne réplique principale disponible, si ses bases de données ne sont pas endommagées, vous pouvez tenter de gérer l’éventuelle perte de données. L’approche disponible pour gérer une éventuelle perte de données dépend du fait que le réplica principal d’origine s’est connecté ou non 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.

La réplique principale d’origine s’est reconnectée

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 son annulation comme première étape de 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 abandonne la branche de récupération d’origine de cette base de données, ce qui entraîne la perte de toutes les transactions qui n’ont jamais été envoyées à l’ancien réplica secondaire ou reçues par celui-ci.

• 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 la base de données primaire actuelle (l’ancienne base de données secondaire) en exportant les données que vous souhaitez récupérer depuis 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.

  Ensuite, sur l’instance de serveur qui héberge le nouveau réplica secondaire, vous pouvez supprimer la base de données secondaire suspendue et créer une base de données secondaire en restaurant cette sauvegarde (et au moins une sauvegarde de journal ultérieure) à 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)
• Cluster 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 de basculement 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 de basculement de 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 du quorum de cluster
• Afficher les paramètres NodeWeight du quorum du cluster
• Forcer un cluster WSFC à démarrer sans quorum