Partager via

Différences entre les modes de disponibilité pour un groupe de disponibilité Always On

S'applique à :SQL Server

Dans les groupes de disponibilité Always On, le mode de disponibilité est une propriété de la réplique qui détermine si une réplique de disponibilité donnée peut fonctionner en mode de validation synchrone. Pour chaque réplica de disponibilité, vous devez configurer le mode de disponibilité pour le mode en validation synchrone, le mode en validation asynchrone ou le mode en configuration uniquement.

Si le réplica principal est configuré pour le mode de validation asynchrone, il n’attend pas qu’un réplica secondaire écrive des enregistrements de journal des transactions entrants sur le disque (pour renforcer le journal).

Si un réplica secondaire donné est configuré en mode en validation asynchrone, le réplica principal n’attend pas que ce réplica secondaire renforce le journal. Si le réplica principal et un réplica secondaire donné sont configurés pour le mode de validation synchrone, le réplica principal attend que le réplica secondaire confirme qu’il a renforcé le journal (sauf si le réplica secondaire n’envoie pas de commande ping au réplica principal pendant la période d’expiration de sessiondu réplica principal).

Remarque

Si une réplique secondaire de validation synchrone dépasse le délai d’expiration de session de la réplique principale (la valeur par défaut est de 10 secondes), la réplique principale marque temporairement l’état de synchronisation de chaque base de données sur cette réplique secondaire comme NOT SYNCHRONIZING et l’état de la réplique comme NOT_HEALTHY. Lorsque le réplica secondaire se reconnecte au réplica principal, ils reprennent le mode de validation synchrone.

Modes de disponibilité pris en charge

Les groupes de disponibilité Always On prennent en charge trois modes de disponibilité :

  • Mode en validation asynchrone
  • Mode de commit synchrone
  • Mode configuration uniquement

Le Mode en validation asynchrone est une solution de récupération d’urgence qui fonctionne correctement quand les réplicas de disponibilité sont séparés par des distances considérables. Si chaque réplica secondaire s’exécute en mode en validation asynchrone, le réplica principal n’attend pas que les réplicas secondaires renforcent le journal. En revanche, immédiatement après l’écriture d’un enregistrement de journal dans le fichier journal local, le réplica principal envoie une confirmation de transaction au client. Le réplica principal s'exécute avec une latence de transaction minimale par rapport à un réplica secondaire configuré pour le mode avec validation asynchrone.

Si le serveur principal actuel est configuré pour le mode de disponibilité en validation asynchrone, il valide les transactions de façon asynchrone pour tous les réplicas secondaires, quels que soient leurs paramètres de mode de disponibilité.

Pour plus d’informations, consultez le mode de disponibilité en engagement asynchrone, plus loin dans cet article.

Lemode avec validation synchrone privilégie la haute disponibilité par rapport aux performances, mais au prix d’une latence accrue des transactions. Sous le mode en validation synchrone, les transactions attendent que le réplica secondaire ait renforcé le journal sur le disque avant d’envoyer la confirmation de transaction au client. Lorsque la synchronisation des données démarre sur une base de données secondaire, la réplique secondaire commence à appliquer les enregistrements de journal entrants depuis la base de données primaire correspondante. Dès que chaque enregistrement de journal a été consolidé, la base de données secondaire entre à l'état SYNCHRONIZED. Ensuite, chaque nouvelle transaction est renforcée par le réplica secondaire avant que l’enregistrement du journal soit écrit dans le journal local. Lorsque toutes les bases de données secondaires d’un réplica secondaire donné sont synchronisées, le mode en validation synchrone prend en charge le basculement manuel et, éventuellement, le basculement automatique.

Pour plus d’informations, consultez le mode de disponibilité Synchronous-Commit, plus loin dans cet article.

Le Mode de configuration uniquement s’applique aux groupes de disponibilité qui ne se trouvent pas sur un cluster de basculement Windows Server. Un réplica en mode configuration uniquement ne contient pas de données utilisateur. En mode configuration uniquement, la base de données réplica master stocke les métadonnées de configuration du groupe de disponibilité. Pour plus d’informations, consultez Haute disponibilité et protection des données pour les configurations des groupes de disponibilité.

L’illustration suivante montre un groupe de disponibilité avec cinq réplicas de disponibilité. Le réplica principal et un réplica secondaire sont configurés pour le mode en validation synchrone et le basculement automatique. Un autre réplica secondaire est configuré pour le mode en validation synchrone pour un basculement manuel planifié uniquement. Deux réplicas secondaires sont configurés pour le mode avec validation asynchrone qui prend en charge uniquement le basculement manuel forcé (généralement appelé basculement forcé).

Diagramme des modes de disponibilité et de basculement des répliques.

