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