Dans cet article, nous explorerons les concepts de surveillance et de basculement dans un groupe de disponibilité Always On de SQL Server. Comme nous l’avons appris dans les articles précédents, un groupe de disponibilité distribué peut être mis en œuvre entre plusieurs nœuds de cluster de basculement indépendants. Maintenant, plongeons dans les détails des processus de surveillance et de basculement.
Vérification du groupe de disponibilité Always On SQL Server distribué
Tout d’abord, vérifions la configuration du groupe de disponibilité distribué. Connectez-vous à la réplique principale du cluster principal et développez le groupe de disponibilité. Vous verrez un mot-clé “Distribué” pour le groupe de disponibilité distribué. Cependant, si vous vous connectez à la réplique secondaire du cluster principal, vous ne verrez pas le groupe de disponibilité distribué. Cela est dû au fait que le groupe AG distribué est configuré sur l’URL du listener qui se connecte toujours à la réplique principale. La base de données du groupe de disponibilité distribué doit être dans un état synchronisé.
Surveillance du groupe de disponibilité distribué
Nous pouvons utiliser des vues de gestion dynamique (DMV) pour surveiller le groupe de disponibilité distribué et ses performances. Les DMV suivantes peuvent être utilisées pour la surveillance du groupe de disponibilité :
- Sys.dm_hadr_availabilty_replica_states
- Sys.availabilty_replica
- Sys.availability_groups
Ces DMV fournissent des informations sur l’état de la réplique, le rôle, le mode de basculement et les configurations sous-jacentes du groupe de disponibilité. Nous pouvons également utiliser la DMV sys.dm_hadr_database_replicas_states pour vérifier l’état de synchronisation actuel, le taux de journalisation, la taille de la file d’attente de refaire et le taux de refaire du groupe de disponibilité distribué.
Surveillance des compteurs de performance du système d’exploitation pour le groupe de disponibilité distribué
En plus des DMV, nous pouvons utiliser la DMV sys.dm_os_performance_counters pour récupérer les compteurs de performance du système d’exploitation et leurs valeurs directement à partir de SQL Server. En spécifiant le nom du groupe AG distribué dans la requête, nous pouvons surveiller l’état de santé du groupe de disponibilité distribué en vérifiant les valeurs des compteurs de performance.
Basculement dans le groupe de disponibilité Always On SQL Server distribué
Dans un groupe de disponibilité distribué, le basculement manuel est pris en charge, mais les basculements automatiques ne sont pas possibles car les répliques sont dans des clusters différents. Pour effectuer un basculement manuel, suivez ces étapes :
- Assurez-vous que le groupe de disponibilité distribué est en mode synchronisé et que le last_hardened_lsn est le même pour la réplique principale et le transmetteur.
- Exécutez la commande suivante sur la réplique principale du cluster principal pour changer son rôle en secondaire :
ALTER AVAILABILITY GROUP distributedag SET (ROLE = SECONDARY); - Effectuez un basculement manuel avec le paramètre
FORCE_FAILOVER_ALLOW_DATA_LOSSen exécutant la commande suivante sur la réplique principale actuelle du groupe de disponibilité secondaire :ALTER AVAILABILITY GROUP distributedag FORCE_FAILOVER_ALLOW_DATA_LOSS;
Après le basculement, surveillez le groupe de disponibilité distribué pour vous assurer qu’il est à nouveau synchronisé. Il peut prendre un certain temps pour que les bases de données se synchronisent complètement.
Impact du basculement au sein d’un cluster
Lors de l’exécution d’un basculement au sein d’un cluster, tel que l’application de correctifs Windows aux répliques AG dans le site principal, cela peut avoir un impact sur le groupe de disponibilité distribué. Comme le groupe AG distribué fonctionne sur le listener SQL, qui pointe toujours vers la réplique principale, un basculement peut entraîner le passage du groupe de disponibilité distribué à une nouvelle réplique principale. Cela peut entraîner une interruption temporaire des transactions et nécessiter de rétablir les connexions à partir du principal global.
Conclusion
Dans cet article, nous avons exploré les concepts de surveillance et de basculement dans un groupe de disponibilité Always On de SQL Server. En utilisant des vues de gestion dynamique et en surveillant les performances du groupe de disponibilité distribué, nous pouvons garantir sa santé et prendre les mesures nécessaires en cas de besoin. Comprendre l’impact du basculement au sein d’un cluster est également crucial pour maintenir la disponibilité et l’intégrité du groupe de disponibilité distribué.