Surveillance de la synchronisation du réplica du groupe de disponibilité

Si vous déployez des groupes de disponibilité SQL Server, l'un des aspects importants d'un déploiement réussi consiste à surveiller la synchronisation des bases de données du réplica secondaire avec le réplica principal. Il existe plusieurs façons de surveiller la synchronisation des réplicas dans un groupe de disponibilité, et cet article présentera chacune d'elles et expliquera leurs avantages et leurs inconvénients,

L'un des moyens les plus simples de surveiller l'état d'un groupe de disponibilité, de chacun des serveurs réplicas et des bases de données de disponibilité consiste à utiliser le tableau de bord intégré dans Management Studio. Cependant, la disposition par défaut du tableau de bord ne fournit pas beaucoup de détails et devra être personnalisée pour afficher des informations supplémentaires sur les serveurs réplicas ainsi que sur les bases de données de disponibilité. Des colonnes supplémentaires peuvent être ajoutées à la mise en page via le lien Ajouter/Supprimer des colonnes sur le tableau de bord, ou via le menu contextuel du clic droit sur l'un des en-têtes de colonne existants, comme indiqué ci-dessous :

Personnalisation du tableau de bord AG dans SSMS

Pour les bases de données de disponibilité, la surveillance de la taille de la file d'attente d'envoi du journal (Ko), du taux d'envoi du journal (Ko/s), de la perte de données estimée (durée), du temps de récupération estimé (secondes) et des performances de synchronisation (secondes) vous permettra de mieux comprendre de la façon dont les données circulent vers les réplicas et de l'état général des bases de données de disponibilité. Par exemple, dans la capture d'écran ci-dessous, j'ai modifié la configuration réseau de la machine virtuelle pour SQL03 afin qu'elle ait une latence plus élevée et un débit plus faible, ce qui affecte la synchronisation des bases de données :

Ici, nous pouvons voir qu'il y a près de six minutes de perte de données potentielles pour SQL03, et 505 Mo de journal non envoyé qui est envoyé à un débit de 7 Mo/sec au secondaire (qui, dans ce cas, est un secondaire asynchrone) . Alors que SQL02 est actuellement rattrapé et n'a aucune perte de données en tant que secondaire synchrone dans la configuration.

Une alternative au tableau de bord du groupe de disponibilité est l'interrogation directe des DMV, d'où le tableau de bord extrait ses informations en tant que source. La requête suivante affiche l'état actuel et les métriques de synchronisation pour chaque base de données d'un groupe de disponibilité :

SELECT 
	ar.replica_server_name, 
	adc.database_name, 
	ag.name AS ag_name, 
	drs.is_local, 
	drs.is_primary_replica, 
	drs.synchronization_state_desc, 
	drs.is_commit_participant, 
	drs.synchronization_health_desc, 
	drs.recovery_lsn, 
	drs.truncation_lsn, 
	drs.last_sent_lsn, 
	drs.last_sent_time, 
	drs.last_received_lsn, 
	drs.last_received_time, 
	drs.last_hardened_lsn, 
	drs.last_hardened_time, 
	drs.last_redone_lsn, 
	drs.last_redone_time, 
	drs.log_send_queue_size, 
	drs.log_send_rate, 
	drs.redo_queue_size, 
	drs.redo_rate, 
	drs.filestream_send_rate, 
	drs.end_of_log_lsn, 
	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;

En interrogeant les DMV directement sur le réplica principal, il est facile d'obtenir des informations à jour sans attendre la période d'actualisation du tableau de bord dans Management Studio. Cela a été utile à quelques reprises lors de consultations avec des clients qui ont eu une défaillance de liaison entre les centres de données, ou lorsque la connectivité a été interrompue pour maintenance pendant un certain temps, et que les répliques secondaires sont en train de rattraper leur retard une fois la connexion rétablie. .

L'outil natif final pour surveiller la synchronisation du groupe de disponibilité est l'Analyseur de performances, à l'aide de l'objet de performance SQLServer:Database Replica. Le tableau ci-dessous montre les compteurs de performances pertinents et leurs descriptions de la documentation en ligne (https://msdn.microsoft.com/en-us/library/ff878356(v=sql.110).aspx) :

L'un des défis et des limites de l'utilisation de l'Analyseur de performances pour surveiller l'environnement est que l'objet n'est valide que sur l'instance de SQL Server qui héberge un réplica secondaire. Cela signifie que vous devez ajouter les compteurs de chaque réplica secondaire dans l'Analyseur de performances pour obtenir une vue complète de ce qui se passe avec toutes les bases de données secondaires, où le tableau de bord AG dans Management Studio et la requête DMV sur le réplica principal, fournissent des informations sur toutes les bases de données secondaires en un seul emplacement.

Comme alternative aux fonctionnalités intégrées de surveillance de la synchronisation des groupes de disponibilité, vous pouvez également tirer parti d'outils tiers tels que SQL Sentry Performance Advisor, qui inclut la surveillance des groupes de disponibilité en tant que fonctionnalité standard. Vous pouvez en savoir plus sur cette fonctionnalité dans ce billet de blog de Greg Gonzalez qui a introduit la fonctionnalité pour la première fois dans la version 7.5 du produit.

Tableau de bord Performance Advisor AG

L'onglet Répliques de Performance Advisor permet à chacun des serveurs de répliques secondaires d'être développé pour afficher facilement les bases de données et leurs données de synchronisation actuelles. La disposition par défaut de la matrice de nœud/groupe WSFC en haut du tableau de bord fournit également des informations sur l'état de la file d'attente d'envoi du réplica principal, l'état de la file d'attente de rétablissement du réplica secondaire et le flux de données entre chacun des serveurs de réplica. Dans cet exemple, nous pouvons voir que la file d'attente d'envoi de journaux sur le primaire envoie actuellement une grande quantité de données de SQL01 à SQL03, en fonction de la largeur de la ligne entre les serveurs, après que les problèmes de connectivité entre SQL01 et SQL03 ont été corrigés dans l'environnement. Le graphique de droite montre la vitesse à laquelle les données sont transférées depuis SQL01, ainsi que la taille actuelle de la file d'attente d'envoi du journal, puisqu'il s'agit de la réplique sélectionnée sur le côté gauche. Cliquer sur l'un des autres serveurs de réplica dans la disposition de la matrice de nœud/groupe WSFC modifiera également le graphique pour qu'il corresponde aux mesures de performances de ce réplica spécifique sur le côté droit.

Il existe de nombreuses façons de surveiller les performances de la synchronisation des données entre les serveurs réplicas dans un groupe de disponibilité dans SQL Server. Le tableau de bord du groupe de disponibilité intégré dans Management Studio contient une multitude d'informations faciles d'accès une fois que vous savez comment personnaliser la disposition pour afficher les informations les plus importantes sur le tableau de bord. Il est également possible d'utiliser les DMV directement à partir du serveur réplica principal pour surveiller les performances de la synchronisation des données à l'aide de Transact-SQL, et des outils tiers comme SQL Sentry incluent également la surveillance de la synchronisation des données. Bien que l'Analyseur de performances puisse fournir ces mêmes informations, le fait que les compteurs de performances ne soient disponibles qu'à partir du serveur réplica secondaire rend un peu plus de travail pour obtenir une vue complète de l'ensemble de l'environnement.