SQL Server 2012 (11.0.5058.0) Enterprise Edition
Nous avons 8 groupes de disponibilité dans un cluster 2 (HA) +1 (DR) et nos DMV de surveillance rapportent des résultats qui me déroutent. 6 Les groupes de disponibilité sont configurés pour HA et DR, 1 est configuré pour HA uniquement et 1 est configuré pour DR uniquement.
Chacun des 6 groupes de disponibilité HA / DR a «SQLB» en tant que réplique HA (SQLA) secondaire et «SQLA» en tant que réplique secondaire (synchrone) et «SQLC» en tant que réplique secondaire (async).
Sur les deux secondaires:
SELECT dhags.group_id, dhags.synchronization_health_desc
FROM sys.dm_hadr_availability_group_states dhags
signale que tous les états de synchronisation de la réplication du groupe de disponibilité sont NOT_HEALTHY
et
select replica_id,synchronization_health_desc
from sys.dm_hadr_availability_replica_states
signale que toutes les répliques ont un état de synchronisation de HEALTHY
.
Le réplica principal signale tous les groupes de disponibilité et réplicas avec un état de synchronisation de HEALTHY
.
Bien que je comprenne qu'un rapport sur la santé de la synchronisation des répliques et les autres rapports sur la santé de la synchronisation AG, il me semble logique que si l'état plus granulaire (AG) n'était pas sain, cela affecterait la santé globale du contexte plus large (réplique) . Je ne trouve pas de documentation MSDN qui décrit comment l'état de santé est déterminé à chaque niveau.
Pourquoi les secondaires établiraient-ils un rapport NOT_HEALTHY
sur l'intégrité de la synchronisation du groupe de disponibilité, mais HEALTHY
sur l'intégrité de la synchronisation des réplicas, et pourquoi cela diffère-t-il du rapport du principal?
la source
NOT_HEALTHY
uniquement sur la réplique ASYNC secondaire?NOT_HEALTHY
à la fois sur les répliques SYNC et ASYNC.Réponses:
Malheureusement, sys.dm_hadr_availability_replica n'est pas un indicateur fiable de l'intégrité des répliques. Voici l'élément Connect sur l'un des bogues que nous avons rencontrés où DMV cesse de se rafraîchir - notez dans les commentaires que log_send_queue_size dans le DMV sys.dm_hadr_database_replica_states affiche 0 même lorsqu'il y a des données de journal à envoyer.
Notez que l'élément Connect est marqué comme ne sera pas résolu. Trombone triste.
la source
sys.dm_hadr_availability_group_states.synchronization_health_desc
(ce que je comprends, c'est un rapport sur la santé de l'ensemble du groupe) des rapportsNOT_HEALTHY
sur les secondaires, maisHEALTHY
sur les primaires (3 répliques). Les documents décrivent le col comme "un cumul de synchronization_health de toutes les réplicas de disponibilité dans le groupe de disponibilité". Cela montre la disparité au sein du système sans même regarder sys.dm_hadr_availability_replica_states (qui est, vraisemblablement, d'où les données sont remontées).