Haute disponibilité (Hight Availability – HA) en Mysql – Quelles possibilités ?

Il n’y a actuellement pas sur le marché de solution de HA Mysql qui s’impose par rapport aux autres.
Les différentes solutions ont chacune leur avantages, limites et inconvénients.

Dans le cadre de la définition de l'architecture serveur pour le site qu'on réalise pour un de nos clients, à savoir une plateforme Drupal 7, j'ai eu à essayer d'évaluer les différentes solutions de haute disponibilité pour Mysql.

N.B. : Plus l'architecture technique et lourde, plus il y aura de problèmes potentiels et donc vouloir à tout prix faire de la haute disponibilité contient un risque de faire baisser la disponibilité si ce n'est pas maitrisé de bout en bout. Avant toute chose il est donc souhaitable de se poser la question de la réelle nécessité d'une architecture HA.

Différentes solutions de Hight Availability

Sans être exhaustif on peut citer les solutions suivantes.

Heartbeat/DRDB

C'est au niveau système de fichier que se fait la réplication entre les nœuds.

Ressources :

Contraintes :

Mysql Cluster

Incompatible avec Drupal (Impose un moteur de stockage particulier)

XtraDB Cluster

Limitations le rendant incompatible avec Drupal (Ne supporte pas les instructions LOCK)

MariaDB Galera Cluster

A propos de Maria DB : https://mariadb.org/ , http://fr.slideshare.net/bytebot/why-mariadb
A propos de Galera : https://kb.askmonty.org/en/galera/, http://codership.com/content/using-galera-cluster

Ressources traitant de l'implémentation de Galera Cluster avec Drupal :

Contraintes :

  • Relativement lourd de mise en œuvre
  • Jeunesse de la solution et donc manque de retour sur expérience
  • MariaDB est un fork de Mysql et par conséquent la pérennité de la solution à horizon 5 ou 10 ans n’est pas aussi garantie que celle de Mysql édité par Oracle.

Mysql-MMM : Multi-Master Replication Manager for Mysql

http://mysql-mmm.org/
Solution utilisable à partir de Mysql et non à partir d’un fork de Mysql
Relativement simple de mise en œuvre et n’apporte que peu de limitations au niveau applicatif.
Critiqué car limité dans son architecture même : http://www.xaprb.com/blog/2011/05/04/whats-wrong-with-mmm/
Le failover (bascule automatique en cas de défaillance du master) n’offre pas suffisamment de garanties pour pouvoir être utilisé. Il vaut donc mieux la désactiver et faire la bascule à la main.

Mysql5.6 (horizon 2014)

Les futures avancées de MySql5.6 (cf http://planet.mysql.com/entry/?id=30209 ) , permettront à Mysql d’assurer du failover en master master en natif.

Conclusions

État des lieux

Il n’y a actuellement pas sur le marché de solution de HA Mysql qui s’impose par rapport aux autres.
Les différentes solutions ont chacune leur avantages, limites et inconvénients.
Le document http://openlife.cc/system/files/Evaluating%20HA%20alternatives%20MySQL%20tutorial2.pdf représente bien la complexité de la question.

Des réflexions de fond sur le clustering Mysql sont également disponible :

Quelle solution retenir ?

Si on peut se passer de la bascule auto en cas de défaillance du master, c'est à dire si un taux de disponibilité de 99.9 % est suffisant alors j’aurai tendance à préconiser du MMM.
Si on souhaite aller au-delà de 99.9 % de disponibilité alors MariaDB Galera Cluster semble la solution de choix.
Les futurs apports de Mysql 5.6 vont rebattre les cartes et on devrait voir apparaitre en natif des solutions de clustering plus simple à mettre en œuvre et reposant sur des mécanismes natif à mysql.

D’ici à 2014, soit MariaDB Galera Cluster se sera imposé comme étant LA solution de HA Mysql, soit Mysql 5.6 comblera suffisamment ses manques et la question ne se posera plus ou du moins pas dans les mêmes termes.

2 commentaires

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.