Failback – Réplication MySQL Master/Slave
Conférence MySQL au Fosdem 2009
Euro Web était présent au Fosdem 2009,
et nous avons assisté à une présentation de Geert Vanderkelen sur la
haute disponibilité
avec MySQL :
La présentation n’a pas abordé la question des failback, nous souhaitons l’aborder ici.
Introduction / Prérequis
Attention, c’est le coté « protocole à suivre » que nous détaillons, ce howto à pour pré-requis
le fait que vous ayez déjà mise en place de la réplication MySQL.
Supposons que nous ayons ultérieurement mis en place une configuration comme la suivante, c’est à
dire : réplication MySQL avec un serveur
MySQL en master, un en esclave, et une ip virtuelle
qui passe du master au slave (grâce à heartbeat par exemple ; avec auto_failback = off)
Lorsque tout va bien, l’esclave exécute aveuglément les instructions binaires transmises par le master,
ce qui implique qu’il ne faut en aucun cas écrire sur l’esclave directement au risque inévitable
de créer des conflits. On y vient…
L’instant fatal, le crash
Supposont simplement que – par malchance – le serveur MySQL maître plante, reboot, et enchaine ensuite
sur un assez long fsck.
Heartbeat, qui aura bien été configuré dans ce but, aura fait alors basculer l’ip
virtuelle sur le serveur slave.
L’IP virtuelle pointant maintenant sur l’esclave, il traîte alors des requêtes d’écriture
directes. Le soucis c’est que nous sommes dans une configuration Maître-Esclave, le master sera de nouveau
fonctionnel à un moment donné et tout doit être fait pour qu’il ne reçoive pas de
nouvelles requêtes – et c’est le cas, puisque (voir plus haut) : auto_failback = off
Synchroniser les données sur le master
Les étapes suivantes vont permettre de remettre les données utiles sur le master, en le transformant
temporairement en slave. De plus, le slave va être désactivé.
- —– MySQL fonctionne correctement, mais en mode dégradé —–
- Stoppons Heartbeat sur le master (l’ip restera sur le slave)
- Stoppons MySQL sur le master
- Activons les log-bin sur le slave (si ce n’est pas déjà le cas)
- RESET MASTER; sur le slave
- rsync de /var/lib/mysql slave vers master
- RESET MASTER; sur le slave
- —– A partir de là, MySQL ne sera accessible qu’en lecture seule —–
- FLUSH TABLES WITH READ LOCK; sur le slave
- rsync de /var/lib/mysql slave vers master
- SHOW MASTER STATUS; sur le slave (on copie le résultat)
- UNLOCK TABLES; sur le slave
- —– MySQL est à nouveau disponible en lecture/écriture —–
- Redémarrons MySQL sur le master
- —– A partir de là, MySQL ne sera accessible qu’en lecture seule —–
- FLUSH TABLES WITH READ LOCK; sur le slave
- CHANGE MASTER TO; sur le master
- START SLAVE; sur le master
- Attendre que le master soit arrivé à se synchroniser avec le slave
- Redémarrons Heartbeat sur le master (l’ip restera sur le slave)
- Stoppons Heartbeat sur le slave (l’ip basculera sur le master)
- —– MySQL est à nouveau disponible en lecture/écriture —–
- STOP SLAVE; sur le master
- RESET SLAVE; sur le master
- UNLOCK TABLES; sur le slave
- Stoppons MySQL sur le slave
Remette le slave en serveur de secours
Le slave va être re-synchronisé, puis reconfiguré comme slave, heartbeat sera
réactivé.
- —– MySQL fonctionne correctement, mais en mode dégradé —–
- RESET MASTER; sur le master
- rsync de /var/lib/mysql master vers slave
- RESET MASTER; sur le master
- —– A partir de là, MySQL ne sera accessible qu’en lecture seule —–
- FLUSH TABLES WITH READ LOCK; sur le master
- rsync de /var/lib/mysql master vers slave
- SHOW MASTER STATUS; sur le master (on copie le résultat)
- UNLOCK TABLES; sur le master
- —– MySQL est à nouveau disponible en lecture/écriture —–
- Redémarrons MySQL sur le slave
- CHANGE MASTER TO; sur le slave
- START SLAVE; sur le slave
- Attendre que le slave soit arrivé a se synchroniser avec le master
- Redémarrons Heartbeat sur le slave (l’ip restera sur le master)
Conclusion
Nous espérons que ce howto vous sera utile, même s’il ne répond
pas forcément à tous les besoins.