Le comportement de synchronisation et de basculement entre deux réplicas de disponibilité dépend du mode de disponibilité des deux réplicas. Par exemple, pour que la validation synchrone se produise, le réplica principal et le réplica secondaire doivent être configurés pour la validation synchrone. De même pour un basculement automatique, les deux réplicas doivent être configurés pour le basculement automatique. Par conséquent, le comportement du scénario de déploiement illustré précédemment peut être résumé dans le tableau ci-dessous, qui explore le comportement avec chaque réplique principale potentielle.

Réplique principale actuelle Cibles de basculement automatique Comportement du mode de validation synchrone avec Comportement du mode de validation asynchrone avec Basculement automatique possible
01 02 02 et 03 04 Oui
02 01 01 et 03 04 Oui
03 01 et 02 04 Non
04 01, 02 et 03 Non

En général, le nœud 04 (réplica en validation asynchrone), est déployé sur un site de récupération d’urgence. Le fait que les nœuds 01, 02 et 03 demeurent en mode de validation asynchrone après avoir basculé vers le nœud 04 aide à prévenir une dégradation potentielle des performances dans votre groupe de disponibilité en raison d'une latence réseau élevée entre les deux sites.

Mode de disponibilité en validation asynchrone

En mode avec validation asynchrone, le réplica secondaire n’est jamais synchronisé avec le réplica principal. Bien qu'une base de données secondaire donnée puisse rattraper la base de données principale correspondante, n'importe quelle base de données secondaire peut être en décalage à tout moment. Le mode de validation asynchrone peut être utile dans un scénario de récupération d’urgence dans lequel le réplica principal et le réplica secondaire sont séparés par une distance importante et où vous ne souhaitez pas que de petites erreurs affectent le réplica principal ou dans les situations où les performances sont plus importantes que la protection des données synchronisées. En outre, étant donné que le réplica principal n’attend pas les confirmations du réplica secondaire, les problèmes survenant sur ce réplica secondaire n’affectent jamais le réplica principal.

Un réplica secondaire en validation asynchrone tente de suivre les enregistrements de journal reçus du réplica principal. Cependant, en mode avec validation asynchrone, les bases de données secondaires ne sont jamais synchronisées et peuvent rester derrière les bases de données principales correspondantes. Généralement, l'intervalle entre une base de données secondaire avec validation asynchrone et la base de données primaire correspondante est faible. Mais l'intervalle peut devenir substantiel si le serveur qui héberge le réplica secondaire est surchargé ou si le réseau est lent.

La seule forme de basculement prise en charge par le mode en validation asynchrone est le basculement forcé (avec perte de données possible). Un forçage du basculement constitue le dernier recours adapté uniquement aux situations dans lesquelles le réplica principal reste indisponible pendant une période prolongée et la disponibilité immédiate des bases de données primaires est plus importante que le risque de perte de données. La cible de basculement doit être une réplique dont le rôle est soit dans l’état SECONDARY, soit dans l’état RESOLVING. La cible de basculement passe au rôle principal et ses copies de bases de données deviennent la base de données primaire. Toutes les bases de données secondaires restantes, avec les bases de données primaires précédentes, une fois qu'elles sont disponibles, sont interrompues jusqu'à ce que vous les repreniez manuellement et individuellement. En mode de validation asynchrone, tous les journaux des transactions que le réplica principal d’origine n’avait pas envoyés à l’ancien réplica secondaire sont perdus. Cela signifie que les transactions validées récemment peuvent manquer dans certaines ou toutes les nouvelles bases de données principales. Pour découvrir plus d’informations sur le basculement forcé et sur les meilleures pratiques pour l’utiliser, consultez Basculement et modes de basculement (groupes de disponibilité Always On).

Mode de disponibilité en validation synchrone

Sous le mode de disponibilité de validation synchrone, après avoir été joint à un groupe de disponibilité, une base de données secondaire rattrape la base de données primaire correspondante et entre dans l’état SYNCHRONIZED. La base de données secondaire reste SYNCHRONIZED tant que la synchronisation des données se poursuit. Cela garantit que chaque transaction validée sur une base de données primaire donnée est validée sur la base de données secondaire correspondante. Lorsque chaque base de données secondaire sur un réplica secondaire donné est synchronisée, l’état d’intégrité de synchronisation du réplica secondaire dans son ensemble est HEALTHY.

Dans cette section :

Facteurs qui interrompent la synchronisation des données

