Comme je l ai deja dit, MySQL-Proxy n'est pas une solution pour ce cas, le probleme n est pas au niveau du LUA (il peux tenter de parcourir les backend pour le changer, il se fera virer par le logiciel).
Regardez plutot du cote de sqlrelay pour cela.
On 30/08/2011 10:47, Pierre-Henry Muller wrote:
Salut,
Entièrement d'accord avec toutes ces techniques, heureusement j'ai des clients qui comprennent les enjeux du côté applicatif et font souvent tout ce qu'il faut pour que l'architecture reste simple pour mieux marcher. Mais voilà quand on est fasse à des mamouths (nom que je donne aux grosses entreprises / administrations où il faut 5 réunions espacées de 1 à 2 semaines, autant de rapports plein de blabla et de schéma pour faire la moindre action) et qu'ils prennent la décision de ne pas toucher au code parce que l'entreprise qui fait le développement a dit que c'était compliqué, il faut bien trouver une solution sinon on dit que c'est toi qui n'est pas bon ... Bref éternel débat mais on est bien tous d'accord sur le fait que la bonne solution à l'heure actuelle est côté code sauf que Grégory va nous sortir un nouveau script lua qui va super bien faire son boulot.
Allé Greg un peu de pression au passage :P
Le 30/08/11 00:35, Damien Claisse a écrit :
Hello,
La solution côté système parait souvent plus simple et moins coûteuse mais d'expérience elle finira toujours par te coûter bonbon à plus ou moins long terme (tu vas monter du serveur de plus en plus gros, empiler les rustines puis maintenir des rustines de rustines et perdre du temps en maintenance), jusqu'au jour ou patatras, plus rien ne tiendra la route, tu vas devoir tout refaire de zéro: l'application doit aussi être scalable à son niveau.
Bien entendu, les applis ne sont pas souvent pensées scalabilité (cache, sharding ou au moins ventilation lecture/écriture SQL sur deux connexions différentes), mais il est souvent possible de rajouter tout ça de façon itérative, quitte à patcher au fur et à mesure l'appli: tu fournis une seconde ip virtuelle portée par un keepalived/haproxy/etc pour se connecter à des slaves répliqués, et tu demandes au(x) dev de basculer les requêtes les plus consommatrices (et pas dépendantes de l'éventuel lag de répli) dessus, puis ça tient un peu plus longtemps, et tu réidentifies des requêtes à passer sur la répli, et ainsi de suite.
Ca marche aussi avec la mise en place du cache applicatif (memcached par exemple), et comme suggéré auparavant tu peux également monter un reverse proxy cache (nginx, varnish ou autre) en amont sur des requêtes qui n'ont pas besoin de trop de fraicheur, le but étant de ne pas envoyer des requêtes inutiles sur ton serveur d'appli et ta DB. Tu peux même commencer par le reverse proxy de façon totalitaire (genre si pas de cookie qui dit que le type est logué alors page sortie du cache) si l'appli est vraiment impossible à patcher et qu'il te faut une amélioration de perfs pour hier.
Bon courage,
Liste de diffusion du FRsAG http://www.frsag.org/