Pour chaque connexion au proxy, le proxy va decider d un serveur mysql a utiliser, alors que vous n avez pas encore effectue la moindre requete ( du moins c etait comme ca il y a un an et demi, et on ne pouvai pas forcer un changement de serveur via LUA, question de securite ). C est donc un probleme de design.
Il existe un logiciel bien mieux pense pour ce genre de cas, qui s appelle sqlrelay. sqlrelay se connecte d entree a tous les serveurs, avec un pool de connexion, et lorsque vous effectuez des requetes, il va decider sur quel serveur cela doit aller, au lieu de vous affecter un serveur a la connexion.
Par contre sqlrelay ne semble plus maintenu, les erreurs sont mal gerees ... la ML tres peu locace. Autant pour mes tests ca a tres bien fonctionne, autant 1 an apres quand on a voulu vraiment le tester a fond pour eventuellement le mettre en prod, on a eu des plantages des demons sans la moindre explication, ni la moindre erreur dans les logs, et tu te retrouves vite comme un con =)
On 26/08/2011 16:54, Sébastien FOUTREL wrote:
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.
<<attachment: guillaume_friloux.vcf>>
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
