Flush Logs #8 : Pause estivale…

Il est grand temps pour moi d’aller voir si le soleil m’attend quelque part, une pause s’impose !
MySQL+ reprendra donc une activité normale d’ici quelques semaines, d’ici là, je vous invite à lire ou relire les articles les plus populaires :

Si le coeur vous en dit, n’hésitez pas à laisser un commentaire sur ces articles.

Si vous ne l’avez jamais fait, je vous propose de lire l’à propos de ce site : http://www.mysqlplus.fr/a-propos/

N’oubliez pas de me suivre également sur twitter, de vous abonnez au flux RSS ou par email.

Je n’ai plus qu’une seule chose à écrire : Bonnes vacances !

Flush Logs #7 : What’s up with MMM ?!

L’actualité MySQL et Oracle sélectionnée par MySQL+
Pour les news en temps réel, suivez-moi sur twitter

Vous pouvez également vous inscrire au flux RSS ou par email pour recevoir automatiquement une notification de publication des nouveaux articles

Un flush logs essentiellement consacré à MMM (multi-masters replication)

En effet, plusieurs acteurs importants de la mysqlsphère ont exprimé cette semaine leurs difficultés avec cet outil remettant même en cause une utilisation possible en production.

J’avais moi même exprimé il y a quelques temps mon sentiment sur cet outil : Pourquoi-mmm-ne-fait-pas-ce-que-jaimerais-quil-fasse/

Les réactions à ces articles sont diverses et variées mais ce soudain intérêt pour cet outil est à mon avis révélateur d’une tendance à vouloir aller plus loin avec MySQL aujourd’hui.
En effet, la réplication est très utilisée avec MySQL et les outils permettant de rendre transparent la promotion d’un slave en master sont rares et parfois peu fiables. Le fait est que chacun a finalement pris le pli de développer ses propres outils ou d’écrire des procédures de promotion manuelle.

Je dis que c’est révélateur d’un changement de comportement mais également de la façon dont on utilise désormais MySQL pour des projets de plus en plus critiques en production. Il est donc normal de se heurter aux mêmes difficultés que l’on a pu rencontrer avec les autres SGBD et de tenter de trouver des solutions plus ou moins pertinentes.

La seule chose qui reste un peu flou après la lecture de ces articles est de savoir quelles solutions pertinentes mettre en oeuvre pour faire du multi-masters ?
Finalement, j’ai tendance à penser que pour l’instant, la réplication MySQL n’est pas conçue pour ça, au moins jusqu’à la version 5.1 (Des améliorations significatives arrivent en 5.5 et 5.6 pour la réplication).

Il faut donc peut-être se poser la question différemment : Est-il raisonnable de faire du multi-masters avec la réplication MySQL aujourd’hui ?

Je n’ai pas de réponse définitive à cette question et vous laisse vous faire votre propre opinion à travers les différents articles publiés dernièrement sur le sujet :
( Lisez aussi les commentaires, ils sont également très intéressants )

Pour le reste de l’actualité MySQL, j’ai selectionné les news suivantes pour cette semaine (on reste un peu dans le monde de la réplication) :

C’est tout pour cette semaine. N’hésitez pas à partager vos expériences sur MMM !

Pourquoi MMM ne fait pas ce que j’aimerais qu’il fasse ?!

Dans le cadre d’une réplication avec plusieurs esclaves et un seul maitre, ce dernier devient vite le point faible de votre architecture.
C’est pourquoi, une solution comme MMM, qui permet de gérer plusieurs maitres en actif/passif peut paraître séduisante mais c’est sans compter sur ses limitations.

Je fais un petit rappel de l’outil pour ceux qui n’ont jamais plongé le nez dans ce type d’architecture.
MMM est un ensemble de scripts perl permettant de gérer et de contrôler la bascule d’un maitre à un autre dans le cadre d’une réplication de type multi-master.

Je ne vais pas entrer ici dans les détails de la mise en oeuvre de ces outils, vous trouverez toutes ces informations ici : http://mysql-mmm.org/start
(La documentation est somme toute assez sommaire et incomplète, des connaissances de la réplication MySQL sont nécessaires)

Ce que fait MMM dans une architecture multi-master

Dans une architecture classique, un seul maitre joue le rôle de point d’entrée pour les écritures :

Ici, si le maitre est défaillant, il est possible de promouvoir un esclave en maitre manuellement. Attention, toutefois, il est nécessaire d’avoir une configuration adaptée pour cela : http://dev.mysql.com/doc/refman/5.1/en/replication-solutions-switch.html
Mais pendant ces opérations, toutes les écritures de vos applications sont en attentes.

Les outils MMM vous promettent une gestion simplifée pour basculer d’un maitre à un autre, voire même d’un maitre vers un esclave pour les écritures :

Pour cela, vous devez avoir configuré une architecture de type master-master, soit, une réplication circulaire entre deux serveurs. Les deux maitres ne sont pas utilisés simultanément, il y a un maitre actif et un maitre passif.
En cas de défaillance d’un des maitres, le maitre passif prend automatiquement le relais pour les écritures.
En cas de défaillance d’un des slaves, les flux de lecture sont redirigés vers les slaves restants.

Ce que MMM ne fait pas (et que j’aimerais qu’il fasse)

Le hic, avec MMM, est qu’il lui manque une fonctionnalité de taille qui, à mon sens, limite son utilisation.
En effet, c’est une très bonne solution lorsque votre architecture n’est composée que de deux maitres, sans esclave, en mode actif/passif. Le maitre actif supporte les écritures et le maitre passif les lectures.
Dans ce cas, vous pouvez basculer volontairement d’un maitre à l’autre sans aucun problème.
De même, en cas de défaillance du maitre actif, le maitre passif prend le relais pour les écritures et lectures.

Ca se complique lorsque l’architecture ressemble à celle présentée plus haut, deux maitres actif/passif et un ou plusieurs esclaves.
Dans la réplication MySQL, un esclave ne peut avoir qu’un seul maitre. Ici, le maitre de tous les esclaves est donc le maitre actif.
Dans ce cas,  lors de la bascule vers le maitre passif, les esclaves ne peuvent plus joindre leur maitre, les réplications s’arrêtent. Les esclaves ne servent donc plus à rien, les écritures et les lectures sont toutes redirigées vers le maitre passif qui a pris la main.

En effet, MMM ne dirigera pas les esclaves vers le nouveau maitre.
Pire encore, comme il s’agit d’une réplication circulaire, la présence du paramètre log_slave_update=1 sur les deux maitres, vous empêchera de promouvoir sereinement votre maitre passif en nouveau maitre pour vos esclaves.

Ma conclusion

Ces réflexions sont issues de tests que j’ai réalisé à partir de la configuration standard de MMM.
Je pense qu’il est possible de mettre en oeuvre une architecture plus complexe avec quelques bidouilles sur lesquelles je ne me suis pas penché.

Néanmoins, je ne peux vous recommander de partir avec un tel produit si votre architecture cible ressemble à celle évoquée plus haut (2 masters + n slaves).
En effet, vous risquez de dépenser beaucoup d’énergie pour adapter MMM à vos besoins alors qu’une procédure de promotion manuelle correctement rédigée et testée sera certainement la meilleure solution.

Pour une architecture ne comprenant que deux serveurs maitres, ces outils peuvent vous apporter satisfaction.
Juste une petite réserve quand à la documentation très légère  et aux mises à jour peu régulières.

Comme d’habitude, n’hésitez pas à me faire un retour si vous utilisez cet outil ou si vous avez des questions.
Cédric.