Déterminer pourquoi les modifications apportées à la réplique principale ne sont pas répercutées sur la réplique secondaire dans un groupe de disponibilité Always On

S'applique à :SQL Server

L’application cliente mène à bien une mise à jour sur le réplica principal, mais l’exécution d’une requête sur le réplica secondaire montre que le changement n’a pas été répercuté. Ce scénario suppose que votre disponibilité présente un bon état de synchronisation. La plupart du temps, ce problème se résout tout seul en quelques minutes.

Si les modifications ne sont toujours pas répercutées sur la réplique secondaire après quelques minutes, il se peut qu’il y ait un goulot d’étranglement dans le flux de travail de synchronisation. L’emplacement du goulot d’étranglement dépend du fait que le réplica secondaire soit configuré en validation synchrone ou en validation asynchrone.

Validation synchrone

Chaque mise à jour effectuée sur le réplica principal a déjà été synchronisée avec le réplica secondaire, ou les enregistrements de journal ont déjà été vidés à des fins de renforcement sur le réplica secondaire. Le goulot d’étranglement devrait donc se situer dans le processus de réexécution qui a lieu une fois le journal vidé sur la réplique secondaire.

Toutefois, une fois que la réapplication a rattrapé son retard, toutes les charges de travail en lecture sur le réplica secondaire s’exécutent en isolation d’instantané :

  • Transactions de longue durée sur la réplique principale

  • Rétablir sur la réplique secondaire

Validation asynchrone de la transaction

Étant donné qu’une validation asynchrone considère une transaction comme validée dès qu’elle est écrite sur le disque local, le goulot d’étranglement peut se situer à n’importe quel endroit au-delà de ce point :

  • Transactions longues sur la réplique principale

  • Latence ou débit du réseau

  • Validation du journal des transactions sur la réplique secondaire

  • Rétablir sur la réplique secondaire

Les sections suivantes décrivent les causes courantes pour lesquelles les modifications apportées au réplica principal ne sont pas répercutées sur le réplica secondaire pour les requêtes en lecture seule.

Transactions actives de longue durée

Une transaction de longue durée sur le réplica principal empêche que les mises à jour soient lues sur le réplica secondaire.

Explication

Toutes les opérations de lecture sur le réplica secondaire sont des requêtes exécutées au niveau d’isolation des captures instantanées. Dans l’isolement de capture instantanée, les clients en lecture seule voient la base de données de disponibilité sur le réplica secondaire au point de début de la transaction active la plus ancienne dans le journal restauré par progression. Si une transaction n’est pas validée depuis des heures, la transaction ouverte empêche toutes les requêtes en lecture seule de voir les mises à jour récentes.

Diagnostic et résolution

Sur le réplica principal, utilisez DBCC OPENTRAN (Transact-SQL) pour afficher les transactions actives les plus anciennes et voir si elles peuvent être restaurées. Une fois les transactions actives les plus anciennes restaurées et synchronisées avec le réplica secondaire, les charges de travail de lecture sur le réplica secondaire peuvent voir les mises à jour dans la base de données de disponibilité jusqu’au début de la transaction active la plus ancienne à ce moment-là.

Une latence réseau élevée ou un débit réseau faible provoque l’accumulation des journaux sur le réplica principal

Une latence réseau élevée ou un débit faible peut empêcher l’envoi des journaux au réplica secondaire suffisamment rapidement.

Explication

La réplique principale applique un contrôle de flux à l’envoi du journal lorsqu’elle dépasse le nombre maximal autorisé de messages envoyés à la réplique secondaire et non encore accusés de réception. Tant qu’une partie de ces messages ne fait pas l’objet d’un accusé de réception, aucun bloc de journal supplémentaire ne peut être envoyé au réplica secondaire. Cette situation peut avoir des conséquences plus graves, notamment la perte de données, compromettant ainsi votre objectif de point de récupération (RPO).

Diagnostic et résolution

Une valeur DMV log_send_queue_size élevée peut indiquer que les journaux sont retenus au niveau du réplica principal. Divisez cette valeur par log_send_rate pour obtenir une estimation approximative de l’heure à laquelle les données seront à niveau sur le réplica secondaire.

En outre, il est utile de vérifier les deux objets de performance SQL Server : réplica de disponibilité > Temps de contrôle de flux (ms/s) et SQL Server : réplica de disponibilité > Contrôle de flux/s. La multiplication de ces deux valeurs vous indique, pendant la dernière seconde, combien de temps a été passé à attendre la fin du contrôle de flux. Plus le temps d’attente du contrôle de flux est long, plus le taux d’envoi est faible.

