Intéressantes ces remarques, est ce que tu te souviens de la version de mysql proxy testée?
Je repose une autre question, quand un client veut faire un site forte charge à partir d'un CMS ou moteur de blog du marché et que ces derniers n'ont pas d'intelligence dans la répartition de charge quel type de solution autre que mysql proxy vous utiliseriez? On devrait pouvoir développer une surcharge de la classe sql pour faire le split mais les clients n'ont bizarrement jamais de budget pour cela.
Le 26/08/11 16:54, Sébastien FOUTREL a écrit :
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-frsag@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/