Mon sentiment sur la réplication Galera

J’ai eu une conversation par mail il y a peu avec l’ami Cyril à propos de Galera replication.
C’est vrai que ce produit suscite un réel intérêt des acteurs de la communauté MySQL et j’aimerais modestement vous apporter mon sentiment sur ce produit et ses dérivés.

J’ai simplement eu l’occasion de tester ce produit dans le cadre d’un projet (en fait c’était XtraDB Cluster mais c’est presque la même chose).
Je n’ai pas une réelle expérience de production sur ce produit mais je vous livre ici ce que j’ai retenu de la prise en main du produit et des quelques tests que j’ai pu réaliser.

Galera replication, c’est quoi ?

C’est un système de réplication synchrone multi-masters. Tous les serveurs sont actifs en lectures et en écritures. Ce sont tous des maitres en quelque sorte.
Toutes les données sont néanmoins stockées sur chacun des serveurs, il s’agit en effet d’un système de type “share nothing” (Les données ne sont pas partagées).
Il s’agit en fait d’une librairie qui vient se greffer au noyau MySQL. Cette librairie est distribuée en open source.

A quoi ça sert ?

Les cas d’utilisation les plus courants sont les suivants :

  • Répartition de charge pour les lectures
  • Réplication master-master (écritures distribuées)
  • Système de haute disponibilité (à partir de 3 serveurs)

Quelles différences avec la réplication classique ?

  • Tous les noeuds sont des maitres indépendants, les écritures peuvent être faites depuis n’importe quel noeud
  • Il n’y a pas de notion de bascule master/slave en cas de problème puisqu’il n’y a que des maitres
  • La réplication des données est synchrone (enfin presque)
  • L’intégration de nouveaux noeuds est automatisée
  • La réplication se fait en parallèle (plusieurs threads dédiés à la réplication)

Comment l’implémenter ?

Je vous recommande vivement de passer par l’un des deux produits qui proposent une solution intégrée de Galera :

L’installation et la prise en main de ces produits est à mon avis plus simple que d’essayer d’implémenter soi-même la librairie dans le moteur MySQL standard.
Sachez que c’est relativement simple à installer, pour faire simple, ce n’est pas plus compliqué que d’installer un MySQL classique.

Bon, et alors, tu en as pensé quoi ?

La première chose sur laquelle je me suis jeté quand j’ai commencé à travailler avec le produit c’est la documentation.
La partie vers laquelle je me tourne en premier lieu, quel que soit le produit, ce sont les limitations.
Je vous recommande vivement de lire cette page avant d’aller plus loin avec le produit.
Les deux limitations les plus marquantes sont le seul support de InnoDB (pas de MyISAM) et quelques limitations concernant les “grosses” transactions.

Voici donc ce que je peux en dire :

  • Le coté synchrone mis en avant est à mon avis un peu exagéré car il ne s’agit pas réellement de réplication synchrone (on parle de “virtuellement synchrone“). Ce concept est d’ailleurs à l’origine des problèmes que l’on peut rencontrer avec certaines transactions
  • C’est très très très verbeux…
  • Il s’agit d’une alternative simple à implémenter si on a besoin de faire du master-master
  • Des outils existent pour le monitoring (Plugin Nagios par exemple) ainsi que pour l’installation
  • Je pense qu’on manque encore d’un peu de recul sur la techno mais ça commence à prendre depuis que MariaDB et Percona ont sorti leurs versions packagées
  • C’est un produit qui répond à un besoin complet, ce n’est pas forcement astucieux de partir sur cette solution uniquement si vous n’avez besoin que d’une partie des fonctionnalités. Par exemple, si votre besoin est simplement de basculer plus facilement du master vers un slave, MHA fait ça très bien.

J’espère que ces quelques retours pourront vous aider et si vous avez une expérience du produit, n’hésitez pas à la partager dans les commentaires.

