Dans une configuration de réplication d'hébergement MySQL, le paramètre Seconds_Behind_Master (SBM), tel qu'affiché par la commande SHOW SLAVE STATUS, est couramment utilisé comme une indication du retard de réplication actuel de l'esclave . Dans cet article de blog, nous examinons comment comprendre et interpréter cette valeur dans diverses situations.
Valeurs possibles de Secons Behind Master
La valeur de SBM, comme expliqué dans la documentation MySQL, dépend de l'état de l'esclave MySQL en général, et des états de l'esclave MySQL SQL_THREAD et IO_THREAD en particulier. Pendant que IO_THREAD se connecte au maître et lit les mises à jour, SQL_THREAD applique ces mises à jour sur l'esclave. Examinons les valeurs possibles de SBM lors de différents états de l'esclave MySQL.
Lorsque la valeur SBM est nulle
- SBM est toujours NULL si votre esclave est arrêté ou si votre thread SQL est arrêté (ou ne fonctionne pas).
- SBM sera également NULL si le thread IO est arrêté, à condition que le thread SQL ait déjà traité tous les événements du journal de relais. Un exemple de sortie de SHOW SLAVE STATUS (coupé pour n'afficher que les valeurs intéressantes) le démontre :
Slave_IO_State :
Master_Host :172.19.0.13
Slave_IO_Running : Non
Slave_SQL_Running :Oui
Seconds_Behind_Master :NULL
Master_UUID :23b326b1-a452-11e8-91ca-000d3a065e8e
Slave_SQL_Running_State :l'esclave a lu tous les journaux de relais ; en attente de nouvelles mises à jour
Retrieved_Gtid_Set :23b326b1-a452-11e8-91ca-000d3a065e8e:818-389213
Executed_Gtid_Set :23b326b1-a452-11e8-91ca-000d3a065e8e:1-389213
Lorsque la valeur SBM est nulle ou positive
- SBM va refléter une valeur valide (>= 0) lorsque le thread SQL traite activement des événements. Cela est vrai quel que soit l'état du thread IO. Par exemple :
Slave_IO_State :
Master_Host :172.19.0.13
Slave_IO_Running : Non
Slave_SQL_Running :Oui
Seconds_Behind_Master :3399
Master_UUID :23b326b1-a452-11e8-91ca-000d3a065e8e
Slave_SQL_Running_State :attendre que les travailleurs esclaves traitent leurs files d'attente
Retrieved_Gtid_Set :23b326b1-a452-11e8-91ca-000d3a065e8e:818-389213
Executed_Gtid_Set :23b326b1-a452-11e8-91ca-000d3a065e8e:1-118774
Dans l'exemple ci-dessus, nous pouvons voir que l'esclave est derrière le maître en comparant le Retrieved_GTID_Set et le Executed_GTID_Set. Dans de tels cas, Seconds_Behind_Master représentera la différence entre l'horodatage de la dernière transaction traitée par le thread SQL et l'horodatage de la même transaction lorsqu'elle a été traitée sur le maître. Cet horodatage de transaction du maître est conservé grâce à la réplication et, par conséquent, l'esclave pourra calculer le SBM localement.
En outre, une fois que l'esclave a complètement rattrapé tous les journaux de relais (c'est-à-dire que le GTID exécuté devient 23b326b1-a452-11e8-91ca-000d3a065e8e:1-389213/), Seconds_Behind_Master passer à '0' si le Thread IO est en cours d'exécution, ou à 'NULL' si le Thread IO n'est pas en cours d'exécution.
Tutoriel #MySQL - Comprendre les secondes derrière la valeur principaleCliquez pour tweeter
Comprendre la vitesse d'exécution de l'esclave MySQL
En supposant que le thread SQL et le thread IO sur l'esclave sont en cours d'exécution, il est possible de comprendre les vitesses d'exécution relatives du maître et de l'esclave en surveillant la valeur SBM. Une valeur « 0 » cohérente ou une valeur constante indique que l'esclave s'exécute à la même vitesse que le maître. D'autre part, une pente ascendante pour Seconds_Behind_Master indique que l'esclave fonctionne plus lentement que le maître.
La console de surveillance de ScaleGrid pour MySQL sur Azure trace les valeurs de SBM au fil du temps pour les nœuds esclaves.
Valeur nulle ou constante de SBM
Dans l'exemple ci-dessus, l'esclave a été démarré environ 40 heures après que le maître ait eu des écritures actives. Une fois démarré, l'esclave a commencé à répliquer ces données, et nous voyons que le SBM était assez plat indiquant que l'esclave s'exécutait à la même vitesse que le maître. Notez également que la chute de SBM à '0' est abrupte, ce qui signifie en réalité que bien que la dernière transaction exécutée par l'esclave ait été exécutée environ 40 heures avant sur le maître, une fois que nous avons rattrapé le retard, il y a un retard de '0'.
Augmentation des valeurs de SBM
Dans le graphique ci-dessous, nous pouvons voir que SBM augmente constamment, ce qui signifie que la vitesse d'exécution de l'esclave est inférieure à celle du maître. Il s'agit en fait d'un cas où nous exécutons 20 threads effectuant des écritures continues sur le maître et un esclave monothread n'est pas en mesure de suivre le rythme.
Enfin, il est important de noter que dans nos discussions jusqu'à présent, nous n'avons supposé aucun goulot d'étranglement du réseau. En cas de réseaux lents, le thread IO esclave lui-même sera en retard sur le maître, et si le thread SQL est assez rapide, le SBM oscillera entre '0' et un nombre positif. Dans de tels cas, SBM ne sera pas un paramètre utile pour comprendre le décalage réel avec le maître.
Si vous avez apprécié cet article de blog, consultez nos autres tutoriels populaires de gestion de base de données MySQL pour en savoir plus sur l'optimisation de vos déploiements :
- Calcul de la taille du pool de tampons InnoDB pour votre serveur MySQL
- Tutoriel MySQL – Configuration et gestion de SSL sur votre serveur MySQL
- Explication du cadre de haute disponibilité MySQL – Partie I :Introduction
