1

vous pouvez utiliser l'outil de maatkit mk-heartbeat

2

vous pouvez regarder le résultat de

show slave status;

fonctionne sur sql slave mais Seconds_Behind_Master est parfois d'une imprécision troublante.

3

vous pouvez bricoler votre propre solution, similaire à la mienne - je l'utilise à la fois pour nagios la surveillance et l'alimentation munin Les graphiques montrent les "secondes derrière le maître".

Sur le serveur principal, j'ai une simple tâche cron :

* * * * * root /usr/local/bin/repltest

où repltest est :

#!/bin/bash
start=`date +%s`
d=0
while [ $d -lt 60 ] ; do
        echo "update repl_test set t= NOW(); " |mysql --defaults-file=/etc/mysql/debian.cnf repl_test
        sleep 3
        d=$(( `date +%s` - $start ))
done

sur l'esclave i valeur du moniteur retournée par :

echo "select UNIX_TIMESTAMP(NOW())-UNIX_TIMESTAMP(t) from repl_test" |  mysql --defaults-file=/etc/mysql/debian.cnf -N repl_test

L'heure locale de tous les serveurs est synchronisée via ntp.

repl_test db contient :

CREATE TABLE IF NOT EXISTS `repl_test` (`t` datetime NOT NULL) ENGINE=MyISAM DEFAULT CHARSET=utf8;
INSERT INTO `repl_test` (`t`) VALUES(NOW());

si vous exécutez la réplication - je suggère que vous configuriez également mk-table-checksum pour comparer le contenu de vos serveurs sql de temps en temps.

PQd l'a fait, vérifier "show slave status" est le moyen le plus simple. En ce qui concerne l'inexactitude de Seconds_behind_master, je voulais mentionner que la valeur est la différence dans l'horodatage de la déclaration lue dans le journal du relais par le thread SQL esclave ; elle n'est pas liée à une estimation du temps qu'il faudra pour rattraper le retard. Par exemple, une seule mise à jour de longue durée qui prend, disons, une heure à exécuter, fera apparaître l'esclave jusqu'à une heure derrière son maître, mais une fois la déclaration terminée, il pourrait très bien n'avoir qu'une seconde de travail à faire pour rattraper son retard.

De plus, vous voudrez accorder le statut de 'CLIENT DE REPLICATION' à l'utilisateur à partir duquel vous effectuerez la surveillance afin de récupérer le statut de l'esclave ;

La réponse évidente, comme d'autres l'ont dit, est d'utiliser une variation de SHOW SLAVE STATUS. Personnellement, j'utilise le vérificateur intégré à Nagios, mais c'est parce que je fais déjà toutes sortes d'autres surveillances avec Nagios. Il y a cependant un problème, il est possible que SHOW SLAVE STATUS montre les deux processus en cours d'exécution et que l'esclave soit bloqué. D'après ce que nous pouvons dire (parce que nous avons eu le problème et l'avons étudié), le problème se produit lorsqu'il y a des burps réseau d'une durée trop courte pour tuer l'esclave mais trop longue pour qu'il puisse récupérer correctement. Nous avons trouvé un moyen de contourner le problème en examinant l'horodatage de la dernière entrée dans une table qui change régulièrement et en la comparant entre le maître et l'esclave, puis en lançant une alerte si le retard est "trop important". Ce n'est pas parfait et cela ne fonctionnerait que dans certaines circonstances, mais vous êtes prévenus.

Vous pouvez vous référer à cet article de blog qui mentionne tous les outils open-source et commerciaux qui montre http://blog.webyog.com/2012/11/20/how-to-monitor-mysql-replication/

En général, ce blog comprend des outils tels que pt-heartbeat : Outil pratique pour surveiller le décalage des esclaves en temps réel. pt-slave-restart : Surveille et redémarre l'esclave en cas d'erreur. pt-slave-find : Trouve la hiérarchie de réplication des esclaves. pt-table-checksum : Vérifie si les bases de données sur les esclaves sont synchronisées avec leur maître.

MySQL Enterprise Monitor : Un "Assistant DBA virtuel" d'Oracle est un outil de surveillance basé sur un agent et doté d'une interface graphique web soignée. L'onglet "Réplication" donne une vue topologique de tous les maîtres et de leurs esclaves, ainsi que les résultats de SHOW SLAVE STATUS et SHOW MASTER STATUS.

MONyog - Moniteur et conseiller MySQL : Il prend en charge la surveillance et la gestion de la réplication, notamment l'onglet "Réplication" qui donne une vue topologique de tous les maîtres et de leurs esclaves, ainsi que les fonctions SHOW SLAVE STATUS et SHOW MASTER STATUS.

Utilice

mysql_config_editor set --login-path=local --host=<< your slave >> --user=username --password

et

mysql_config_editor set --login-path=remote --host=<< your master >> --user=username --password

pour définir des valeurs de connexion prédéfinies afin d'éviter Avertissement : L'utilisation d'un mot de passe sur l'interface de ligne de commande peut être peu sûre.

Utilisez-les pour interroger les deux serveurs MySql :

1. Compare la position du journal sur le maître avec Exec_Master_Log_Pos sur l'esclave :

   master_log=$(mysql --login-path=remote -e "show master status" | grep -v File | awk '{print $2}')

   slave_exec=$(mysql --login-path=local -e "show slave status \G " | grep Exec_Master_Log_Pos | awk '{print $2}')

   diff=$(( $master_log - $slave_exec ))

2. Vérifiez l'état de l'IO de l'esclave pour voir s'il est en cours d'exécution :

   IO_Status=$(mysql --login-path=local -e "show slave status \G " | grep Slave_IO_Running | awk '{print $2}')

3. Vérifiez l'état de l'esclave SQL pour voir s'il est correct ou non :

   SQL_Status=$(mysql --login-path=local -e "show slave status \G " | grep "Slave_SQL_Running :" | awk '{print $2}')

Vous pouvez ensuite utiliser les valeurs de $diff, $SQL_Status et $IO_Status pour envoyer des courriels d'avertissement si elles ne correspondent pas à certaines valeurs, selon vos préférences.