Comportement de la réplication Mysql

[cedricgirard]

Bonjour,

nous utilisons un serveur Mysql répliqué sur un esclave (mis en place par un prestataire). Sur le masteur, à longueur de journée je peux voir une tâche tourner

Code :

14565  replimol   31703 Binlog Has sent ALL binlog TO slave; waiting FOR binlog TO be updated

Je me demande si c'est bien normal. De plus le presta nous a averti qu'il y avait parfois des gros retards de réplication. Ne connaissant pas grand chose je cherche des pistes et conseils.

Merci
Cédric

[cyrill.gremaud]

bonjour cedricgirard.

Votre prestataire vous a-t-il dit dans quel cas ce retard pouvait être présent ? Est-il dû à un paramètre bien spécifique ou est-ce une généralité avec l'architecture de replication ?

salutations

[cedricgirard]

Il a juste mentionné ce fait (l'esclave est en retard) comme anormal. En expliquant cela par le fait qu'on écrivait peut être directement sur l'esclave, ce qui n'est pas possible vu notre configuration (ou alors c'est leur architecture qui délire, celle qui est censée remplacer le maitre par l'esclave en cas de panne du premier).

[Sivrît]

Le message, si j'interprète correctement, indique que l'intégralité du log binaire a été envoyé à (aux) l'esclave et donc que la tâche chargée de le relayer est au chômage technique jusqu'à ce qu'il y ait des modifications de la base. Ca me semble tout à fait normal.

Il y a des retard, ou bien il prévient qu'il peut y en avoir ? Par définition l'esclave est toujours un peu derrière, sauf s'il ne se passe rien. Le retard augmente avec l'activité mais doit normalement rester raisonnable, surtout que le maitre doit être plus chargé que l'esclave.
S'il augmente vraiment il se pourrait que (liste non exhaustive, je ne suis pas expert du sujet) :

• La machine de l'esclave est moins puissante que le maitre et lors des pics d'utilisation elle peine à suivre
• Les modifications sont faites sur le maitre mais on profite de l'esclave pour répartir les SELECT et l'esclave ne suit plus (ou une grosse requête dure longtemps et ses verrous en lecture sur l'esclave l'empêchent de réaliser ses mises à jour avant qu'elle se termine).
• Les backup (mysqldump) sont réalisés sur l'esclave et la charge et/ou le verrouillage ralentissent et/ou bloquent le processus de réplication.
• Le requêtes sont rejouées séquentiellement sur l'esclave. Si l'une d'elle prend 5 minutes, l'esclave prend 5 minutes de retard pendant ce temps (mais devrait le rattraper par la suite).
• La transmission du log traine... reste à voir pourquoi. Réseau congestionné ?

[replivit]

Bonjour,

je confirme SilVrit: à vérifier :
1- ce qui tourne sur le Slave
2- la dimension de la machine slave: il n'y a pas d'économie à mettre un slave moins costaud que le master, si ce n'est perdre des données qui n"ont pas encore été répliquées par manque de temps, et/ou engorgement des binlog sur le Slave.
3- engorgement du réseau : sur un LAN : se réserver ce qu'il faut, voire mettre une connexion directe au plus haut. sur un WAN , plus dur, sachant que la communication entre le master et son (ses) slaves est conpressés nativement dans le moteur MySQL. trier (QoS) et vérifier les flux (analyse)reste la meilleure route vers la solution.

4- il apparaît que le moteur de réplication peut prendre du retard. Cependant, ton message n'est pas inquiétant. il s'agit juste d'une info du master. consulter les logs sur le slave pour savoir où il en est de la "digestion" des logs du master.