[FRsAG] Retours sur galera cluster mariadb

frsag at jack.fr.eu.org frsag at jack.fr.eu.org
Ven 26 Juin 09:13:36 CEST 2020


o/

Je valide

Galera n'est pas un drop-in replacement à un mariadb standalone, la 
coopération du client est recommandée, voir nécessaire

Par exemple, un truc bien reloud : la modification des schémas
Au moins avec galera3, tu ne peux sainement faire un alter table sans 
rekt ta base complétement, tu dois utiliser un outil comme 
pt-online-schema-change

Je passe sur la gestion des clef primaires
Oui, rien ne dit que les auto_increment sont incrémentés de 1 à 1
Et oui, certains dev qualitatifs se basent sur le fait que c'est le cas, 
et s'étonnent ensuite que les numéros de facture vont de 3 en 3 sur un 
cluster galera

À noter également que galera coute très cher: 3x le dataset en stockage, 
supposement des capacités hardware équivalentes également

Enfin, des problèmes liés au setup, j'en ai eu plein
En revanche, des problèmes évités grace au setup, beaucoup moins (c'est 
subjectif, naturellement)

Bref, en conclusion, je pense que Galera est une solution qui est adapté 
à un cas de niche, mais en aucun cas à une utilisation généraliste

Cordialement,

On 6/25/20 9:08 AM, Michel Blanc wrote:
> 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/
> 


-- 
"UNIX was not designed to stop its users from doing stupid things, as 
that would also stop them from doing clever things." – Doug Gwyn


Plus d'informations sur la liste de diffusion FRsAG