Un R/W splitting doit prendre en compte enormement de parametres.
Comment traiter un last insert id ?
Comment traiter une transaction ?
De plus, MySQL-proxy a un defaut dans la gestion des sessions. Je ne
sais pas s'il a été corrigé mais cela avait provoqué un gros NOGO sur
un gros projet pour nous.
En gros :
un user U1 qui n'a le droit que d'acceder au schema A se connecte au
proxy, le proxy ouvre une sessions avec l'instance et transmet l'auth
du user U1
un user U2 qui n'a le droit que d'acceder au schema B se connecte au
proxy, le proxy peut reutiliser la session ouverte precedemment pour
U1 sauf que la requete va etre rejetée car l'auth a deja été faite par
U1 et que celui-ci n'a pas acces au schema B.
Deuxieme probleme.
Un java hibernate se connecte et créé un pool de connexions vers
mysql-proxy, mysql-proxy créé des connections vers l'instance. pour
une raison ou une autre les connexions entre mysql-proxy et l'instance
sont coupées. Hibernate n'est pas informée et donc ses requetes sont
mortes.
Ce sont deux cas rencontrés il y a plus d'un an et depuis nous avons
abandonné l'idée d'utiliser Mysql-proxy. Nos clients qui font de
l'usage intensif (plus de 5000hits/s) utilisent un LB au niveau du
code pour determiner s'ils attaquent le master ou le slave et les
slaves sont derriere un LB software genre lvs.
My 2 cents.
Le 26 août 2011 15:15, Gregory Duchatelet <greg-fr...@duchatelet.net> a écrit :
> Le 25/08/2011 17:56, Wallace a écrit :
>
> Le 25/08/11 16:58, Gregory Duchatelet a écrit :
>
> Va falloir que je me mette au LUA ! :)
> Si tu as un script qui marche, ou une version modifié de celui fournit avec
> MySQL Proxy, je suis preneur !
>
> Je n'ai utilisé que le script livré dans les docs de mysql proxy, pas eu
> besoin d'aller plus loin pour le moment mais tes recherches m'intéressent
> pour comprendre ce qui cloche dans son script.
>
> Je reste quand même persuadé que tu auras de meilleurs résultats avec la
> première idée. Seul l'appli sait si elle a besoin de faire un read juste
> après un update et c'est clairement le problème du split des requêtes.
>
> Notre appli utilise cette regexp pour savoir s'il faut taper sur un slave ou
> pas :
>
> preg_match("/^([\r\n\t ]+)?(SELECT|USE|SET|CALL
> (stats)?|DESCRIBE|(CREATE|DROP) TEMPORARY TABLE|\()/i", trim($query), $r);
>
> Avec ça l'appli n'a pas besoin de "savoir".
>
> Dans mon code de mon projet quand j'execute une requête sql la fonction
> d'appel a une variable pour forcer
> à être sur le master. Si elle est présente alors peut importe si la requête
> ne comporte qu'un select elle sera quand même passer sur le master et pas
> sur les slaves. Ca le mysql proxy ne le saura jamais.
> Quand les devs jouent à ce genre de mise à jour puis get tu peux pas trop te
> permettre d'attendre 1 ou plusieurs secondes que ca se synchronise.
>
> Si, dans le script LUA on peut faire ce qu'on veut ! Imagines, tu peux faire
> un simple
> SET forcemaster=1
> Et dans le script LUA, catcher ce SET, stocker dans une variable un peu
> comme la variable is_in_transaction de ce même script, et voilà :)
>
> Pour info, le script LUA en question est visible ici :
> http://paste.frsag.net/TAWVp
>
> --
> Greg
>
> _______________________________________________
> Liste de diffusion du FRsAG
> http://www.frsag.org/
>
>
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
