Monitor replication mysql

 Monitor réplication MySql

 

monitoring-replication-mysql

 

Configurer une réplication MySQL n’est pas suffisant, vous devez surveiller régulièrement vos esclaves pour s’assurer qu’ils ‘continuent à travailler de façon transparente avec monitor réplication MySql. Voici une vue d’ensemble des esclaves à surveiller et les outils qui vous aideront à surveiller avec facilité.

Vous avez mis en place une réplication en temps réel d’une base de donnée MySql,
le passage du maître->esclave ne se fera pas si la réplication ne fonctionne plus.

Monitor réplication MySql

status=0
MasterHost=”192.168.80.1″
SlaveHost=”192.168.80.2″
emails=”alert@domaine.fr”
ReplicationDownAlert=”Replication status – Not OK”
ReplicationGoodAlert=”Replication status – OK”
ReplicationGoodMessage=”Etat de la réplication sur $SlaveHost est OK.\n\n\n”

 

Script monitor replication mysql

Slave_SQL_Running et Slave_IO_Running

monitor-mysql.sh

!#/bin/sh

SQLresponse=`mysql -u root –password=xxxxxx test -e “show slave status \G” |grep -i “Slave_SQL_Running”|gawk ‘{print $2}’`

IOresponse=`mysql -u root –password=xxxxx test -e “show slave status \G” |grep -i “Slave_IO_Running”|gawk ‘{print $2}’`

if [ “$SQLresponse” = “No” ]; then
error=”La réplication sur le serveur exclave ($SlaveHost) n’est plus en fionctionnement.\nSlave_SQL_Running: No\n”
status=1
fi
if [ “$IOresponse” = “No” ]; then error=”La réplication sur le serveur exclave($SlaveHost) n’est plus en fionctionnement.\nSlave_IO_Running: No\n”
status=1
fi

# si la réplication ne fonctionne pas
if [ $status = 1 ]; then
for address in $emails; do
echo -e $error | mail -s $ReplicationDownAlert $address
echo “Replication NOK, envoie email à $address”
done
fi

# si la réplication fonctionne
if [ $status = 0 ]; then
for address in $emails; do
echo -e $ReplicationGoodMessage | mail -s $ReplicationGoodAlert $address
echo “Replication est OK, envoie email à $address”
done
fi

Monitor réplication MySql

Variables mysql à surveiller sur vos esclaves pour

La réplication mysql est mieux surveillée en cochant la variable- suivante

Slave_running : Il s’agit d’une valeur variable globale et Son statut peut être vérifiée à l’aide SHOW STATUS GLOBAL comme «Slave_running. Soit il peut être «ON» ou «OFF».

Si Slave_running est “ON”, alors l’esclave est en place et fonctionnent bien, ce qui signifie deux le thread SQL et le fil IO sont en cours d’exécution. Si Soit le fil ou le thread SQL n’est pas en cours d’exécution IO Cette variable serait alors «OFF». Utilisez la commande SHOW SLAVE STATUS et essayer de déterminer l’existence d’une erreur ou l’esclave a été arrêté manuellement. Vérifiez les 100 dernières lignes du journal des erreurs de l’esclave pour voir si qui donne un indice. Regardez Last_Error_Number et Last_Error_Message les informations d’erreur spécifique et réparer votre esclave.

Les variables suivantes sont une partie de la commande SHOW SLAVE STATUS
Slave_IO_Running : Il nous dit si le fil IO de l’esclave est fiable pour se connecter à maître IST et fonctionne très bien. Les valeurs possibles pour la variable, ceci est «Oui» ou «Non» ou « connexion ».

 

Si cette variable écrit “NON” alors vous devrez vérifier la Last_Error_Number et Last_Error_Message et réparer votre esclave. Depuis MySQL 5.1.20, dans les colonnes d’origine sont des alias pour Last_SQL_Errno et Last_SQL_Error. Avant 5.1.20, ils ‘indiquent le nombre d’erreur et le message d’erreur renvoyé par la dernière instruction exécutée. Un numéro d’erreur de 0 et le message de la chaîne vide signifie “pas d’erreur.”
Slave_SQL_Running : Il indique si le thread SQL de l’esclave a commencé et fonctionne très bien. Les valeurs possibles sont variables de esta «Oui» ou «Non».

 

Si cette variable se lit «Non», puis le fil IO a été causé à arrêter. Vous devrez vérifier la Last_SQL_Errno et Last_SQL_Err pour plus d’informations sur la cause. Un numéro d’erreur de 0 et le message de la chaîne vide signifie “pas d’erreur”. Last_SQL_Error les apparaît de l’esclave dans le journal d’erreur.
Seconds_Behind_Master: Comme son nom l’indique, ce champ indique le retard est votre esclave. En d’autres termes, il indique le temps en secondes que le thread SQL de l’esclave accuse lors du traitement de log binaire de maître. Une augmentation continue Cette valeur n’est pas un très bon signe car cela signifie que l’esclave n’est pas fiable pour rattraper son maître. Il n’existe pas de valeur seuil pour cette variable à comparer à, afin de déterminer si la valeur est élevée ou basse. Il dépend entièrement de votre demande, la vitesse du réseau, etc

 

NOTE: Bien que Seconds_Behind_Master est la meilleure option disponible pour la détermination de l’esclave décalage disponible dans toutes les versions de MySQL, il a été-pour ne pas être toujours critiqué précis.

MySQL version 5.5

A le statut de variable MASTER_HEARTBEAT_PERIOD Septembre Lorsque Quel sera envoyer des colis à battre l’esclave. Après la perte d’un battement du fil Slave IO se déconnecte et essayez de vous reconnecter. Différentes solutions pour l’ajout d’un «battement de coeur» ont été mécanisme proposé et des correctifs et des plug-ins sont disponibles pour MySQL <5.5. Si vous avez de tels ajoutée mécanisme de «battement de coeur» que vous devriez suivre ainsi.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.

* Copy This Password *

* Type Or Paste Password Here *