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/
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