Merci




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
  • http://www.blog.dev-art.fr Guillaume Dievart

    Super,

    merci pour l’article, cela fait quelques jours que des collègues me parle du couple XtraDB et Galera, ça m’en donne une meilleur vision.

    Ils doivent être mis en place d’ici quelques mois pour un site à fort trafic.

    Je ferai un retour sur leur expèrience, à moins que le Cyril dont tu parles est celui que je connais, dans ces cas là tu le saura peut ere avant moi :)

    • http://www.mysqlplus.fr Cédric PEINTRE

      Merci pour ce commentaire.
      Ton retour sera évidemment très bien venu.

  • http://lesdatabases.blogspot.fr Cyril Scetbon

    Merci pour ce post Cédric :) Effectivement Guillaume m’a reconnu ! Je rajouterai que la documentation est assez light ce qui est dommage car ça peut en révulser certains. Je vous ferai un retour sur les premiers tests que l’on aura pu faire et j’espère aussi voir l’intérêt d’utiliser un packaging plutôt qu’un autre (Percona Vs Maria), car en effet je ne vois pas l’intérêt de le packager nous même si c’est déjà fait.

    • http://www.mysqlplus.fr Cédric PEINTRE

      Ah ah ! tu es démasqué…
      Effectivement la doc n’est pas forcement à la hauteur mais il y a eu des slides de Percona qui expliquent l’installation basique pas à pas (http://www.percona.com/files/presentations/WEBINAR-percona-xtradb-cluster-installation-and-setup.pdf)
      Pour MariaDB Cluster, par contre, il semble que ce soit en Alpha pour le moment (pas réussi à trouver l’info pour XtraDB Cluster)
      Nous attendons donc ton retour avec impatience ;-)

  • http://cequisiedamichel.fr Michel

    Très intéressant. On aimerait bien quelques copies d’écrans.
    Effectivement, ‘pas de MyISAM’ est une limitation considérable.
    Est-ce au moins prévu dans un futur proche ?

    • http://www.mysqlplus.fr Cédric PEINTRE

      Merci pour le commentaire Michel.
      Des copies d’écran ? Il ne s’agit pas d’un outil graphique.
      Pour MyISAM je ne pense pas, une bonne occasion de migrer vers InnoDB :-)

  • Massimo Brignoli

    Well put Cedric!

    Sorry if write in english in your nice french blog :) but also if I speak french is easier for me to write in english.

    So first of all congratulations for your post clear and organized.
    I would like to add something:

    - The big advantage of Galera is that you don’t have any failover since the nodes are all active and equal so you need just a load balancer in front of them
    - Distributing the writes you can have same some aborted transactions depending on your application: typical example is when you do lot of updates of the same rows. This means the application must be modified to handle this situation.
    - In general Galera is a drop-in replacement being transparent for the applications (no need anymore for read-write splitting) unless you have to manage the aborted transactions as said before

    As you said perfectly, there are many reasons to use Galera, for scalability, for high availability or for both.

    To avoid problems with the distribution of writes in case of usage as simple HA solution, is possible to add on top a virtual ip, in this way you write to 1 node at a time.
    I know, this means to lose the main point, the absence of failover but on the other side you remove all the deadlocks problems.
    This can be done quite easily adding pacemaker on top with a custom resource agent.
    This is what we (at SkySQL) has decided to propose while we are waiting for MariaDB Galera Cluster to be GA.

    • http://www.mysqlplus.fr Cédric PEINTRE

      Hi Massimo, thx for this reply.
      What do you mean by “I know, this means to lose the main point, the absence of failover but on the other side you remove all the deadlocks problems” ?
      Thx

    • http://lesdatabases.blogspot.fr Cyril Scetbon

      Let’s start speaking english :)
      You understand that if we think about using Galera it’s not for using only one node for writes ! but maybe in your case it’s the right thing to do. If you know how to identify which data you’ll access, you could split your writes on the nodes depending on it. For example, you could say service 1 and 2 both access to marketing data and often the same data (same rows) and then redirect them to the same node, whereas you load balance others.
      I think Cedric did not understand what you meant cause you can use MHA to move “transparently” this ip between nodes in case of a failure.

      I’m hoping that load balancing writes on different nodes will allow us to make more writes (SQL is not redone on all nodes but only batch modifications are applied as I understood) even if I understand that it shouldn’t be a good solution to scale writes as they are made on all nodes and commits are synchronous.

  • http://lesdatabases.blogspot.fr Cyril Scetbon

    MyISAM est supporté depuis la version 5.5.23 de XtraDB Cluster (expérimental)
    voir http://www.codership.com/content/wsrep-patch-235-mysql-5523-released
    Mais effectivement je vote pour la migration vers InnoDB !

    • http://www.mysqlplus.fr Cédric PEINTRE

      Merci pour l’info.
      J’imagine qu’il est de toute façon plus sécurisant de partir sur du InnoDB pour ce genre de solution.
      Souvenez-vous des problèmes que l’on peut rencontrer avec la réplication classique et MyISAM…

  • http://www.expert-php.fr/ Pascal CESCATO

    Bonsoir – A la lecture de l’article, je vois que tout n’est pas rose, mais existe-t-il d’autres solutions simples et gratuites pour faire du master-master ? Après, que MyISAM soit supporté ou non, peu m’importe, il me semble pour l’avoir utilisé que le moteur InnoDB de Percona est très performant, au moins autant que le moteur MyISAM de MySQL… Enfin mes tests datent de la version 5.0.x donc ce n’est peut-être plus le cas aujourd’hui.

    • http://www.mysqlplus.fr Cédric PEINTRE

      Il y a toujours des limitations à une solution…
      Pour ce qui est de MyISAM, je trouve que ce n’est pas un frein énorme, mis à part dans des cas très spécifiques, il est à présent peu avantageux d’utiliser ce moteur.
      Ce n’est pas viable d’envisager une telle solution sans l’utilisation d’InnoDB (Que ce soit celui de Percona ou un autre)

  • http://dasini.net/blog/ Olivier

    Salut Cédric,
    Merci pour ce retour !
    Effectivement la réplication multi-master est une demande récurrente depuis plus d une décennie :)
    Tu as une estimation de l’impact sur les performances par rapport à la réplication classique ?

    Olivier encore en vacance ;)

    • http://www.mysqlplus.fr Cédric PEINTRE

      Que veux-tu dire concernant les performances ?
      Si tu parles des perfs de la réplication en elle même, c’est normalement plus performant mais il faut faire attention à la taille des transactions.
      Bonne fin de vacances amigo.