Merci beaucoup pour ton retour. Effectivement, tu soulèves des points très importants et j'en prend note. Je t'avouerai que je suis TRES haproxy, et comme tu le disais, mon appli sait géré le R/W sur des ports différents, cela peut nous convenir. Je vais maquetter pour me faire la main sur Galera.

Merci à tous pour vos retours, très intéressants et de qualités (comme d'habitude).

Alex

Le jeu. 25 juin 2020 à 09:15, Michel Blanc <mblanc.networks@gmail.com> a écrit :
Le 24/06/2020 à 21:48, open doc a écrit :
> Bonjour,
>
> nous devons updater notre vieux cluster master/slaves en mariadb. On
> étudie la possibilité d'intégrer galera cluster mariadb. J'aurai aimé
> avoir quelques retours sur la techno. En êtes-vous satisfait ? il y a
> t'il des choses sur lesquels il faut absolument faire attention ?

TL;DR: je ne mettrai du galera aujourd'hui uniquement en cas de
problèmes de performances en lecture sur un workload avec un
r/w ratio > 99%


C'est assez difficile de répondre sans connaître ton besoin ni les
motivations sur Galera.

En complément des réponses précédentes:

Galera a un mécanisme de "certification" des transactions: avant chaque
write, il va aller causer à tous les noeuds du cluster pour voir s'ils
sont d'accord pour exécuter ce write; en cas de souci ton write va
échouer; donc le RTT entre chaque noeud conditionne directement tes
performances en write (donc au final un impact majeur en perfs sur les
writes).

Pour éviter un échec des transactions, la technique habituelle est de
write sur un seul noeud; et là, problème. Soit ton application est
intelligente et sait faire elle même le R/W splitting, soit tu dois
mettre un proxy qui parle MySQL au milieu (haproxy ne suffit pas, tu
peux effectivement faire un front end "read" et un autre "write", mais
il ne peut pas décider seul ce qui est un read et ce qui est un write).

ProxySQL sait bien faire ça, mais ça n'est pas trivial à mettre en œuvre
correctement, notamment en cluster. Et si tu n'as qu'une instance de
loadbalancer, tu as seulement déplacé ton SPOF.

Chez nous on posait en général un ProxySQL (pas en cluster, indépendant)
sur chaque frontal et les apps pointaient localement sur ce proxy.

Maintenant, avec le recul (et dans notre contexte), je trouve que
l'impact en perfs de Galera et toute la machinerie annexe nécessaire
pour que ça marche bien (r/w splitting, failover, ...) vaut rarement le
coup. C'est intéressant si tu as un workload *très fortement READ*
(genre > 99%). Et même dans ce cas, c'est probablement aussi bien de
partir sur un setup primary/replica normal avec une bonne procédure de
failover et des LB au milieu.

Par ailleurs ça nous a rarement sorti le cul des ronces en prod (plutôt
l'inverse). On a parfois pu switcher des applis sur un autre noeud à
cause d'un souci, mais on est pas sur que ce souci n'ait pas été causé
par Galera en premier lieu.

Pour décider, tu as probablement intérêt à monter une maquette et
rejouer des slow querylogs de ton infra actuelle dessus pour voir ce que
ça donne, et te familiariser avec les procédures de recovery (bootstrap
de cluster, grastate.dat, etc...) avant de plonger dedans.


Bonne chance
---
M

_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/