Hello, Yep maxscale j'ai aimé, mais a partir de la V2, ils ont rendu le produit payant .. Sinon j'en profite pour donner des infos:
Management cluster MySQL like, postgres, mongo = clustercontrol de severalnines Percona fait également un bon boulot : cluster mysql + galera + proxysql et supervision via prometheus / grafana = 1/2 clustercontrol opensource :) Expert Mysql + Infogérance = OCEANDBA <https://www.oceandba.fr/> Cdt, Ronan Le jeu. 17 sept. 2020 à 11:02, Pierre DOLIDON <sn...@sn4ky.net> a écrit : > 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> 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. >> 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> a écrit : >> >>> Le ven. 26 juin 2020 à 09:15, <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 FRsAGhttp://www.frsag.org/ > > > _______________________________________________ > Liste de diffusion du FRsAG > http://www.frsag.org/ > -- Ronan DUCAMP
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
