Bonjour
j'eusse mis en prod du MaxScale aussi pour ce genre de cas. ça marche
plutôt pas trop mal (c'est un truc de chez MariaDB).
Le 16/09/2020 à 14:36, Ronan Ducamp a écrit :
Hello,
Je plussoie fortement ProxySQL ! Eviter le mode RW/Split from scratch
si l'application ne supporte pas les staleread, ça a beau être de la
répli synchrone sur le papier en réalité ça ne l'est pas.
Custom ProxySQL pour répartir les querys en fonction du besoin est
beaucoup mieux, sharding and co ..
HaProxy c'est bien quand ton application sait splitter, sinon bof a
part pour faire du failover.
Pour les cas d'usage, en interne on c'est mis la barre à 5% de write
maximum... Bien entendu, on est loin d'avoir un load de milliers de
query/s xD
Sinon il y a repmgr <https://signal18.io/products/srm> de signal18
pour garder un semblant de cluster :) ça fait le boulot chez des
grands noms avec un gros workload.
Ronan
Le ven. 10 juil. 2020 à 18:54, open doc <linuxopen...@gmail.com
<mailto:linuxopen...@gmail.com>> a écrit :
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
<http://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@frsag.org <mailto:frsag@frsag.org>> a écrit :
Le ven. 26 juin 2020 à 09:15, <fr...@jack.fr.eu.org
<mailto:fr...@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/
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
--
Ronan DUCAMP
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