Voici une liste des métriques utiles pour diagnostiquer les problèmes liés à la latence et au débit du réseau. Vous pouvez utiliser d’autres outils Windows comme ping.exe pour évaluer l’utilisation du réseau.

  • DMV log_send_queue_size

  • DMV log_send_rate

  • Compteur de performances SQL Server:Database > Log Bytes Flushed/sec

  • Compteur de performances SQL Server:Database Mirroring > Send/Receive Ack Time

  • Compteur de performances SQL Server:Availability Replica > Bytes Sent to Replica/sec

  • Compteur de performances SQL Server:Availability Replica > Bytes Sent to Transport/sec

  • Compteur de performances SQL Server:Availability Replica > Flow Control Time (ms/sec)

  • Compteur de performances SQL Server:Availability Replica > Flow Control/sec

  • Compteur de performances SQL Server:Availability Replica > Resent Messages/sec

Pour remédier à ce problème, essayez d’augmenter votre bande passante réseau ou de supprimer/réduire le trafic réseau inutile.

Une autre charge de travail de création de rapports empêche l’exécution du thread de restauration par progression

Le thread de restauration sur la réplique secondaire est empêché d’effectuer des modifications de langage de définition de données (DDL) par une requête en lecture seule de longue durée. Le thread de réexécution doit être débloqué avant de pouvoir rendre d’autres mises à jour disponibles pour les charges de travail de lecture.

Explication

Sur le réplica secondaire, les requêtes en lecture seule acquièrent les verrous de stabilité de schéma (Sch-S). Ces verrous Sch-S peuvent empêcher le thread de réexécution d’acquérir les verrous de modification de schéma (Sch-M) pour effectuer des modifications DDL. Un thread de réexécution bloqué ne peut pas appliquer les enregistrements de journal tant qu’il n’est pas débloqué.

Diagnostic et résolution

Quand le thread de restauration est bloqué, un événement étendu appelé sqlserver.lock_redo_blocked est généré. Vous pouvez également interroger la DMV sys.dm_exec_requests sur le réplica secondaire pour identifier la session qui bloque le thread REDO, puis prendre des mesures correctives. La requête suivante renvoie l’ID de session de la charge de travail de génération de rapports qui bloque le thread de restauration.

select session_id, command, blocking_session_id, wait_time, wait_type, wait_resource   
from sys.dm_exec_requests where command = 'DB STARTUP'

Vous pouvez soit laisser la charge de travail de création de rapports se terminer, ce qui déclenche le déblocage du thread de restauration par progression, soit débloquer immédiatement le thread de restauration par progression en exécutant la commande KILL (Transact-SQL) sur l’ID de session à l’origine du blocage.

Le thread de reprise prend du retard en raison d’une contention de ressources

Une importante charge de travail de génération de rapports sur le réplica secondaire a ralenti les performances du réplica secondaire, et le thread de réexécution a pris du retard.

Explication

Lors de l’application des enregistrements du journal sur la réplique secondaire, le thread de réexécution lit les enregistrements du journal depuis le disque du journal, puis, pour chaque enregistrement du journal, il accède aux pages de données afin d’appliquer cet enregistrement. L’accès à la page peut être lié aux E/S (accès au disque physique) si la page ne figure pas déjà dans le pool de mémoires tampons. Si la charge de génération de rapports est limitée par les E/S, elle entre en concurrence avec le thread de réapplication pour les ressources d’E/S et peut ralentir ce thread. Cette situation empêche non seulement les autres charges de travail de reporting d’accéder à des données actualisées, mais elle affecte aussi le RTO.

Diagnostic et résolution

Vous pouvez utiliser la requête DMV suivante pour voir dans quelle mesure le thread de restauration est en retard, en mesurant la différence de l’écart entre last_redone_lsn et last_received_lsn.

select recovery_lsn, truncation_lsn, last_hardened_lsn, last_received_lsn,   
   last_redone_lsn, last_redone_time  
from sys.dm_hadr_database_replica_states

Si le thread de réexécution accuse effectivement un retard, vous devez rechercher la cause profonde de la dégradation des performances sur la réplique secondaire. En cas de contention des E/S avec la charge de travail de génération de rapports, vous pouvez utiliser Resource Governor pour contrôler le temps processeur utilisé par cette charge de travail afin de limiter indirectement, dans une certaine mesure, les ressources d’E/S consommées. Par exemple, si votre charge de travail de création de rapports utilise 10 % de l’UC et que la charge de travail est liée aux E/S, vous pouvez utiliser Resource Governor pour limiter l’utilisation des ressources de l’UC à 5 % afin de restreindre la charge de travail de lecture et réduire l’impact sur les E/S.

Contenu connexe

  • Last updated on