Une fois que toutes ses bases de données sont synchronisées, un réplica secondaire entre dans l’état HEALTHY . Le réplica secondaire synchronisé reste sain, sauf si l’une des opérations suivantes se produit :

  • Un retard de réseau ou d’ordinateur, ou un autre problème, entraîne l’expiration du délai d’attente de la session entre le réplica secondaire et le réplica principal.

    Remarque

    Pour plus d’informations sur la propriété de temps de session des réplicas de disponibilité, consultez Qu’est-ce qu’un groupe de disponibilité Always On ?

  • Vous suspendez une base de données secondaire sur le réplica secondaire. Le réplica secondaire cesse d’être synchronisé et son état synchronization-health est marqué comme NOT_HEALTHY. Le réplica secondaire ne peut pas redevenir sain tant que la base de données secondaire suspendue n’est pas reprise et resynchronisée ou bien n’est pas supprimée du groupe de disponibilité.

  • Vous ajoutez une base de données primaire au groupe de disponibilité. Les réplicas secondaires précédemment synchronisés entrent dans l'état de santé de NOT_HEALTHY synchronisation. Cet état indique qu’au moins une base de données est dans l’état de NOT SYNCHRONIZING synchronisation. Un réplica secondaire donné ne peut pas être HEALTHY à nouveau tant qu’une base de données secondaire correspondante n’a pas été préparée sur le réplica, qu’elle a été jointe au groupe de disponibilité et qu’elle est synchronisée avec la nouvelle base de données primaire.

  • Vous passez le réplica principal ou le réplica secondaire au mode de disponibilité en validation asynchrone. Après être passé en mode validation asynchrone, le réplica secondaire reste dans l’état de santé de HEALTHY synchronisation tant que la synchronisation des données se poursuit. Toutefois, si seul le réplica principal est passé en mode de validation asynchrone, le réplica secondaire de validation synchrone entrera dans l’état PARTIALLY_HEALTHY d’intégrité de synchronisation. Cet état indique qu’au moins une base de données est dans l’état SYNCHRONIZING de synchronisation, mais aucune des bases de données n’est dans l’état NOT SYNCHRONIZING .

  • Vous passez un réplica principal au mode de disponibilité en validation synchrone. Cela entraîne la marque du réplica secondaire comme étant dans l’état d’intégrité de PARTIALLY_HEALTHY synchronisation jusqu’à ce que toutes ses bases de données soient dans l’état SYNCHRONIZED de synchronisation.

Conseil

Pour afficher l’intégrité de synchronisation d’un groupe de disponibilité, d’un réplica de disponibilité ou d’une base de données de disponibilité, interrogez la colonne synchronization_health ou synchronization_health_desc de sys.dm_hadr_availability_group_states, sys.dm_hadr_availability_replica_states ou sys.dm_hadr_database_replica_states, respectivement.

Fonctionnement de la synchronisation sur une réplique secondaire

Dans le mode en validation synchrone, une fois qu’un réplica secondaire rejoint le groupe de disponibilité et établit une session avec le réplica principal :

  1. Le réplica secondaire écrit les enregistrements de journal entrants sur le disque (renforce le journal).
  2. Le réplica secondaire envoie un message de confirmation au réplica principal.

Une fois que le journal durci sur la base de données secondaire a atteint la fin du journal sur la base de données primaire, l’état de la base de données secondaire est défini SYNCHRONIZED sur.

Le temps nécessaire pour la synchronisation dépend de la distance entre la base de données secondaire et la base de données primaire au début de la session. Ce delta est mesuré par le nombre d’enregistrements de journal initialement reçus du réplica principal, la charge de travail sur la base de données primaire et la vitesse de l’hôte d’instance du réplica secondaire.

Processus de transaction

En mode de validation synchrone, les transactions sont validées sur les deux réplicas dans cet ordre :

  1. Le réplica principal reçoit une transaction d’un client.

  2. Le réplique principal écrit l’enregistrement dans le journal des transactions et envoie simultanément l’enregistrement du journal aux répliques secondaires.

    Une fois qu’un enregistrement de journal est écrit dans le journal des transactions de la base de données primaire, la transaction peut être annulée uniquement s’il existe un basculement vers une base de données secondaire qui n’a pas reçu le journal.

  3. Le réplica principal attend la confirmation du ou des réplicas secondaires en validation synchrone.

  4. Le réplica secondaire renforce le journal et retourne une confirmation au réplica principal.

  5. La réplique principale termine le traitement de validation et envoie un message de confirmation au client.

Délai d’expiration de la validation synchrone

Si un réplica en validation synchrone expire sans confirmer son durcissement du journal, les actions suivantes se produisent dans le groupe de disponibilité :

  1. Le réplica principal marque le réplica secondaire comme ayant échoué.
  2. L’état du réplica secondaire passe à DISCONNECTED.
  3. Le principal cesse d’attendre la confirmation.
  4. Le groupe de disponibilité marque l’état de synchronisation comme NOT SYNCHRONIZING et l’état du réplica comme NOT_HEALTHY.

Ce comportement veille à ce qu’un réplica secondaire en validation synchrone n’empêche pas le renforcement du journal sur le réplica principal.

