[FRsAG] Retours sur galera cluster mariadb

open doc linuxopendoc at gmail.com
Ven 10 Juil 18:52:40 CEST 2020


Hello, je viens de faire quelques tests.
avec HAProxy on peut piloter l'intégration du node via un jeux de question
réponse (clairement inspiré des redis sentinel)

---
        option          tcp-check
        tcp-check       connect
        tcp-check       send local_state\r\n
        tcp-check       expect string wsrep_local_state_comment Synced
        tcp-check       send ready\r\n
        tcp-check       expect string wsrep_ready ON
        tcp-check       send quit\r\n
        tcp-check       expect string bye
---

Si tout est validé le node est intégré.
C'est un petit script avec du xinet que l'on peut appeler en telnet

---
telnet verstestgalera03 3201
Trying X.X.X.X...
Connected to verstestgalera03.xxxxxxxxx.fr.
Escape character is '^]'.
h
option not found
h           : help
local_state : shows the node state in a human readable format
ready       : Whether the server is ready to accept queries
local_state
wsrep_local_state_comment Synced
ready
wsrep_ready ON
quit
bye
Connection closed by foreign host
---

Sur la partie écriture on peut écrire sur un node, et écrire sur un autre
si le premier est down avec la notion de backup dans HAProxy
Effectivement, j'ai bien le décalage dans les auto increment et ca c'est
pas génial, mais on peut le bypasser

---
[galera]
wsrep_auto_increment_control=OFF

[mysqld]
auto_increment_increment = 1
auto_increment_offset = 1
---

J'ai fait plus 40 000 inserts avec 16 écritures simultanées sur des tables
avec des auto increment tout en testant un changement de master, je n'ai
pas eu de décalage.
je vais continuer les tests.

Avez vous d'autres situations ou le galera cluster n'est pas adapté ?

Alex


Le ven. 26 juin 2020 à 23:21, Jonathan Leroy - Inikup via FRsAG <
frsag at frsag.org> a écrit :

> Le ven. 26 juin 2020 à 09:15, <frsag at jack.fr.eu.org> a écrit :
> > 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
>
> Je ne compterai pas ça comme un point négatif. C'est clair et
> documenté : les auto-incréments ne doivent pas êtres utilisés dans des
> cas ou la numérotation doit être consécutive (typiquement les numéros
> de facture en France). Avec ou sans Galera, il y a un dizaine de
> raisons qui font qu'il peut y avoir un trou dans les ID en
> AUTO_INCREMENT (transaction annulée, INSERT IGNORE...).
>
> Malheureusement la plupart des dev ne le comprennent pas, donc on est
> obligés de trouver des solutions en catastrophe quand la compta se
> rend compte qu'ils vont avoir de gros problèmes avec les impôts.
>
>
> > 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)
>
> C'est un peu le cas de toutes les solutions de HA : ajout de machines
> = archi plus complexe.
>
> Mais c'est particulièrement vrai sur les SGBD pour lesquels ça ne
> pardonne pas. J'ai eu quelques fois à fusionner les données de tables
> après un split-brain MySQL, je m'en souviens encore. (:
>
> Il y a quelques années les équipes de GitHub ont décidées de redonder
> complètement leurs archis physique *et* logicielle : tout a été doublé
> niveau hardware (serveurs, switchs, routeurs...) et niveau soft (infra
> MySQL complexe).
> Dans l'année qui a suivie, le nombre de panne du service a été
> extrêmement important, parfois plusieurs par semaines, alors que les
> années précédentes il n'y avait eu que très peu d'incidents. Bref, la
> HA c'est compliqué.
>
> Donc la question à se poser est : est-ce absolument nécessaire ? Si
> c'est juste une question de disponibilité, la réponse est rarement
> oui, sauf si les sommes en jeu ne permettent pas 5-10 minutes
> d'indispo toutes les X semaines.
> Si c'est une question de charge c'est sûrement oui, mais ça ne se fera
> pas sans adapter l'application. Et ça peut être du coup une occasion
> de passer sur des technos plus adaptées.
>
> --
> Jonathan Leroy
> _______________________________________________
> Liste de diffusion du FRsAG
> http://www.frsag.org/
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://www.frsag.org/pipermail/frsag/attachments/20200710/802fd3e6/attachment.htm>


Plus d'informations sur la liste de diffusion FRsAG