Quelle est la raison pour laquelle une réplique secondaire AlwaysOn AG a une taille de file d'attente de rétablissement élevée et un temps de récupération estimé avec un bon taux de rétablissement?

Question

SQL14 est le serveur principal, SQL16 est le réplica secondaire et ils sont configurés à l'aide du mode de disponibilité de validation synchrone:

Hier, il est apparu que les données avaient cessé de se synchroniser du primaire vers la réplique. Ce matin, nous avons suspendu la base de données de disponibilité, puis l'avons reprise. Cela a semblé relancer la synchronisation alors que je vois de nouvelles données arriver, mais la taille de la file d'attente de rétablissement et le temps de récupération estimé dans le tableau de bord sont toujours importants et continuent de croître.

Quelles choses puis-je vérifier/faire pour résoudre ce problème?

Informations supplémentaires: Version du serveur: SQL Server 2016 Enterprise - SP1 (à la fois principal et secondaire)

De plus, certains travaux de réorganisation/reconstruction d'index de longue durée échouent sur le serveur principal plus tôt dans la matinée. (C'était il y a environ 4 heures, mais cela pourrait-il encore être un contributeur potentiel à ce problème maintenant?)

J'ai remarqué les journaux de serveur suivants sur le secondaire (du plus ancien au plus récent):

Vous ne savez pas s'il y a des indices là-dedans?

DBCC OPENTRAN sur le secondaire renvoie ce qui suit:

Session d'événements étendue pour suivre les attentes sur le secondaire:

Answer 1

Donc, un certain nombre de choses ici ... (par exemple, ce sera une réponse longue et peut passer par un certain nombre d'itérations):

D'abord et avant tout cet AG a-t-il connu un basculement? Sinon, la vérification des ERRORLOG sur le nœud principal est l'endroit où je vous suggère de démarrer votre processus de dépannage; si un basculement s'est produit, vérifiez les ERRORLOG sur le noeud officiellement appelé primaire pour voir ce qui s'est passé. Vous pouvez utiliser l'interface utilisateur maladroite dans SSMS ou vous pouvez utiliser la procédure étendue non documentée xp_readerrorlog , ce qui est ma recommandation car il est juste plus rapide de filtrer le bruit de cette façon. Par exemple, je suggère de commencer à chercher des références au nom de l'AG comme les suivantes et de creuser à partir de là:

xp_readerrorlog 0, 1, N'>>YOUR AG NAME HERE<<', NULL, '2019-11-18 12:00:00.000', '2019-11-19 15:00:00.000', NULL, NULL

Vérifiez le lien ci-dessus pour la syntaxe entourant la commande.

En fonction de ce que vous trouvez, développez la recherche en vérifiant vos journaux d'événements Windows (eventvwr.msc), journaux de cluster (cluadmin.msc), journaux d'application, etc. en utilisant les temps d'erreur comme point de référence si nécessaire. Je soupçonne fortement que ces journaux identifieront ce qui a causé l'arrêt de la synchronisation, que ce soit un problème lié au cluster, un hoquet dû à la maintenance, etc. Sur cette base, je suggère de poster une nouvelle question si vous avez du mal à interpréter les résultats. .

Deuxièmement, l'exécution de la maintenance d'index dans un AG entraînera des retards de synchronisation AG . Il est impossible de le contourner, quelle que soit la version de SQL Server (SQL 2019 incluse), bien que les nouvelles versions aient tendance à récupérer plus rapidement. Si vous pensez que vous devez exécuter la maintenance d'index et que vous avez la possibilité de mettre l'application hors ligne, je vous suggère d'exécuter la maintenance d'index hors ligne. Exécutez-le en tant que REBUILDs hors ligne avec MAXDOP défini, car les opérations de reconstruction d'index hors ligne ne provoquent pas de retards aussi graves dans votre AG. Évidemment, cette approche entraînera une panne, donc ce n'est pas quelque chose à faire à la légère. Je prends en charge un environnement où nous faisons cela car négliger la maintenance d'index provoque une croissance inutile (et dans un système multi TB qui provoque d'autres problèmes)

Pour le dire clairement, une idée fausse courante dans la communauté SQL Server est que la maintenance d'index est super critique pour les performances d'une base de données. Ce n'est généralement pas le cas car la fragmentation de l'index n'a que impact minimal sur le comportement du plan d'exécution . Ce n'est que lorsque l'espace blanc moyen par page approche des niveaux extrêmes, la fragmentation commence-t-elle à avoir de l'importance . Honnêtement, dans la plupart des cas, la maintenance des index est fondamentalement une opération de mise à jour des statistiques très coûteuse, ce qui signifie être au-dessus des mises à jour des statistiques qui ne provoquent généralement pas de blocage et aussi ne sauvegardez pas les AG.

Enfin , si vous voulez voir à quelle distance se trouvent les secondaires et obtenir une estimation du temps qu'il faudra pour les rattraper, donnez à cette requête un essayez qui est une variante de ce code de Jonathan Kehayias :

SELECT ar.replica_server_name, 
       adc.database_name, 
       ag.name AS ag_name, 
       drs.is_local, 
       drs.synchronization_state_desc, 
       drs.synchronization_health_desc, 
       drs.last_redone_time, 
       drs.redo_queue_size, 
       drs.redo_rate, 
       (drs.redo_queue_size / drs.redo_rate) / 60.0 AS est_redo_completion_time_min,
       drs.last_commit_lsn, 
       drs.last_commit_time
FROM sys.dm_hadr_database_replica_states AS drs
INNER JOIN sys.availability_databases_cluster AS adc 
       ON drs.group_id = adc.group_id AND 
       drs.group_database_id = adc.group_database_id
INNER JOIN sys.availability_groups AS ag
       ON ag.group_id = drs.group_id
INNER JOIN sys.availability_replicas AS ar 
       ON drs.group_id = ar.group_id AND 
       drs.replica_id = ar.replica_id
ORDER BY 
       ag.name, 
       ar.replica_server_name, 
       adc.database_name;