Bonjour, pour l'instant je n'ai pas trouvé mieux qu'une gestion coté applicatif pour répartir les requêtes de lecture (SELECT...) sur les slaves MySQL, et les requêtes d'écritures sur le master, avec gestion un peu plus intelligente qu'un simple load-balancer : - regex sur la requête pour pouvoir l'orienter - gestion des slaves down, spares - exclusion des slaves ayant trop de délais de réplication Pour tout ça MySQL Proxy semblait tout faire sur le papier, à l'aide de scripts LUA : http://dev.mysql.com/doc/relnotes/mysql-proxy/en/index.html Avez vous des retours sur cet outil ? Où sur d'autres outils ? Greg
Bonjour, Peut-être regarder du côté de mysqlnd_ms. Lilian Le 09/09/2013 09:45, Greg a écrit :
Bonjour,
pour l'instant je n'ai pas trouvé mieux qu'une gestion coté applicatif pour répartir les requêtes de lecture (SELECT...) sur les slaves MySQL, et les requêtes d'écritures sur le master, avec gestion un peu plus intelligente qu'un simple load-balancer : - regex sur la requête pour pouvoir l'orienter - gestion des slaves down, spares - exclusion des slaves ayant trop de délais de réplication
Pour tout ça MySQL Proxy semblait tout faire sur le papier, à l'aide de scripts LUA : http://dev.mysql.com/doc/relnotes/mysql-proxy/en/index.html
Avez vous des retours sur cet outil ? Où sur d'autres outils ?
Greg
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Lilian RIGARD - Devclic Gérant - CEO & CTO E-mail : lilian@devclic.fr Web : http://www.devclic.f
J'avais testé il y a 2-3 ans la version 0.7, donc ça date un peu. A l'époque, c'était pas top côté perfs et stabilité, mais ça a pu changer depuis. Ceci étant dit, c'est toujours en alpha (avec un dev qui a commencé en 2007) et les releases ne sont pas très fréquentes, ce qui n'est pas un signe encourageant. A l'époque, je n'avais pas réussi à déterminer s'il était possible de garantir qu'une transaction aboutisse toujours sur le maitre (pour garantir que les lectures et les écritures soient faites dans un état cohérent). Si c'est possible, ce n'est certainement pas simple. J'en étais arrivé à la conclusion que ce genre d'opérations doit impérativement se faire au niveau applicatif. Sinon, pour ne pas avoir à se préoccuper du split R/W, il y a Galera... JFB Le 9 sept. 2013 à 09:45, Greg a écrit :
Bonjour,
pour l'instant je n'ai pas trouvé mieux qu'une gestion coté applicatif pour répartir les requêtes de lecture (SELECT...) sur les slaves MySQL, et les requêtes d'écritures sur le master, avec gestion un peu plus intelligente qu'un simple load-balancer : - regex sur la requête pour pouvoir l'orienter - gestion des slaves down, spares - exclusion des slaves ayant trop de délais de réplication
Pour tout ça MySQL Proxy semblait tout faire sur le papier, à l'aide de scripts LUA : http://dev.mysql.com/doc/relnotes/mysql-proxy/en/index.html
Avez vous des retours sur cet outil ? Où sur d'autres outils ?
Greg _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 09/09/2013 10:47, JF Bustarret a écrit :
J'en étais arrivé à la conclusion que ce genre d'opérations doit impérativement se faire au niveau applicatif.
Exactement pareil. C'est au dev de bosser sur ça ;) Généralement j'utilise haproxy en plus pour savoir si un slave est un peu lent ou non. En fonction du nombre de req/s ça peut être un peu mauvais, mais bon, ça dépends réellement. Je fais rajouter quelques lignes de code aux devs pour qu'ils fassent un check toutes les 2/3 minutes savoir si un Slave est à la ramasse ou non (memcache pour garder le status, un ptit cron pour update ce status). Mais bon, généralement les devs vont gueuler, mais c'est réellement de leur côté qu'il faut faire ça. De ton côté ça simplifie énormément ton infra (un mysql proxy en moins) et surtout après, si tu as des couilles de réplication, les devs peuvent t'orienter, plutôt que de te dire "les données sont pas bonnes" ;)
Sinon, pour ne pas avoir à se préoccuper du split R/W, il y a Galera...
JFB
Le 9 sept. 2013 à 09:45, Greg a écrit :
Bonjour,
pour l'instant je n'ai pas trouvé mieux qu'une gestion coté applicatif pour répartir les requêtes de lecture (SELECT...) sur les slaves MySQL, et les requêtes d'écritures sur le master, avec gestion un peu plus intelligente qu'un simple load-balancer : - regex sur la requête pour pouvoir l'orienter - gestion des slaves down, spares - exclusion des slaves ayant trop de délais de réplication
Pour tout ça MySQL Proxy semblait tout faire sur le papier, à l'aide de scripts LUA : http://dev.mysql.com/doc/relnotes/mysql-proxy/en/index.html
Avez vous des retours sur cet outil ? Où sur d'autres outils ?
Greg _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonsoir, et merci pour vos retours. Je ne suis pas aussi certain que ce soit aux devs de gérer ça. D'un coté c'est mieux pour eux, ils peuvent gérer les erreurs au cas par cas, soit en retentant plus tard, soit en affichant un message d'erreur approprié, soit en tentant sur un autre slave, etc ... Mais je constate que les devs partent du principe que "ça marche"... C'est une mauvaise habitude difficile à changer et surtout c'est un "combat" permanent. Je note la solution VIP+master et IPVS/Keepalived sur les slaves ;) Merci, Greg Le 9 septembre 2013 14:28, Boris Pigeot <ml@admin-serv.net> a écrit :
Le 09/09/2013 10:47, JF Bustarret a écrit :
J'en étais arrivé à la conclusion que ce genre d'opérations doit impérativement se faire au niveau applicatif.
Exactement pareil. C'est au dev de bosser sur ça ;) Généralement j'utilise haproxy en plus pour savoir si un slave est un peu lent ou non. En fonction du nombre de req/s ça peut être un peu mauvais, mais bon, ça dépends réellement.
Je fais rajouter quelques lignes de code aux devs pour qu'ils fassent un check toutes les 2/3 minutes savoir si un Slave est à la ramasse ou non (memcache pour garder le status, un ptit cron pour update ce status).
Mais bon, généralement les devs vont gueuler, mais c'est réellement de leur côté qu'il faut faire ça. De ton côté ça simplifie énormément ton infra (un mysql proxy en moins) et surtout après, si tu as des couilles de réplication, les devs peuvent t'orienter, plutôt que de te dire "les données sont pas bonnes" ;)
Sinon, pour ne pas avoir à se préoccuper du split R/W, il y a Galera...
JFB
Le 9 sept. 2013 à 09:45, Greg a écrit :
Bonjour,
pour l'instant je n'ai pas trouvé mieux qu'une gestion coté applicatif pour répartir les requêtes de lecture (SELECT...) sur les slaves MySQL, et les requêtes d'écritures sur le master, avec gestion un peu plus intelligente qu'un simple load-balancer : - regex sur la requête pour pouvoir l'orienter - gestion des slaves down, spares - exclusion des slaves ayant trop de délais de réplication
Pour tout ça MySQL Proxy semblait tout faire sur le papier, à l'aide de scripts LUA : http://dev.mysql.com/doc/**relnotes/mysql-proxy/en/index.**html<http://dev.mysql.com/doc/relnotes/mysql-proxy/en/index.html>
Avez vous des retours sur cet outil ? Où sur d'autres outils ?
Greg ______________________________**_________________ Liste de diffusion du FRsAG http://www.frsag.org/
______________________________**_________________ Liste de diffusion du FRsAG http://www.frsag.org/
______________________________**_________________ Liste de diffusion du FRsAG http://www.frsag.org/
Pour la partie repartition de charge entre les slaves, j'utilise depuis des années (2006) du LVS géré par keepalived. En particulier une partie intéressante: MISC_CHECK { # MISC healthchecker misc_path <STRING>|<QUOTED-STRING> # External system script or program misc_timeout <INTEGER> # Script execution timeout # If set, exit code from healthchecker is used # to dynamically adjust the weight as follows: # exit status 0: svc check success, weight # unchanged. # exit status 1: svc check failed. # exit status 2-255: svc check success, weight # changed to 2 less than exit status. # (for example: exit status of 255 would set # weight to 253) misc_dynamic Donc en jouant bien sur ton script de monitoring, tu peux ejecter les serveurs trop en retard, et alterer le poids de chaque serveur en fonction de la charge. En faisant du lvs-dr ca depotte pas mal, meme avec une dizaine de slaves, sans SPOF. On 2013-09-09 09:45, Greg wrote:
Bonjour,
pour l'instant je n'ai pas trouvé mieux qu'une gestion coté applicatif pour répartir les requêtes de lecture (SELECT...) sur les slaves MySQL, et les requêtes d'écritures sur le master, avec gestion un peu plus intelligente qu'un simple load-balancer : - regex sur la requête pour pouvoir l'orienter - gestion des slaves down, spares - exclusion des slaves ayant trop de délais de réplication
Pour tout ça MySQL Proxy semblait tout faire sur le papier, à l'aide de scripts LUA : http://dev.mysql.com/doc/relnotes/mysql-proxy/en/index.html
Avez vous des retours sur cet outil ? Où sur d'autres outils ?
Greg
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, Pour la répartition de charge sur MySQL, nous sommes partis sur plusieurs choses : Côté applicatif, séparation des requêtes lecture / écriture au niveau de notre framework de connexion à la base de données avec deux handlers, un pour les écritures et un pour les lectures. Côté infrastructure : - Un master avec une VIP de réplication, du heartbeat et un script de bascule de la réplication en cas de crash du master. - Un load balancer avec une VIP pour la lecture, avec heartbeat + haproxy * des slaves derrière le haproxy * un script qui check le seconds_behind_master du show slave status et retire les slaves de la grappe en cas de seconds_behind_master > 0 * le master en backup si aucun slave n'est disponible Comme nous sommes tributaires d'un délai de réplication de l'ordre de la seconde, nous gérons en plus les retards de réplication au niveau applicatif quand celui-ci tente d'accéder à un objet qui n'existe pas encore sur le slave, en postposant la requête d'une seconde. Hope it helps Le 9 sept. 2013 à 15:10, Thomas Pedoussaut <thomas@pedoussaut.com> a écrit :
Pour la partie repartition de charge entre les slaves, j'utilise depuis des années (2006) du LVS géré par keepalived.
En particulier une partie intéressante: MISC_CHECK { # MISC healthchecker misc_path <STRING>|<QUOTED-STRING> # External system script or program misc_timeout <INTEGER> # Script execution timeout
# If set, exit code from healthchecker is used # to dynamically adjust the weight as follows: # exit status 0: svc check success, weight # unchanged. # exit status 1: svc check failed. # exit status 2-255: svc check success, weight # changed to 2 less than exit status. # (for example: exit status of 255 would set # weight to 253) misc_dynamic
Donc en jouant bien sur ton script de monitoring, tu peux ejecter les serveurs trop en retard, et alterer le poids de chaque serveur en fonction de la charge.
En faisant du lvs-dr ca depotte pas mal, meme avec une dizaine de slaves, sans SPOF.
On 2013-09-09 09:45, Greg wrote:
Bonjour,
pour l'instant je n'ai pas trouvé mieux qu'une gestion coté applicatif pour répartir les requêtes de lecture (SELECT...) sur les slaves MySQL, et les requêtes d'écritures sur le master, avec gestion un peu plus intelligente qu'un simple load-balancer : - regex sur la requête pour pouvoir l'orienter - gestion des slaves down, spares - exclusion des slaves ayant trop de délais de réplication
Pour tout ça MySQL Proxy semblait tout faire sur le papier, à l'aide de scripts LUA : http://dev.mysql.com/doc/relnotes/mysql-proxy/en/index.html
Avez vous des retours sur cet outil ? Où sur d'autres outils ?
Greg
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Frédéric de Villamil / @fdevillamil I'm not strange, weird, off, nor crazy, my reality is just different from yours. Le Rayon UX – http://t37.net
Bonjour la liste, Peut-être regarder du coté de MariaDB Galera Cluster ? Tu fais tout en local et ta DB est identique entre tout tes "masters"... Un peu simple comme réponse mais ça te donnera peut être des idées différentes pour scaler ( désolé du franglicisime ). My 2cents, Tristan. Le 09/09/2013 15:17, Frédéric de Villamil a écrit :
Bonjour,
Pour la répartition de charge sur MySQL, nous sommes partis sur plusieurs choses :
Côté applicatif, séparation des requêtes lecture / écriture au niveau de notre framework de connexion à la base de données avec deux handlers, un pour les écritures et un pour les lectures.
Côté infrastructure : - Un master avec une VIP de réplication, du heartbeat et un script de bascule de la réplication en cas de crash du master. - Un load balancer avec une VIP pour la lecture, avec heartbeat + haproxy * des slaves derrière le haproxy * un script qui check le seconds_behind_master du show slave status et retire les slaves de la grappe en cas de seconds_behind_master > 0 * le master en backup si aucun slave n'est disponible
Comme nous sommes tributaires d'un délai de réplication de l'ordre de la seconde, nous gérons en plus les retards de réplication au niveau applicatif quand celui-ci tente d'accéder à un objet qui n'existe pas encore sur le slave, en postposant la requête d'une seconde.
Hope it helps
Le 9 sept. 2013 à 15:10, Thomas Pedoussaut <thomas@pedoussaut.com <mailto:thomas@pedoussaut.com>> a écrit :
Pour la partie repartition de charge entre les slaves, j'utilise depuis des années (2006) du LVS géré par keepalived.
En particulier une partie intéressante: MISC_CHECK { # MISC healthchecker misc_path <STRING>|<QUOTED-STRING> # External system script or program misc_timeout <INTEGER> # Script execution timeout
# If set, exit code from healthchecker is used # to dynamically adjust the weight as follows: # exit status 0: svc check success, weight # unchanged. # exit status 1: svc check failed. # exit status 2-255: svc check success, weight # changed to 2 less than exit status. # (for example: exit status of 255 would set # weight to 253) misc_dynamic
Donc en jouant bien sur ton script de monitoring, tu peux ejecter les serveurs trop en retard, et alterer le poids de chaque serveur en fonction de la charge.
En faisant du lvs-dr ca depotte pas mal, meme avec une dizaine de slaves, sans SPOF.
On 2013-09-09 09:45, Greg wrote:
Bonjour,
pour l'instant je n'ai pas trouvé mieux qu'une gestion coté applicatif pour répartir les requêtes de lecture (SELECT...) sur les slaves MySQL, et les requêtes d'écritures sur le master, avec gestion un peu plus intelligente qu'un simple load-balancer : - regex sur la requête pour pouvoir l'orienter - gestion des slaves down, spares - exclusion des slaves ayant trop de délais de réplication
Pour tout ça MySQL Proxy semblait tout faire sur le papier, à l'aide de scripts LUA : http://dev.mysql.com/doc/relnotes/mysql-proxy/en/index.html
Avez vous des retours sur cet outil ? Où sur d'autres outils ?
Greg
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Frédéric de Villamil / @fdevillamil I'm not strange, weird, off, nor crazy, my reality is just different from yours. Le Rayon UX – http://t37.net
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, Le 09/09/13 16:18, Tristan Mahé a écrit :
Bonjour la liste,
Peut-être regarder du coté de MariaDB Galera Cluster ?
Tu fais tout en local et ta DB est identique entre tout tes "masters"...
Un peu simple comme réponse mais ça te donnera peut être des idées différentes pour scaler ( désolé du franglicisime ). J'utilise une telle config (à base d'xtradb cluster de Percona) pour assurer de la haute dispo inter-zones sur AWS. Les serveurs sont derrière un LB, lequel effectue un Health Check sur un port dédié et écarte un serveur lorsqu'il est down. Basique mais robuste (KISS). Si besoin, il est d'ailleurs facile d'exclure un serveur qui aurait trop de load via ce Health Check.
En revanche, le mode multi-master introduit un peu de latence, cette solution peut ne pas convenir s'il y a beaucoup d'opérations d'écriture. Il y a aussi quelques limitations (query cache désactivé, par exemple), et bien que MyISAM fonctionne il vaut mieux préférer InnoDB. Enfin, il est recommandé de ne dépasser (je crois me souvenir) 10 serveurs, je pense qu'au delà les perfs doivent chuter rapidement. Quelques liens : http://www.percona.com/software/percona-xtradb-cluster http://www.percona.com/doc/percona-xtradb-cluster/limitation.html http://www.percona.com/files/presentations/WEBINAR-Percona-XtraDB-Cluster-20... https://archive.fosdem.org/2013/schedule/event/mysql_galera/attachments/slid... a+ -- Olivier
participants (8)
-
Boris Pigeot -
Frédéric de Villamil -
Greg -
JF Bustarret -
Lilian - Devclic -
Olivier Le Cam -
Thomas Pedoussaut -
Tristan Mahé