Les bases de données du groupe de disponibilité distribué SQL Server ne se synchronisent pas après un redémarrage du serveur
Nous nous apprêtons à effectuer ne mise à niveau importante sur nos serveurs SQL et constatons un comportement inhabituel avec les groupes de disponibilité distribuée que j'essaie de résoudre avant d'aller de l'avant.
Le mois dernier, j'ai mis à niveau un serveur secondaire distant de SQL Server 2016 vers SQL Server 2017. Ce serveur fait partie de plusieurs groupes de disponibilité distribués (DAG) et d'un autre groupe de disponibilité (AG) . Lorsque nous avons mis à niveau ce serveur, nous ne savions pas qu'il entrerait dans un état illisible , donc au cours du mois dernier, nous nous sommes uniquement appuyés sur le serveur principal.
Dans le cadre de la prochaine mise à niveau, j'ai appliqué le correctif CU 4 au serveur et l'ai redémarré. Lorsque le serveur est revenu en ligne, le secondaire juste corrigé a montré que tous les DAG/AG se synchronisaient sans aucun problème.
Cependant, le primaire montrait une histoire très différente. Il rapportait que
- l'AG séparé se synchronisait sans aucun problème
- mais les DAG étaient dans un état non synchronisé/non sain
Après avoir paniqué initialement, j'ai tenté les choses suivantes pour que les choses se synchronisent à nouveau dans les DAG:
- Depuis le primaire, j'ai arrêté et repris le mouvement des données. Cela n'a pas commencé à synchroniser les données.
- Sur le secondaire (celui que je viens de patcher), j'ai couru
ALTER DATABASE [<database] SET HADR RESUME;- qui s'exécutent sans erreur, mais n'ont repris aucune synchronisation
Ma dernière tentative de synchronisation des données a été de me connecter au secondaire et de redémarrer manuellement le service SQL Server. Le redémarrage manuel du service semble un peu extrême, car je m'attendrais à ce que le serveur en cours de redémarrage soit suffisant.
Quelqu'un a-t-il rencontré ce problème lorsqu'un DAG ne démarre pas la synchronisation avec un secondaire après un redémarrage? Si oui, comment a-t-il été résolu?
J'ai vérifié à la fois le journal des erreurs de SQL Server et l'observateur d'événements sur le serveur secondaire, il n'y avait rien d'extraordinaire que je pouvais voir.
Veuillez noter que ce n'est pas une réponse définitive mais c'est la meilleure réponse après avoir discuté avec Taryn .
Cependant, le primaire montrait une histoire très différente. Il signalait que l'AG séparé se synchronisait sans aucun problème, mais les DAG étaient dans un état de non synchronisation/non sain.
Si les bases de données individuelles et les AG sous-jacents à l'AG distribuée disent qu'ils sont sains et synchronisés, il y a de fortes chances que ce soit juste un hoquet dans les tableaux de bord DMV et/ou SSMS. Puisqu'il n'y avait rien dans le journal des erreurs pour suggérer que la réplique ne se connectait pas ou était dans un état déconnecté.
Malheureusement, puisque le problème est résolu, il est difficile de dire exactement ce que c'était ... mais à l'avenir si cela se produit pour quelqu'un:
- Vérifiez sys.dm_hadr_database_replica_states sur tous les clusters à la recherche de tout ce qui n'est pas sain. Si tout montre bien, il est possible que le DMV n'ait pas encore été mis à jour
- S'il n'est pas sain, vérifiez le journal d'erreurs/DMV pour les problèmes de connectivité (comme ne pas pouvoir vous connecter au transitaire/principal global)
- Dan's La réponse mentionne des problèmes qui pourraient survenir lors du démarrage de la base de données - bien que dans ce cas, l'instance ne peut pas être lue, ce qui n'était probablement pas un problème mais pourrait l'être dans votre cas
- Si la base de données est lisible, test de fumée avec une table/insert factice ou ...
- Session d'événement étendue utilisant les éléments du canal DEBUG
sqlserver.hadr_dump_log_blockousqlserver.hadr_apply_log_blockpour voir si le secondaire reçoit/applique réellement les blocs de journaux ou ... - Objet Perfmon
SQLServer:Database Replica\Log Bytes Received/sec
Si vous recevez des données sur ce secondaire mais que l'agrégat distribué montre toujours pas de synchronisation ou n'est pas sain, je laisserais aller un peu pour voir si les valeurs DMV changent, car il reçoit et traite évidemment les blocs de journal.
Si, cependant, ce n'est pas le cas, nous devrons enquêter davantage sur ce qui est hors de portée de la réponse.
Je préfère tout cela avec la mise en garde que je n'ai pas de DAG en production. Fondamentalement, ces conseils devraient s'appliquer entre les AG et les DAG.
La synchronisation a-t-elle repris après le redémarrage du service? Si c'est le cas, ma meilleure estimation de la cause serait de bloquer le SPID de rétablissement. S'il ne se synchronise toujours pas même après le redémarrage, voici ce que je vérifierais en premier:
Blocage de AG redo SPID
Généralement, il ne se produira que sur un secondaire lisible. Pour vérifier, exécutez ce qui suit:
select session_id, blocking_session_id, db_name(database_id), wait_type
from sys.dm_exec_requests
where command = 'DB STARTUP'
Si des SPID bloquants apparaissent, vous devrez les tuer avant que le secondaire puisse reprendre (le DB STARTUP SPID est ce qui gère les opérations de rétablissement). Je suggère de revoir le SPID de blocage au préalable pour essayer de déterminer la cause (généralement un rapport long).
Si vous souhaitez plus d'informations à ce sujet, il y a un excellent article (y compris la surveillance de ce type de comportement à l'aide de XE) ici .
Vérifier les DMV
Si le mouvement des données est suspendu, vous pouvez vous référer aux DMV pour obtenir plus d'informations sur la raison de la suspension. Exécutez ce qui suit:
select db_name(database_id), synchronization_state_desc, database_state_desc, suspend_reason_desc
from sys.dm_hadr_database_replica_states
article BOL décrit un peu plus la suspend_reason.
Votre groupe de disponibilité distribuée (DAG) est-il divisé entre différentes régions? Si c'est le cas, vous pourriez souffrir de la valeur par défaut de SESSION_TIMEOUT (10 secondes). Cela signifie que la latence entre les deux régions est trop élevée pour terminer la synchronisation de manière fiable.
Un groupe de disponibilité normal peut voir sa valeur SESSION_TIMEOUT augmentée pour rendre les sessions de synchronisation plus stables. J'ai remarqué à la fin de l'année dernière que le paramètre SESSION_TIMEOUT des DAG ne pouvait pas être modifié. Cela signifiait que les DAG n'étaient viables que pour les scénarios à faible latence. Nous avons enregistré un ticket avec Microsoft et plus tôt cette année, un correctif a été publié.