MySQL Proxy

Posté par  (site web personnel) . Modéré par Nÿco.
Étiquettes : aucune
1
9
août
2007
Base de données
MySQL AB a publié il y a quelques semaines un nouvel outil fort intéressant et qui a été accueilli avec enthousiasme par la communauté des utilisateurs MySQL. Il s'agit de MySQL Proxy. Comme son nom l'indique ce programme se place entre le client et le serveur MySQL. La puissance de ce logiciel réside notamment dans sa flexibilité, fournie par le langage de script Lua.

Selon Wikipédia : Lua est un langage de script libre dont l'interpréteur est conçu dans un but de compacité (95 à 185 Ko pour la version 5.0.2, selon le compilateur utilisé et le système cible). Lua est conçu de manière à pouvoir être embarqué au sein d'une autre application, ce qui permet d'étendre celle-ci.

Avec MySQL Proxy, vous serez capable de :
  • Filtrer les requêtes avant de les transmettre au serveur ;
  • Réécrire certaines requêtes (en corrigant la syntaxe par exemple) ;
  • Intercepter le resultset afin d'y supprimer, modifier ou ajouter des enregistrements ;
  • Interdire le retour de certains résultats vers le client.
Mais également :
  • Rediriger les écritures sur le maître et les lectures sur l'esclave, dans le cas de réplication ;
  • Exécuter des commandes Shell.
MySQL Proxy est publié sous licence GPL et toujours en version alpha, mais n'a, sans aucun doute, pas encore fini de faire parler de lui.

Aller plus loin

  • # Retour d'expérience en production

    Posté par  (site web personnel) . Évalué à 10.

    Bonjour,

    effectivement ce produit est très interressant sur le principe, on évite par exemple de faire de la répartition de charge au niveau applicatif...

    Je l'ai configuré et installé, tout semblait parfait, sous l'effet de l'excitation je l'ai meme mis en prod quelques heures.

    Environnement: des serveurs PHP qui interroge un pool de 5 serveurs MySQL de manière aléatoire, statistiquement c'est équitable :)
    J'ai donc changé le pool de 5 par 1 seul: MySQL Proxy, qui lui load balance les requetes sur les 5 serveurs (read-only)

    Impressionnant, mysql proxy ne consomme rien en CPU avec 1500 req/sec , le serveur n'atteint meme pas 1 de charge, et ... ça marche !

    Sauf que ... je ne sais pas pourquoi, mais les 5 serveurs se prennent moins de requetes, la partie du site concerné est plus lente à la navigation, on dirait que mysql proxy n'accepte qu'un nombre restreint de connections simultanés et/ou par secondes, le serveur étant pourtant légerement tuné pour largement encaisser plus de 100000 cnx / seconde.

    J'ai posé la question sur le forum mysql proxy, et n'ai pas obtenu de réponse....
    Et je n'ai pas le temps de creser, pour l'instant.

    Dommage :-(

    • [^] # Re: Retour d'expérience en production

      Posté par  (site web personnel) . Évalué à 5.

      Juste une question au passage, tu réplique avec quoi / comment tes cinq serveurs ?

      • [^] # Re: Retour d'expérience en production

        Posté par  (site web personnel) . Évalué à 5.

        Réplication partielle MySQL 5 depuis un seul master.

        Pourquoi ?

        • [^] # Re: Retour d'expérience en production

          Posté par  (site web personnel) . Évalué à 3.

          Parceque j'y connais rien et je dois en faire bientôt :)

          • [^] # Re: Retour d'expérience en production

            Posté par  (site web personnel) . Évalué à 7.

            Si je peux me permettre quelques conseils ;)

            Tu peux répliquer toute la DB, juste quelques DB, ou encore seulement des tables.

            Plus tu répliques de données, moins tes slaves seronts efficaces pour répondre aux requetes de lectures, et plus ils risquent de prendre du délais de réplic (d'après mon expérience c'est exponentiel :( le slave qui prend du délais devient tres vite innaccessible)

            Mais attention aux parametres de config "replicate-ignore-table" qui permettent de ne pas répliquer toutes les tables, MAIS si une requête d'écriture impliquant des tables ignorées apparait, la réplic est cassée.
            Exemple typique, tu réplic les tables A, B, C et tu ignores D. Une requete de ce genre va planter la réplic:
            UPDATE B SET champ=1 WHERE D > 0;

            Pour revenir à mysql proxy, il va etre possible dans les versions futures de changer dynamiquement la liste des slaves. Donc avec un programme tiers, on peut récupérer les délais de réplic de tous les slaves, et appliquer un algorithme pour ajouter/supprimer des slaves de mysql proxy ....

    • [^] # Re: Retour d'expérience en production

      Posté par  (site web personnel) . Évalué à 4.

      C'est une version alpha, il y a surement encore des trucs à affiner. Mais ton feedback a du être apprécié sur le forum. C'est avec ce genre de retour que le produit se développe plus rapidement.

  • # Il existe ausi DBIx::MyServer en Perl

    Posté par  . Évalué à 4.

    Sympa, ce proxy.

    Pour ceux que l'utilisation d'un nouveau langage (lua) rebute, vous pouvez également utiliser DBIx::MyServer, un module en Perl.

    Un très bon article à ce sujet : http://dev.mysql.com/tech-resources/articles/dbixmyserver.ht(...)

    Ce qu'on peut en faire ?

    - implémenter un système de journal (log) maison en local ou à distance
    - générer des tests à la demande
    - implémenter des macros pour les expressions SQL les plus courantes
    - lancer des commandes shell et du mail par votre serveur de bases de données
    - utiliser d'autres SGBD au sein de MySQL
    - ...

  • # Et pourquoi pas mettre des requêtes... en memcache ?

    Posté par  (site web personnel) . Évalué à 2.

    Ah, l'un de mes rêves les plus fous ; un proxy SQL !

    C'est assez bizarre l'utilisation de LUA, mais mon rêve le plus fou pourrait bien se réaliser là : mettre les grosses requêtes SQL en memcache sans toucher au code PHP/Perl/ruby pour cacher mes requêtes !

    En effet, on s'est déjà amusé à écrire une lib pour utiliser memcache trouvé là :
    http://trac.lighttpd.net/trac/attachment/ticket/1139/Memcach(...) (la dépêche ne le dis pas, mais LUA est aussi pas mal utilisé dans lightty).

    Il n'y a donc plus qu'à faire la suite, ça ne saurait être bien difficile pour qui a un peu de temps à perdre... Un volontaire pour tester ?

    • [^] # Re: Et pourquoi pas mettre des requêtes... en memcache ?

      Posté par  (site web personnel) . Évalué à 7.

      (la dépêche ne le dis pas, mais LUA est aussi pas mal utilisé dans lightty)

      Ce que la dépêche ne dit pas non plus, ni toi d'ailleurs :), c'est que lighttpd et mysqlproxy sont du même auteur : Jan Kneschke

    • [^] # Re: Et pourquoi pas mettre des requêtes... en memcache ?

      Posté par  (site web personnel) . Évalué à 2.

      MySQL fait déjà du cache sur les requêtes ... il suffit d'avoir pas mal de RAM :)

      • [^] # Re: Et pourquoi pas mettre des requêtes... en memcache ?

        Posté par  (site web personnel) . Évalué à 3.

        Je parle d'un memcache, pas du Query Cache de MySQL qui dans mon cas ne me sert pas (et j'ai même déjà vu le query cache tuer les performances).

        http://www.danga.com/memcached/


        What about MySQL 4.x query caching?

        MySQL query caching is less than ideal, for a number of reasons:

        * MySQL's query cache destroys the entire cache for a given table whenever that table is changed. On a high-traffic site with updates happening many times per second, this makes the the cache practically worthless. In fact, it's often harmful to have it on, since there's a overhead to maintain the cache.
        * On 32-bit architectures, the entire server (including the query cache) is limited to a 4 GB virtual address space. memcached lets you run as many processes as you want, so you have no limit on memory cache size.
        * MySQL has a query cache, not an object cache. If your objects require extra expensive construction after the data retrieval step, MySQL's query cache can't help you there.

        If the data you need to cache is small and you do infrequent updates, MySQL's query caching should work for you. If not, use memcached.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.