MySQL Cluster : c’est pas encore prêt pour tous
Récemment au taf je me suis lancé dans la conception d’une architecture MySQL solide. Des applications internes critiques se basent dessus et suite à un soucis j’ai réalisé le manque de fiabilité de l’existant. Après quelques recherches j’ai donc commencé à mettre en place un cluster MySQL.
Cette solution présente pas mal de choses attrayantes, notamment son système de haute dispo “intégrée” qui il faut le dire, fonctionne très bien : j’ai coupé le courant d’un des noeuds comme un sauvage (IPMI <3) et la bascule s’est faite instantanément, sans perte de données. L’administration via la console de management est assez aisée (y’a pas de clicka mais OSEF), bref jusque là : tout va bien.
Ca se corse quand on commence à faire des vraies opérations sur les bases, style :
ALTER TABLE bla ENGINE=ndbcluster
… quand la table fait 1.5Go le moteur souffre, la RAM aussi. Et oui, MySQL Cluster fonctionne en RAM (entièrement !), et ça aussi ça fait un peu peur. Il y a des écritures régulières, mais c’est pas tip top, sauf pour ce qui est des perfs, qui déboitent quand même bien leur maman ours en guenilles. La liste complète des limitations est bien sur disponible, et perso je trouve que c’est trop contraignant pour être vraiment utilisable en environnement de production.
Néanmoins, je ne jette pas la pierre et je garde un oeil sur cette solution qui si elle continue sur la bonne voie sera sûrement utilisable chez moi d’ici 3/4 versions.