Bonjour à tous,
j'ai réalisé plusieurs configurations de test pour un cluster MariaDB avec Galera en utilisant la dernière release stable de MariaDB (10.2), avec HAProxy pour gérer la répartition de charge sur les 3 nodes de mon cluster.
Pour la synchronisation, j'utilise actuellement rsync mais je n'ai pas testé xtrabackup avec Galera, avez déjà pu comparer les deux solutions ?
Je souhaitais également avoir vos avis sur Galera par rapport à une solution comme Percona cluster avec MySQL ou XtraDB Cluster avec MariaDB ?
Merci d'avance
Perso le seul cluster MySQL que j'ai monté c'est avec Mariadb 10.1 et Galera.
Il tourne sur 3 VM en permanence et parfois en cas de pic on monte à 9 nodes.
Il a absorbé jusqu'à 15k visiteurs simultanément en pic.
La répartition se faisant par l'IP LB NextGen d'OVH le tout derrière CloudFlare.
Le point important étant qu'il faut impérativement être sur des tables InnoDB.
Mais sinon c'est vraiment très stable, l'ajout / suppression de nodes est très simple.
A part dire que "ça marche" je n'ai pas plus de bench que ça.
Le point important étant qu'il faut impérativement être sur des tables InnoDB.
Mais sinon c'est vraiment très stable, l'ajout / suppression de nodes est très simple.
D'accord merci @Sich. Oui j'avais effectivement remarqué que toutes les solutions de clustering MySQL/MariaDB ne supportent que InnodDB, j'ai déjà un cluster Galera avec 3 nodes en production pour une WordPress avec 75k visiteurs/ jour. La répartition de charge se fait extrêmement bien avec Haproxy et le script https://github.com/olafz/percona-clustercheck/ clustercheck pour détecter l'état des nodes.
Je souhaiterais déployer une solution similaire pour un Multi-store Magento, car la charge est relativement importante lors de l'index des produits, mais Magento 2.1 semble supporter difficilement la réplication notamment pour les Index. Donc j'ai voulu savoir si vous aviez testé les autres solutions de clustering comme Percona.
Bonjour,
Le sujet m'intéresse, ceci dit, je suis assez frileux car j'ai beaucoup moins de recul. Du coup, sur le cas d'utilisation en cours, j'ai plusieurs questions à vous soumettre :
* Comment agrandir le cluster à chaud ? Xtrabackup ? (le reste entrainant un read lock)
* Mes données sont déjà sur le serveur MariaDB. Problématique ?
* Ce noeud MariaDB est actuellement un slave d'un autre MySQL, avant de migrer définitivement, sans coupure. Est-ce qu'un cluster Galera peut-être un slave d'un autre serveur MySQL ? (oui, configuration tordue)
Accessoirement, j'ai des procédures de sauvegarde / restauration HYPER rodées qui font que je me pose la question de savoir si je peux conserver les mêmes éléments ou s'il faut tout réinventer et tout revalider en termes de cohérence, intégrité… (oui, je sais, je suis un psychopathe de l'intégrité des données)
- Agrandir un cluster à chaud : Il suffit de connecter un nouveau serveur… La synchro se fait automatiquement avec les données présentes dans le cluster. Cela va écraser les données sur le nouvel arrivant.
- Il est préférable de partir sur une "fresh install" d'un cluster puis de restaurer la bdd… Perso je monterai un cluster à côté puis j'y enverrai la bdd… Même si je pense qu'il est possible de configurer le serveur mysql en mode galera puis d'y ajouter d'autres noeuds… Mais bidouiller sur un serveur en prod c'est assez moyen, perso je ne m'y lancerai pas.
- Je ne pense pas que l'on puisse avoir un noeud qui soit à la fois maitre dans un cluster multi maitre, et slave d'une autre instance en même temps… C'est peut être faisable, à tester, mais encore là je ne jouerai pas ça en prod perso…
Pour les backups pas de soucis particulier, chaque serveur se comporte comme n'importe quel serveur mysql… Si ce n'est qu'il n'y a pas de cache et qu'on tourne sur du 100% innodb…
Me revoila ! J'ai fait quelques tests…
Venant de MySQL 5.1, j'ai de gros problèmes de performance lorsque je passe à MariaDB. Je suis en train d'investiguer, mais en même temps, je dois avancer sur la configuration Galera.
Le cas de test que j'ai est assez brutal: j'insère 2 millions de lignes en auto_increment insert into matable values(),();
J'ai 4 VM à dispo :
* MariaDB 10.2
* 4 vCPUs
* 4 Go de RAM
* Disques SSD
* Configuration quasi identique (la partie wsrep en moins pour le standalone)
Sur le standalone, ça donne ce genre de choses : # time mysql test < insert.sql<br /><br />real 1m32,047s<br />user 0m4,524s<br />sys 0m6,396s
Sur le cluster Galera, pour 1 148 000 lignes, j'ai : real 94m30,695s<br />user 0m4,064s<br />sys 0m3,196s
En gros… Inexploitable… Les machines ne sont quasiment pas utilisées au niveau CPU / RAM / Disques.
Par contre, si je passe tout dans une transaction unique : # time mysql test < transaction.sql<br /><br />real 1m40,035s<br />user 0m4,012s<br />sys 0m7,620s
Des idées sur le tuning à faire pour que ça utilise réellement les ressources à disposition même si je n'ai pas de transactions ?
quel est le lien entre les serveurs ? Ne pas oublier qu'en cas de cluster il faut que tout soit synchronisé sur toutes les nodes… Du coup il me semble que ça lock tant que l'enregistrement n'est pas fait partout… On est pas dans du master/slave là.
Merci Sich, finalement, j'ai compris d'où ça venait.
Le cluster Galera est réparti sur deux PCC à Roubaix et Strasbourg…
Un mtr donne la réponse : Loss% Snt Last Avg Best Wrst StDev<br /> 0.0% 1000 9.3 9.2 9.2 10.0 0.0
A chaque transaction, je prends près de 10ms dans la vue.
Donc, sur 1 millions de transactions, ça donne 2h40 de délai !!!
D'où l'écart entre la transaction unique et la version avec 1 million de requêtes.
> mais Magento 2.1 semble supporter difficilement la réplication notamment pour les Index
En fait, ce n'est pas tellement la réplication qui le gêne mais Galera. Galera entraîne tout un lot de limitations. Il y a en effet un gros travail d'indexation à refaire sur la base de données de Magento, pour pouvoir la basculer intégralement en InnoDB, puis sous Galera (clés primaires explicites partout).
D'autant plus que ce travail ne sera pas pérenne dans le temps, la moindre mise à jour du schéma risque de casser le travail réalisé.
Si tu as un support commercial pour Magento, peut-être leur soumettre la question ?
Sinon, l'idée d'une réplication semi-synchrone avec une répartition des requêtes permettrait au moins d'avoir une scalabilité sur les lectures.
Pour scaler en lecture il faut éventuellement partir sur du master slave avec un proxysql au milieu qui va répartir les requêtes entre l'écriture sur le master et les read sur les différents slave, le tout en ajoutant une petite couche de cache…
Mais pour gérer de façon fine le cache avec proxysql cela demande pas mal de boulot pour étudier quelles requêtes peuvent être mise en cache quelques minutes et les autres… Proxysql basant son cache sur du TTL sans réelle solution d'invalidation du cache. Même si je crois que sur la 4.1 on peut changer le TTL d'une règle et cela va invalider le cache… Mais ce n'est pas encore une version stable.
En parlant de ProxySQL… J'ai fait quelques tests sur mon cluster de 3VM. C'est vraiment une solution superbe. Le scheduler avec le petit script pour gérer l'invalidation d'un noeud est juste parfait. Les premiers tests que j'ai réalisés sont vraiment prometteurs.
Dans beaucoup d'exemples, ils séparent les hôtes en écriture de ceux en lecture dans des hostgroups différents. Il y a une raison à ça ? (hormis l'habitude master-slave qui l'imposait)
Deuxième point : sur la version 1.3.7 (la 1.4 n'est pas encore dispo dans les repo Percona pour Debian), j'ai un comportement "bizarre". Toujours sur mon insertion de 2 millions de lignes, ProxySQL semble ignorer mon "start transaction" / "commit" contenu dans mon fichier SQL. J'ai regardé rapidement dans global_variables, mais n'ai rien trouvé de vraiment pertinent en la matière.
Vous avez aussi ce genre de comportements ?
Pour le moment sur proxysql je n'en suis qu'aux tests assez simple.
Mon but à moi c'est surtout de faire du cache local pour un serveur SQL distant. Avec peut être par la suite localement un slave sur lequel envoyer les SELECT.
Mais la 1.4.1 vient de passer stable avec des .deb de Debian 7 à 9.
Je crois qu'il y'a des changements sur ces questions de transactions / commit justement sur la 1.4
https://github.com/sysown/proxysql/releases/tag/v1.4.1
Pour la question des hostgroups c'est pour pouvoir répartir les requêtes oui, mais il est possible d'avoir un serveur dans plusieurs hostgroups il me semble.
Du coup il est tout à fait possible de faire un hostgroup pour le MASTER, et un hostgroup pour les slaves avec le master dedans.
Avec ça il est possible d'envoyer toutes les requêtes sur le master, sauf celles de notre choix vers le 2° hostgroup qui ne fait que du select.
Il y'a un exemple ici pour les read/write split : http://www.proxysql.com/blog/configure-read-write-split
ProxySQL peut servir à bcp de choses différentes, que ce soit du loadbalancing entre plusieurs slaves, rewrite de query, cache, etc… C'est vraiment un outil intéressant, mais on a pas forcément besoin de toutes les fonctionnalités…
En tout cas je pense que ça doit permettre de mieux monter en charge en absorbant une partie des requests grâce au cache.
Parfait, je ferai la mise à jour la semaine prochaine et ferai des retours.
Je préfère ProxySQL dans sa conception que HAProxy qui ignore complètement la partie applicative. Ca répartit bien la charge en temps normal, mais je doute que HAProxy soit en mesure de gérer la reconstruction d'un noeud (et donc l'éviction du donneur du pool des serveurs à requêter)
J'attends aussi impatiemment MariaDB 10.2.8 (la 10.2.7 ne sortira pas en package pour Stretch), je suis concerné par un bug dans la 10.2.6…
(font quand même chier à rendre mon travail obsolète en moins de 24h ! 
)