Retours sur galera cluster mariadb
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 ? Merci pour vos retours. Alexandre
Bonjour, nous avons quelques clusters MariaDB en prod, et nous en sommes satisfaits oui. Maintenant ce n'est pas parfait, en vrac : - sur du WAN, attention à la latence d'écriture qui augmente fortement avec le débit - sur du WAN toujours, bien ajusté les timeouts, sous peine de catastrophe - si l'applicatif ne gère pas la reprise des transactions en cas de deadlock, il est préférable d'essayer d'aiguiller les écritures sur un seul noeud à la fois - la réplication asynchrone, depuis un cluster Galera vers un slave/replica "classique" n'est pas officiellement supportée avant MariaDB 10.5.x (en vrai ça fonctionne, tant que tu n'écris que sur un noeud à la fois, au delà c'est risqué) Olivier PS: ton mail était en SPAM chez moi, à cause d'une erreur de signature DKIM.
Authentication-Results: gmail.com (fail); signature_incorrect
Le mercredi 24 juin 2020 à 21:48 +0200, open doc a écrit :
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 ?
Bonjour, J'avais mis en place cette solution pour héberger des Wordpress notamment, à l'époque j'avais dû passer par des bidouillages et j'avais pas mal ramé avec Galera :) car le produit n'était pas encore bien mature : J'ai observé les mêmes problèmes de latence voire de dead-lock cités pour des applis comme Moodle et Wordpress lors de multiples accès concurrentiels sur 3 nœuds actifs, peut-être aussi dus à des problèmes en dehors du logiciel (glusterFS), mais j'avais dû finalement avec HAProxy en frontal diriger les requêtes sur un noeud "principal" pour conserver le secondaire et le troisième en "backup" (au sens HAProxy - car pour Galera cluster ils sont tous actifs). Maintenant il est probable qu'une implantation récente de chez Mariadb doit mieux fonctionner, le produit évoluait souvent et j'ai pas opté pour une ré-installation "from scatch" depuis. -- Cordialement / Best regards, Michaël Couren, ABES, Montpellier, France.
Bonjour, En effet il est conseillé d’écrire sur un seul des noeuds du cluster. L’approche avec un HaP pour faire le R/W Splitting est une bonne solution. Cdlt. Nicolas Girardi.
Le 25 juin 2020 à 08:12, Michaël Couren <couren@abes.fr> a écrit :
Bonjour, J'avais mis en place cette solution pour héberger des Wordpress notamment, à l'époque j'avais dû passer par des bidouillages et j'avais pas mal ramé avec Galera :) car le produit n'était pas encore bien mature : J'ai observé les mêmes problèmes de latence voire de dead-lock cités pour des applis comme Moodle et Wordpress lors de multiples accès concurrentiels sur 3 nœuds actifs, peut-être aussi dus à des problèmes en dehors du logiciel (glusterFS), mais j'avais dû finalement avec HAProxy en frontal diriger les requêtes sur un noeud "principal" pour conserver le secondaire et le troisième en "backup" (au sens HAProxy - car pour Galera cluster ils sont tous actifs).
Maintenant il est probable qu'une implantation récente de chez Mariadb doit mieux fonctionner, le produit évoluait souvent et j'ai pas opté pour une ré-installation "from scatch" depuis.
-- Cordialement / Best regards, Michaël Couren, ABES, Montpellier, France. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Est-ce qu'il existe un équivalent au MySQL Router pour Galera ou finalement le front HAProxy est la solution la plus simple? Le 25/06/2020 à 08:26, Nicolas GIRARDI a écrit :
Bonjour,
En effet il est conseillé d’écrire sur un seul des noeuds du cluster. L’approche avec un HaP pour faire le R/W Splitting est une bonne solution.
Cdlt.
Nicolas Girardi.
Le 25 juin 2020 à 08:12, Michaël Couren <couren@abes.fr> a écrit :
Bonjour, J'avais mis en place cette solution pour héberger des Wordpress notamment, à l'époque j'avais dû passer par des bidouillages et j'avais pas mal ramé avec Galera :) car le produit n'était pas encore bien mature : J'ai observé les mêmes problèmes de latence voire de dead-lock cités pour des applis comme Moodle et Wordpress lors de multiples accès concurrentiels sur 3 nœuds actifs, peut-être aussi dus à des problèmes en dehors du logiciel (glusterFS), mais j'avais dû finalement avec HAProxy en frontal diriger les requêtes sur un noeud "principal" pour conserver le secondaire et le troisième en "backup" (au sens HAProxy - car pour Galera cluster ils sont tous actifs).
Maintenant il est probable qu'une implantation récente de chez Mariadb doit mieux fonctionner, le produit évoluait souvent et j'ai pas opté pour une ré-installation "from scatch" depuis.
-- Cordialement / Best regards, Michaël Couren, ABES, Montpellier, France. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Le 25/06/2020 à 09:00, Julien - ISWT a écrit :
Est-ce qu'il existe un équivalent au MySQL Router pour Galera ou finalement le front HAProxy est la solution la plus simple?
Oui il y a https://proxysql.com/ Attention, bien que haproxy puisse faire loadbalancer TCP, il ne sait pas faire du R/W splitting MySQL (sauf développement récent que j'aurai loupé ou extension en LUA peut être ?). C'est l'application qui doit choisir vers quel front haproxy elle doit envoyer sa query. M
Bonjour. Le projet ProxySQL est le mieux pour cela. https://github.com/sysown/proxysql/wiki/MySQL-Server-Configuration Cdt Alexandre Le jeu. 25 juin 2020 à 09:00, Julien - ISWT <julien@iswt.fr> a écrit :
Est-ce qu'il existe un équivalent au MySQL Router pour Galera ou finalement le front HAProxy est la solution la plus simple?
Le 25/06/2020 à 08:26, Nicolas GIRARDI a écrit :
Bonjour,
En effet il est conseillé d’écrire sur un seul des noeuds du cluster. L’approche avec un HaP pour faire le R/W Splitting est une bonne solution.
Cdlt.
Nicolas Girardi.
Le 25 juin 2020 à 08:12, Michaël Couren <couren@abes.fr> <couren@abes.fr> a écrit :
Bonjour, J'avais mis en place cette solution pour héberger des Wordpress notamment, à l'époque j'avais dû passer par des bidouillages et j'avais pas mal ramé avec Galera :) car le produit n'était pas encore bien mature : J'ai observé les mêmes problèmes de latence voire de dead-lock cités pour des applis comme Moodle et Wordpress lors de multiples accès concurrentiels sur 3 nœuds actifs, peut-être aussi dus à des problèmes en dehors du logiciel (glusterFS), mais j'avais dû finalement avec HAProxy en frontal diriger les requêtes sur un noeud "principal" pour conserver le secondaire et le troisième en "backup" (au sens HAProxy - car pour Galera cluster ils sont tous actifs).
Maintenant il est probable qu'une implantation récente de chez Mariadb doit mieux fonctionner, le produit évoluait souvent et j'ai pas opté pour une ré-installation "from scatch" depuis.
-- Cordialement / Best regards, Michaël Couren, ABES, Montpellier, France. _______________________________________________ Liste de diffusion du FRsAGhttp://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAGhttp://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Alexandre
Merci à tous, écoutez ce que vous m'annoncer c'est très bien. Actuellement on utilise un LB (LVS oui c'est super vieux), avec 2 ports d'écoutes, un pour la lecture, un autre pour l'écriture. Globalement, le cluster 1 master, 1 candidate master et un slave. On utilise un binaire en go qui fait la migration du master vers le candidate master, il manipule les conf LVS, mariadb ..., mais par moments, la bascule ne se passe pas très bien, et le old master se retrouve avec des problèmes de synchro de slave. C'est sur cette bascule de master que je veux gagner en rapidité et en stabilité. Alex Le jeu. 25 juin 2020 à 08:26, Nicolas GIRARDI <n.girardi@gmail.com> a écrit :
Bonjour,
En effet il est conseillé d’écrire sur un seul des noeuds du cluster. L’approche avec un HaP pour faire le R/W Splitting est une bonne solution.
Cdlt.
Nicolas Girardi.
Le 25 juin 2020 à 08:12, Michaël Couren <couren@abes.fr> a écrit :
Bonjour, J'avais mis en place cette solution pour héberger des Wordpress notamment, à l'époque j'avais dû passer par des bidouillages et j'avais pas mal ramé avec Galera :) car le produit n'était pas encore bien mature : J'ai observé les mêmes problèmes de latence voire de dead-lock cités pour des applis comme Moodle et Wordpress lors de multiples accès concurrentiels sur 3 nœuds actifs, peut-être aussi dus à des problèmes en dehors du logiciel (glusterFS), mais j'avais dû finalement avec HAProxy en frontal diriger les requêtes sur un noeud "principal" pour conserver le secondaire et le troisième en "backup" (au sens HAProxy - car pour Galera cluster ils sont tous actifs).
Maintenant il est probable qu'une implantation récente de chez Mariadb doit mieux fonctionner, le produit évoluait souvent et j'ai pas opté pour une ré-installation "from scatch" depuis.
-- Cordialement / Best regards, Michaël Couren, ABES, Montpellier, France. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
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
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/
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
Le ven. 26 juin 2020 à 09:15, <frsag@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
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, <frsag@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/
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 <linuxopendoc@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, <frsag@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
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 <linuxopendoc@gmail.com <mailto:linuxopendoc@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, <frsag@jack.fr.eu.org <mailto:frsag@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/
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 <sn4ky@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 <linuxopendoc@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, <frsag@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
participants (11)
-
Alexandre Legrix -
frsag＠jack.fr.eu.org -
Jonathan Leroy - Inikup -
Julien - ISWT -
Michaël Couren -
Michel Blanc -
Nicolas GIRARDI -
Olivier Bonvalet -
open doc -
Pierre DOLIDON -
Ronan Ducamp