Les bases de données SQL Server Distributed Availability Group ne se synchronisent pas après un redémarrage du serveur

Nous nous apprêtons à effectuer une 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 groupe de disponibilité (AG) distinct . Lorsque nous avons mis à niveau ce serveur, nous ne savions pas qu'il entrerait dans un état illisible , donc au cours du dernier mois, nous nous sommes uniquement appuyés sur le serveur principal.

Dans le cadre de la prochaine mise à niveau, j'ai appliqué le patch 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 non à une synchronisation / pas en bonne santé État

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écute sans erreur, mais n'a 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é se disent 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 redirecteur / principal global)
• La réponse de Dan 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_blockou sqlserver.hadr_apply_log_blockpour voir si le secondaire reçoit / applique réellement les blocs de journal 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 STARTUPSPID 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

L' article BOL décrit un peu plus la suspension_reason.

Votre groupe de disponibilité distribuée (DAG) est-il réparti 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é.

Amélioration: configurer la valeur SESSION_TIMEOUT pour une réplique de groupe de disponibilité distribuée dans SQL Server 2016 et 2017