Lorsque la réplique secondaire est de nouveau en ligne :

  1. L’état du réplica secondaire passe à CONNECTED.
  2. Le réplica secondaire traite la file d’attente d’envoi du journal du réplica principal.
  3. L'état de synchronisation passe à SYNCHRONIZING, et l'intégrité du réplica à PARTIALLY_HEALTHY.

Une fois la file d’attente d’envoi du journal traitée, l’état de synchronisation devient SYNCHRONIZED, et l’état de santé du réplica devient HEALTHY.

Le mode avec validation synchrone protège vos données en exigeant que celles-ci soient synchronisées entre deux emplacements, quitte à augmenter un peu la latence de la transaction.

Mode en validation synchrone et basculement manuel uniquement

Lorsque ces réplicas sont connectés et la base de données synchronisée, le basculement manuel est pris en charge. Si le réplica secondaire s’arrête, le réplica principal n’est pas affecté. Le réplica principal fonctionne à découvert s’il n’existe aucun SYNCHRONIZED réplica (c’est-à-dire, sans envoyer de données à un réplica secondaire). Si le réplica principal est perdu, les réplicas secondaires entrent dans l’état RESOLVING , mais le propriétaire de la base de données peut forcer un basculement vers le réplica secondaire (avec perte de données possible). Pour découvrir plus d’informations, consultez Basculement et modes de basculement (groupes de disponibilité Always On).

Mode en validation synchrone et basculement automatique

Le basculement automatique offre une haute disponibilité et assure que la base de données redevient rapidement disponible après la perte du réplica principal. Pour configurer le basculement automatique d’un groupe de disponibilité, vous devez définir le réplica principal actuel et au moins un réplica secondaire en mode de validation synchrone avec basculement automatique. SQL Server 2019 (15.x) augmente le nombre maximal de réplicas synchrones à 5, contre 3 dans SQL Server 2017 (14.x). Vous pouvez configurer ce groupe de cinq réplicas de manière à y instaurer le basculement automatique. Il existe une réplique principale, ainsi que quatre répliques secondaires synchrones.

En outre, pour qu'un basculement automatique soit possible à tout moment, ce réplica secondaire doit être synchronisé avec le réplica principal (autrement dit, toutes les bases de données secondaires doivent être synchronisées) et le cluster de basculement Windows Server (WSFC) doit avoir le quorum. Si le réplica principal devient indisponible dans ces conditions, un basculement automatique se produit. Le réplica secondaire bascule vers le rôle de principal et propose sa base de données comme base de données primaire. Pour plus d'informations, consultez la section « Basculement automatique » de l'article Basculement et modes de basculement (groupes de disponibilité Always On).

Remarque

Pour plus d’informations sur le quorum WSFC et Groupes de disponibilité Always On, consultez Modes de quorum WSFC et configuration de vote (SQL Server).

Latence des données sur la réplique secondaire

L’implémentation de l’accès en lecture seule aux réplicas secondaires est utile si vos charges de travail en lecture seule peuvent tolérer une certaine latence des données. Dans les situations où la latence des données est inacceptable, envisagez d’exécuter les charges de travail en lecture seule sur le réplica principal.

Le réplica principal envoie les enregistrements du journal des modifications sur la base de données primaire aux réplicas secondaires. Sur chaque base de données secondaire, un thread de phase de restauration par progression dédié applique les enregistrements de journal. Sur une base de données secondaire d’accès en lecture, une modification de données donnée n’apparaît pas dans les résultats de la requête tant que l’enregistrement du journal qui contient la modification n’a pas été appliqué à la base de données secondaire et que la transaction a été validée sur la base de données primaire.

Cela signifie qu’il y a une certaine latence, généralement seulement quelques secondes, entre les répliques principales et secondaires. Dans des cas exceptionnels, toutefois, par exemple si des problèmes réseau réduisent le débit, la latence peut devenir importante. La latence augmente en cas de survenue de goulots d'étranglement d'E/S et lorsque le déplacement des données est suspendu. Pour surveiller le déplacement des données suspendues, vous pouvez utiliser le tableau de bord Always On Availability Group (SQL Server Management Studio) ou la vue de gestion dynamique sys.dm_hadr_database_replica_states.

Pour réduire la latence dans SQL Server 2025 (17.x) et les versions ultérieures, vous pouvez réduire le temps (en millisecondes) que le réplica principal prend pour valider les transactions sur le réplica secondaire. Pour plus d’informations, consultez Configuration du serveur : temps de validation du groupe de disponibilité (ms).

Pour modifier le mode de disponibilité et de basculement

Pour ajuster les votes de quorum

Pour effectuer un basculement manuel

Pour afficher les états de groupe de disponibilité, de réplica de disponibilité et de base de données

Contenu connexe

  • Last updated on