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.




Share the love!

Inscrirez vous au flux RSS ou par email pour recevoir automatiquement et en temps réel une notification de publication des nouveaux articles.

Oracle, MySQL, and InnoDB are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners