Piloter et sécuriser ses bases de données avec MySQL Proxy

MySQL Proxy

MySQL Proxy, proposé par MySQL AB, est le genre d’outils dont le rôle semble si évident qu’on se demande pourquoi il n’existait pas avant. Comme tout proxy, il récupère les requêtes destinées à la base de données, effectue des traitements et adresse une requête modifiée au serveur MySQL. Bien entendu, l’opération inverse est aussi gérée : MySQL Proxy sait récupérer un résultat de requête et le transformer avant de l’adresser au client initial.

Fonctionnalités

Après cette petite présentation, on peut se demander pourquoi on aurait besoin d’un proxy, puisque les services applicatifs (s’ils sont correctement architecturés et codés…) devraient envoyer une requête optimisée au serveur MySQL. Une petite liste des fonctionnalités finit par convaincre de son intérêt :

  • Analyse des requêtes
  • Filtrage et modification des requêtes et des résultats
  • Injection de requêtes
  • Load balancing
  • Exécution de scripts (basés sur le langage LUA)

Cas d’utilisation

Dans la pratique, on peut imaginer les situations suivantes :

  • Corriger les erreurs de syntaxe communes.
  • Garantir le fonctionnement d’anciennes applications utilisant des requêtes non supportées.
  • Supprimer du résultat un mot de passe demandé dans la requête.
  • Récupérer et fusionner avec le résultat des données externes à la base de données (fichiers, flux XML, RPC…)
  • Router les requêtes vers un autre serveur MySQL ou vers une autre base de données du même serveur.
  • Empiler un lot de requêtes et les contrôler avant de mettre à jour les tables.
  • Dupliquer les requêtes en temps réel sur deux bases différentes.
  • Exécuter un script shell avant ou après des modifications dans la base de données.
  • Interdire certains motifs de requêtes.
  • Verrouiller des tables selon le contexte.
  • Contrer les injections SQL non désirées.

On le voit, les possibilités sont infinies et ne dépendent que des contextes de production et de l’imagination des développeurs. MySQL Proxy permet surtout d’éviter d’intégrer la gestion de l’exploitation des bases de données MySQL dans les services applicatifs. Voilà enfin une saine séparation du travail du développeur métier et de l’administrateur MySQL !

Mise en œuvre

MySQL Proxy est encore en version alpha et son fonctionnement n’est garanti que pour les versions MySQL 5.0.x et ultérieures.

Pour découvrir ses possibilités, O’Reilly Network propose un didacticiel clair et très fourni : Getting Started with MySQL Proxy.

Source : Linuxfr.org

Commentaires

Newtoon

C’est costaud comme article et j’ai du mal à tout saisir. Suite à la mention du « load balancing », j’en profite pour poser ma question.

J’ai eu des problèmes d’hébergement (mutu) et, suite à des discussions avec de Pro, j’ai trouvé l’idée de pouvoir basculer d’une adresse IP de mon site à une autre (en cas de pépin). Il faudrait donc 2 sites (un en « backup »). J’ai oublié le nom un peu zarbi de cette technique mais l’objectif est simple : que mon site soit dispo 24/24 toute l’année sans faute.

PS : bravo pour ce design de blog, très épuré et correspondant à ton créneau.

19 septembre 2007, 11h56 · Répondre

Christophe

Merci pour tes retours très sympathiques sur le design !

Concernant le nom « zarbi » que tu cherches, il doit s’agir de cluster. Mais cela va bien plus loin que le secours en cas de pépin. Le but des clusters est de mettre en parallèle un certain nombre de serveurs qui pourront ainsi se partager le traitement des requêtes, le tout en temps réel. Tous les serveurs sont donc en exploitation en même temps. C’est un routeur qui assure le load balancing en frontal pour affecter une requête à un serveur clusterisé en fonction de sa charge de travail.

Si un serveur tombe, le service est assuré sans aucune intervention humaine.

En hébergement mutualisé, inutile d’espérer les clusters… C’est du sur-mesure qui coûte cher !

Un serveur de secours est une idée simple et efficace, à condition d’assurer en temps réel le mirroring des fichiers (via rsync ou les synchronisations de bases de données). Concernant l’IP, il vaut mieux la modifier dans la configuration réseau du serveur que dans les enregistrements DNS, sinon la coupure de service est quasi-assurée (mise à jour DNS oblige) ! Mais là encore, ce n’est pas faisable en hébergement mutualisé.

Quant à la disponibilité de 100%, c’est un mythe. La garantir à 99,9% est déjà un luxe (minimum 10 k€/an).

19 septembre 2007, 22h51 · Répondre

Ajouter un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *