Commençons par l’installation du script. Rien de plus simple, il vous suffit pour commencer de télécharger et de décompresser une archive de l’outil, disponible ici. Ensuite, des classiques

$ perl Makefile.PL
$ make
# make install

vous permettent d’installer le script. Notez, point agréable, qu’une page de man est intégrée. Si vous cherchez la syntaxe d’une option, un man mysqlsla vous dispensera donc bien souvent d’aller faire un tour sur le site du projet.

mysqlsla est plus généraliste que mysqldumpslow dans le sens où il est capable de traiter tout type de journal (requêtes lentes, mais aussi journal binaire ou journal général, ou encore journal défini par l’utilisateur). Les principes que nous allons voir dans cet article pour les requêtes lentes sont aussi valables pour les autres types de journaux.

L’idée de base de mysqlsla est de pouvoir analyser des fichiers journaux en leur appliquant éventuellement des filtres afin de ne garder que certains événements et d’émettre un rapport personnalisable présentant les résultats de cette analyse. Dans cet article nous allons seulement regarder les capacités de filtrage de mysqlsla et pas la manière de produire un rapport personnalisé, puisque le rapport par défaut nous convient très bien.

Pour un premier essai, lançons mysqlsla sans paramètre particulier à part l’option lt (comme log type) qui indique au script que le fichier passé est un journal de requêtes lentes. Cette option n’est en réalité pas indispensable car mysqlsla sait détecter automatiquement le type de journal :

$ mysqlsla -lt slow msandbox-slow.log
Report for slow logs: msandbox-slow.log
4 queries total, 2 unique
Sorted by 't_sum'
Grand Totals: Time 1 s, Lock 0 s, Rows sent 1.80k, Rows Examined 64.18k

________________________________________________ 001 ___
Count : 1 (25.00%)
Time : 718.344 ms total, 718.344 ms avg, 718.344 ms to 718.344 ms max (79.40%)
Lock Time (s) : 259 s total, 259 s avg, 259 s to 259 s max (52.11%)
Rows sent : 0 avg, 0 to 0 max (0.00%)
Rows examined : 16.04k avg, 16.04k to 16.04k max (25.00%)
Database : sakila
Users :
msandbox@localhost : 100.00% (1) of query, 100.00% (4) of all users

Query abstract:
SET timestamp=N; INSERT INTO rental2 SELECT * FROM rental;

Query sample:
SET timestamp=1278504762;
INSERT INTO rental2 SELECT * FROM rental;

________________________________________________ 002 ___
Count : 3 (75.00%)
Time : 186.368 ms total, 62.123 ms avg, 52.575 ms to 74.232 ms max (20.60%)
Lock Time (s) : 238 s total, 79 s avg, 60 s to 117 s max (47.89%)
Rows sent : 599 avg, 599 to 599 max (100.00%)
Rows examined : 16.04k avg, 16.04k to 16.04k max (75.00%)
Database : sakila
Users :
msandbox@localhost : 100.00% (3) of query, 100.00% (4) of all users

Query abstract:
SET timestamp=N; SELECT customer_id,COUNT(*) FROM rental WHERE return_date>'S' GROUP BY customer_id;

Query sample:
SET timestamp=1278504711;
SELECT customer_id,COUNT(*) FROM rental WHERE return_date>'2005-01-01' GROUP BY customer_id;

A première vue, ce rapport ressemble à celui de mysqldumpslow avec un regroupement des requêtes similaires. Le rapport est cependant plus complet car pour chaque groupe, nous avons les valeurs minimales, moyennes et maximales ainsi qu’une information très intéressante sur le poids relatif de chaque groupe, ce qui permet de cibler facilement les requêtes qui ont le plus contribué au temps de réponse ou qui ont examiné le plus de lignes.

Autre point à noter : pour chaque groupe de requêtes, mysqlsla nous présente une vue abstraite de la requête, c’est-à-dire une requête générique où les paramètres qui varient entre les requêtes du groupe sont remplacés par N pour un nombre ou S pour une chaîne de caractères, mais aussi un exemple de requête avec des vrais paramètres. C’est un bon point par rapport à mysqldumpslow puisqu’il est facile avec l’exemple de regarder le plan d’exécution donné par la commande EXPLAIN.

Intéressons-nous aux 4 questions que nous nous étions posées lors de l’article précédent, qui vont nous permettre de voir comment utiliser les méta-données des requêtes pour trier ou filtrer.

Chaque requête dans le journal possède un certain nombre de méta-données, comme le temps d’exécution ou le nombre de lignes examinées. Il existe également des méta-données dérivées, comme la moyenne des temps d’exécution pour un groupe de requêtes. Les méta-données disponibles dépendent du type de journal considéré, et tout est détaillé dans la page de la documentation consacrée aux filtres.

mysqlsla nous permet de trier les résultats du rapport selon n’importe quelle méta-donnée avec l’option --sort.

Ceci va nous permettre de répondre aux 2 premières questions :

Quel est le groupe de requêtes ayant le plus long temps de réponse ?

$ mysqlsla -lt slow --sort t_sum msandbox-slow.log

Ici l’affichage est exactement celui que nous avions sans l’option --sort. C’est normal car pour les journaux de requêtes lentes, mysqlsla applique par défaut l’option --sort t_sum !

Quel est le groupe de requêtes ayant le plus grand nombre d’occurrences ?

$ mysqlsla -lt slow --sort c_sum msandbox-slow.log
Report for slow logs: msandbox-slow.log
4 queries total, 2 unique
Sorted by 'c_sum'
Grand Totals: Time 1 s, Lock 0 s, Rows sent 1.80k, Rows Examined 64.18k

_______________________________________________ 001 ___
Count : 3 (75.00%)
Time : 186.368 ms total, 62.123 ms avg, 52.575 ms to 74.232 ms max (20.60%)
Lock Time (s) : 238 s total, 79 s avg, 60 s to 117 s max (47.89%)
Rows sent : 599 avg, 599 to 599 max (100.00%)
Rows examined : 16.04k avg, 16.04k to 16.04k max (75.00%)
Database : sakila
Users :
msandbox@localhost : 100.00% (3) of query, 100.00% (4) of all users

Query abstract:
SET timestamp=N; SELECT customer_id,COUNT(*) FROM rental WHERE return_date>'S' GROUP BY customer_id;

Query sample:
SET timestamp=1278504711;
SELECT customer_id,COUNT(*) FROM rental WHERE return_date>'2005-01-01' GROUP BY customer_id;

________________________________________________ 002 ___
Count : 1 (25.00%)
Time : 718.344 ms total, 718.344 ms avg, 718.344 ms to 718.344 ms max (79.40%)
Lock Time (s) : 259 s total, 259 s avg, 259 s to 259 s max (52.11%)
Rows sent : 0 avg, 0 to 0 max (0.00%)
Rows examined : 16.04k avg, 16.04k to 16.04k max (25.00%)
Database :
Users :
msandbox@localhost : 100.00% (1) of query, 100.00% (4) of all users

Query abstract:
SET timestamp=N; INSERT INTO rental2 SELECT * FROM rental;

Query sample:
SET timestamp=1278504762;
INSERT INTO rental2 SELECT * FROM rental;

L’utilisation des filtres va nous permettre de répondre aux 2 dernières questions. Il faut savoir que mysqlsla dispose de deux types de filtres : le premier type permet de filtrer sur les méta-données des entrées du journal alors que le second permettre de sélectionner ou d’exclure un ou plusieurs types de requêtes. Ces deux types de filtres peuvent bien sûr être combinés afin de répondre à des questions complexes.

Les filtres sur les méta-données s’écrivent avec l’option --meta-filter (ou -mf en abrégé), comme par exemple -mf "db=sakila" pour ne conserver que les requêtes sur la base sakila ou -mf "db=sakila,c_sum>5" pour ne conserver que les requêtes sur la base sakila qui apparaissent au moins 6 fois.

Il est facile avec cette option de répondre à la 3è question :
Quelles sont les requêtes qui prennent plus de x secondes ?
En positionnant x à 0.1s, on obtient le résultat suivant :

$ mysqlsla -lt slow -mf "t>0.1" msandbox-slow.log
Report for slow logs: msandbox-slow.log
1 queries total, 1 unique
Sorted by 't_sum'
Grand Totals: Time 1 s, Lock 0 s, Rows sent 0, Rows Examined 16.04k

________________________________________________ 001 ___
Count : 1 (100.00%)
Time : 718.344 ms total, 718.344 ms avg, 718.344 ms to 718.344 ms max (100.00%)
Lock Time (s) : 259 s total, 259 s avg, 259 s to 259 s max (100.00%)
Rows sent : 0 avg, 0 to 0 max (0.00%)
Rows examined : 16.04k avg, 16.04k to 16.04k max (100.00%)
Database :
Users :
msandbox@localhost : 100.00% (1) of query, 100.00% (1) of all users

Query abstract:
SET timestamp=N; INSERT INTO rental2 SELECT * FROM rental;

Query sample:
SET timestamp=1278504762;
INSERT INTO rental2 SELECT * FROM rental;


Enfin nous allons nous servir des filtres sur les requêtes (option --statement-filter ou -sf) pour répondre à la 4è question :
Comment ne conserver que les requêtes SELECT ?

$ mysqlsla -lt slow -sf "+SELECT" msandbox-slow.log
Report for slow logs: msandbox-slow.log
3 queries total, 1 unique
Sorted by 't_sum'
Grand Totals: Time 0 s, Lock 0 s, Rows sent 1.80k, Rows Examined 48.13k

________________________________________________ 001 ___
Count : 3 (100.00%)
Time : 186.368 ms total, 62.123 ms avg, 52.575 ms to 74.232 ms max (100.00%)
Lock Time (s) : 238 s total, 79 s avg, 60 s to 117 s max (100.00%)
Rows sent : 599 avg, 599 to 599 max (100.00%)
Rows examined : 16.04k avg, 16.04k to 16.04k max (100.00%)
Database : sakila
Users :
msandbox@localhost : 100.00% (3) of query, 100.00% (3) of all users

Query abstract:
SELECT customer_id,COUNT(*) FROM rental WHERE return_date>'S' GROUP BY customer_id;

Query sample:
SELECT customer_id,COUNT(*) FROM rental WHERE return_date>'2005-01-01' GROUP BY customer_id;

Et voilà, notre (courte) exploration de mysqlsla est terminée ! Ces quelques exemples ont montré que mysqlsla est extrêmement flexible comparé à mysqldumpslow, ce qui en fait un très bon choix en tant outil d’analyse de journaux MySQL. Quels sont les inconvénients de mysqlsla ? En fait, je n’en vois qu’un seul : Daniel, le développeur de mysqlsla, a annoncé au printemps que l’outil ne serait plus maintenu. La raison est simple : Daniel fait maitenant partie de l’équipe de développement de Maatkit, qui propose un outil remplaçant mysqlsla. Mais assez dit, ce sera l’objet du prochain article de cette série.

Avant toute chose, montons une petite configuration qui va nous être utile pour illustrer le fonctionnement et les limitations de chaque outil.

Prenons un serveur MySQL en version 5.1 avec la table exemple sakila et choisissons une valeur de long_query_time de 0.05s. Pourquoi une valeur aussi faible ? Tout simplement parce qu’avec une telle valeur, il n’est vraiment pas difficile des requêtes qui seront considérées comme lentes, ce qui nous permettra d’obtenir facilement un journal de requêtes lentes.

Effectuons les requêtes suivantes :

(1) mysql> SELECT customer_id,COUNT(*) FROM rental WHERE return_date > '2005-01-01' GROUP BY customer_id;
(2) mysql> SELECT customer_id,COUNT(*) FROM rental WHERE return_date > '2005-01-02' GROUP BY customer_id;
(3) mysql> SELECT customer_id,COUNT(*) FROM rental WHERE return_date > '2005-01-03' GROUP BY customer_id;
(4) mysql> CREATE TABLE rental2 LIKE rental;
(5) mysql> INSERT INTO rental2 SELECT * FROM rental;

Toutes les requêtes, sauf (4), sont lentes (si ce n’est pas le cas pour vous, il vous suffit de baisser la valeur de long_query_time).

Le journal des requêtes lentes a maintenant l’allure suivante :

# Time: 100707 14:11:51
# User@Host: msandbox[msandbox] @ localhost []
# Query_time: 0.074232 Lock_time: 0.000061 Rows_sent: 599 Rows_examined: 16044
use sakila;
SET timestamp=1278504711;
SELECT customer_id,COUNT(*) FROM rental WHERE return_date>'2005-01-01' GROUP BY customer_id;
# Time: 100707 14:12:10
# User@Host: msandbox[msandbox] @ localhost []
# Query_time: 0.052575 Lock_time: 0.000117 Rows_sent: 599 Rows_examined: 16044
SET timestamp=1278504730;
SELECT customer_id,COUNT(*) FROM rental WHERE return_date>'2005-01-02' GROUP BY customer_id;
# Time: 100707 14:12:15
# User@Host: msandbox[msandbox] @ localhost []
# Query_time: 0.059561 Lock_time: 0.000060 Rows_sent: 599 Rows_examined: 16044
SET timestamp=1278504735;
SELECT customer_id,COUNT(*) FROM rental WHERE return_date>'2005-01-03' GROUP BY customer_id;
# Time: 100707 14:12:42
# User@Host: msandbox[msandbox] @ localhost []
# Query_time: 0.718344 Lock_time: 0.000259 Rows_sent: 0 Rows_examined: 16044
SET timestamp=1278504762;
INSERT INTO rental2 SELECT * FROM rental;


Plutôt que de montrer toutes les possibilités des outils que nous allons regarder, je vous propose de nous concentrer sur quelques questions clés que l’on se pose souvent et de voir si les outils examinés permettent de répondre à ces questions :

- Comment ne garder que les groupes de requêtes qui ont entraîné le plus long temps de réponse ?
- Comment ne garder que les groupes de requêtes qui ont le plus d’occurences ?
- Comment ne garder que les requêtes qui prennent plus de x secondes ?
- Comment ne garder que les SELECT ?

La deux premières questions demandent quelques éclaircissements : qu’est-ce qu’un groupe de requêtes et pourquoi une même requête, pas trop lente mais s’exécutant plusieurs fois, serait-elle plus intéressante à analyser qu’une requête très lente ?

Premièrement, il suffit de regarder les 4 premières requêtes du listing ci-dessus pour s’apercevoir que les requêtes sont identiques à une constante près. Un appel à EXPLAIN donnera le même résultat pour toutes les requêtes, et l’amélioration de l’une d’elles les améliorera toutes.
Et deuxièmement, il faut garder à l’esprit qu’une requête exécutée 1000 fois par seconde en 1 ms chargera plus le serveur qu’une requête exécuté 1 fois par seconde en 0.5s. La recherche des requêtes qui provoquent le plus de charge est un travail aussi important que la recherche des requêtes les plus lentes.

Nous allons regarder dans cet article mysqldumpslow, qui est un script Perl que vous trouverez dans toute distribution MySQL. Ce script est assez rustique (il a été écrit en 2000 !) mais comme c’est le seul outil d’analyse fourni en standard, nous allons y jeter un oeil.

L’utilisation est très simple : il suffit de passer le chemin du journal au script, avec éventuellement des options que nous allons examiner un peu plus loin.

Voici ce que nous obtenons dans notre cas :

$ mysqldumpslow msandbox-slow.log

Reading mysql slow query log from msandbox-slow.log
Count: 1 Time=0.72s (0s) Lock=0.00s (0s) Rows=0.0 (0), msandbox[msandbox]@localhost
insert into rental2 select * from rental

Count: 3 Time=0.06s (0s) Lock=0.00s (0s) Rows=599.0 (1797), msandbox[msandbox]@localhost
select customer_id,count(*) from rental where return_date>'S' group by customer_id


Quelques commentaires sur le rapport obtenu :

- Les requêtes sont rassemblées au sein de groupes comme nous l’avons expliqué. Les constantes qui changent entre chaque requête d’un même groupe sont remplacées par un S, ce qui indique que les valeurs réelles sont des chaines de caractères ou par un N, ce qui indique que les valeurs réelles sont des nombres. Cette présentation concise est bien pratique car très souvent vous retrouverez le même type de requêtes exécuté des dizaines ou des centaines de fois, mais elle a pour inconvénient de ne pas fournir de requête directement exploitable : si vous voulez utiliser EXPLAIN, il vous faudra d’abord remplacer le S par une ‘vraie’ valeur, ce qui peut s’avérer désagréable à l’usage. Il est possible de demander à mysqldumpslow de ne pas rendre abstraites les constantes, mais dans ce cas, chaque requête d’un groupe est considérée comme unique si bien que le regroupement est perdu.

- Les champs Time, Lock et Rows reprennent les informations du journal, en mentionnant la valeur moyenne et la valeur totale (entre parenthèses) de chaque champ pour le groupe. Notez que pour les valeurs totales de Time et Lock, l’unité est la seconde, ce qui était bien adapté en 2000 quand la résolution du journal était la seconde, mais ne l’est plus du tout dans notre cas. Ces valeurs ne sont donc pas toujours exploitables.

Pouvons-nous répondre aux questions que nous nous étions posées avec mysqldumpslow ?

Pour les 2 premières (groupe de requêtes ayant le plus d’occurences et ayant entrainé le plus long temps de réponse), la réponse est oui. mysqldumpslow dispose en effet d’une option pour trier les entrées du rapport selon différents critères. Ainsi :
mysqldumpslow -s c msandbox-slow.log
trie les groupes de requêtes par nombre d’occurences. Et

mysqldumpslow -s t msandbox-slow.log
trie les groupes de requêtes par temps d’exécution. Notez que le tri se fait sur le temps total, ie le chiffre entre parenthèses. Si vous préférez que le tri se fasse sur le temps moyen il faut utiliser l’option -s at.

Pour la troisième question, portant sur les requêtes prenant plus de x secondes, nous ne pouvons pas directement obtenir le résultat. Mais nous pouvons nous en approcher en triant par temps de réponse et en utilisant l’option -t qui n’affiche que les N premiers résultats :
mysqldumpslow -s t -t 1 msandbox-slow.log
donne le groupe de requêtes ayant le temps total d’exécution le plus long. Il suffit alors de trouver, par tâtonnements successifs par exemple, la bonne valeur de l’option -t qui va nous permettre d’obtenir le résultat voulu.

Quant à la dernière question, à savoir filtrer l’affichage sur les SELECT, il existe bien une option -g qui permet de fournir un motif de filtrage, mais il ne m’a pas semblé possible dans notre cas de trouver un motif qui filtre le INSERT … SELECT sans filtrer les SELECT.

Résumons donc : mysqldumpslow est un outil très simple, toujours disponible, qui permet de produire un rapport concis mais peu précis en regroupant les requêtes similaires. Les possibilités de filtrage sont réduites au minimum, ce qui n’en fait pas un outil très pratique quand le journal contient beaucoup d’entrées. On l’utilisera donc surtout quand aucun autre outil n’est disponible, ce qui devrait être finalement assez rare, puisque rien ne vous empêche de rapatrier le journal de requêtes lentes sur votre PC pour l’analyser avec un autre outil.

Rendez-vous très bientôt pour la seconde partie de notre découverte des outils d’analyse de journaux de requêtes lentes avec mysqlsla.

Pour essayer de pallier à tous ces défauts, Darren a créé un outil : Securich, installable sur tout serveur MySQL 5.1. Cet outil permet, à l’aide d’appels à des procédures stockées, de manipuler les utilisateurs et leurs droits. Attention tout de même, le développement de Securich a commencé il y a peu de temps et le code est encore expérimental. Il reste pas mal de fonctionnalités que Darren voudrait implémenter et quelques bugs gênants : par exemple, si vous installez Securich sur un serveur contenant des utilisateurs, Securich va effacer tous les utilisateurs sans vous en avertir…

L’initiative est en tout cas intéressante car il reste effectivement pas mal de travail pour que MySQL présente autant de fonctionnalités sur les utilisateurs et les droits que d’autres produits.

Sans entrer dans le détail des commandes (voir pour cela la page sur Launchpad), MySQL Sandbox permet de créer en une ligne de commande des environnements complets et variés : un serveur, plusieurs serveurs indépendants, un maître-plusieurs esclaves…Il est même possible de créer, toujours en une seule ligne, une réplication circulaire entre N serveurs ! Le script permet également de démarrer, arrêter, effacer chacun des serveurs ainsi créés ou de faire une opération pour tous les serveurs à la fois.

Ca faisait un moment que je voulais prendre un peu de temps pour voir ce qu’il était possible de faire avec MySQL Sandbox, maintenant c’est sûr : je vais m’y mettre !

A voir également sur le sujet : un précédent article d’Arnaud, sur dbnewz bien sûr !

Non, ça n’est pas la dernière énigme à la mode pour rentrer chez Google mais plutôt une question qui pourrait devenir presque banale pour un entretien d’embauche pour un DBA MySQL à l’avenir, qui sait ?

Face à un tel défi, trois solutions :

- La fuite (mais faites une croix sur la « recommandation » Linkedin)
- Le kernel panic
- MySQL Sandbox !

Bien vu, MySQL Sandbox est la réponse la plus stratégique pour la poursuite de votre carrière.

Giuseppe Maxia (dont le blog figure dans notre blogroll, allez y jeter un oeil) est l’auteur de cet outil vraiment très pratique.  Que propose t-il ?

L’idée est d’automatiser l’installation de plusieurs serveurs MySQL sur une même machine. Rien que nous ne puissions faire manuellement c’est vrai, cependant la procédure habituelle consistant à ne pas mélanger les répertoires d’installation, choisir un port différent par serveur, appliquer mysql_secure_installation… Tout cela gagnerait à être automatisé non ? De plus ces installations manuelles sont potentiellement sources d’erreurs.

MySQL Sandbox est compatible avec toutes les versions MySQL de la 3.23 à la 6.0. Les différentes installations effectuées sont indépendantes les unes des autres, on peut ainsi faire cohabiter sans risque de conflits plusieurs versions différentes de MySQL sur une même machine (ports, répertoires et sockets indépendants).

En plus d’automatiser ces processus d’installation (gain de temps), MySQL Sandbox ne s’arrête pas là et  propose également des commandes très simples pour gérer les serveurs une fois installés.

Concernant le gain de temps, son auteur promet (notamment en page 2 de cette présentation) l’installation d’une réplication MySQL en 15 secondes. Info ou intox ?

Installation et pré-requis

Pour fonctionner MySQL Sandbox n’a besoin que des binaries des versions que vous souhaitez installer.

L’installation est très rapide :

Après avoir téléchargé MySQL Sandbox, il suffit de le décompresser dans le répertoire de votre choix :

debian:/opt# tar xzvf mysql_sandbox_2.0.11.tar.gz

On remarque alors que différentes commandes sont à notre disposition, plutôt explicites :

-rwxr-xr-x 1 501 staff  6154 2008-10-05 07:42 make_multiple_custom_sandbox
-rwxr-xr-x 1 501 staff  9062 2008-10-05 07:42 make_multiple_sandbox
-rwxr-xr-x 1 501 staff 12180 2008-10-05 07:42 make_replication_sandbox
-rwxr-xr-x 1 501 staff  5786 2008-10-05 07:42 make_sandbox

make_sandbox : installe un serveur MySQL simple
make_replication_sandbox : installe une réplication (par défaut un master, 2 slaves)
make_multiple_sandbox : pour installer plusieurs serveurs identiques
make_multiple_custom_sandbox : permet d’installer plusieurs serveurs de versions différentes

Installer une réplication

Une fois le binary récupéré, nous utilisons la commande make_replication_sandbox pour obtenir un master et deux slaves. Elle prend en paramètre le tar.gz du binary (d’autres raccourcis sont possibles, je vous renvoie au fichier README de l’outil).

debian:/opt/mysql_sandbox_2.0.11# ./make_replication_sandbox /opt/mysql-5.0.67-linux-i686-glibc23.tar.gz

La sortie écran donne ceci :
installing and starting master
installing slave 1
installing slave 2
starting slave 1
. sandbox server started
starting slave 2
.. sandbox server started
initializing slave 1
initializing slave 2
replication directory installed on /root/sandboxes/rsandbox_5_0_67

C’est fait ! L’installation en elle-même a duré un peu plus de 15 secondes, disons que les lignes de commande à taper tiennent dans ce laps de temps…

Par défaut les « bacs à sable » installés par MySQL Sandbox se placent dans $HOME/sandboxes/. Dans le cadre de notre réplication, celle-ci a été installée ici : debian:~/sandboxes/rsandbox_5_0_67#

Notre réplication est d’ores et déjà fonctionnelle, on peut le vérifier en se connectant par exemple au slave numero 2 (faites un ps-ef | grep mysql pour afficher rapidement les noms/localisations des sockets par ex)

debian:/home/user# mysql –socket=/tmp/mysql_sandbox29473.sock -p

Le password par défaut est « msandbox ».

mysql> show slave status\G
Slave_IO_State: Waiting for master to send event
Master_Host: 127.0.0.1
Master_User: msandbox
Master_Port: 29472
Connect_Retry: 60
Master_Log_File: mysql-bin.000001
Read_Master_Log_Pos: 628
Relay_Log_File: mysql_sandbox29473-relay-bin.000002
Relay_Log_Pos: 765
Relay_Master_Log_File: mysql-bin.000001
Slave_IO_Running: Yes
Slave_SQL_Running: Yes

La réplication fonctionne, le pari est tenu !

Les autres commandes disponibles

Evoquées plus haut les commandes make_multiple_custom_sandbox, make_multiple_sandbox, make_sandbox et make_replication_sandbox vous permettent d’installer différentes topologies de serveurs MySQL, du master-master au groupe de serveurs aux versions identiques ou pas.

Exemple, pour installer la version MySQL 5.1.28 sur la même machine que notre réplication précédente :

debian:/opt/mysql_sandbox_2.0.11# ./make_sandbox /opt/mysql-5.1.28-rc-linux-i686-glibc23.tar.gz

Résultat :

« Your sandbox server was installed in /root/sandboxes/msb_5_1_28. », simple non ?

D’autres commandes existent pour gérer votre installation :

start, restart, stop, clear… un suffixe « _all » pour les réplications vient s’ajouter aux commandes précédentes, ex « stop_all« .

« m » est le raccourci de master, « s1″, « s2″, etc concernent les slaves.

Ainsi pour arrêter totalement notre configuration de réplication précédente, on effectue :

debian:~/sandboxes/rsandbox_5_0_67# ./stop_all

A l’écran :

executing « stop » on slave 1
executing « stop » on slave 2
executing « stop » on master

Comme vous le voyez, MySQL Sandbox est très simple d’emploi.

Pour aller plus loin je vous conseille vivement la lecture (c’est rapide) du wiki de l’outil. Il reprend en fait le fichier README. Clair et concis vous y trouverez certainement votre bonheur : grâce à MySQL Sandbox, tester une nouvelle version de MySQL devient un jeu d’enfant.

Fonctionnement du script

Rien de plus simple que d’aller fouiller dans les entrailles de mysql_secure_installation puisque c’est un script shell.
En quelques mots, le script ne supporte aucune option et construit son propre my.cnf temporaire qu’il va ensuite passer en paramètre au client mysql :

mysql --defaults-file=fichier_my.cnf_temporaire

Le script utilise donc le client mysql pour passer ses requêtes. Les seules lignes que comptent ce my.cnf temporaire sont les suivantes, elles sont inscrites dans le fichier dès lors que vous fournissez le mot de passe root :

# mysql_secure_installation config file
[mysql]
user=root
password=xxxxxxxx

C’est tout !

Dans un tel cas, le comportement de mysql par défaut sous unix est tout simplement de chercher à se connecter au port 3306 d’un serveur localhost au travers d’une socket. Impossible donc de demander à mysql_secure_installation de se connecter à un serveur distant ou de tenter la connexion sur un autre port…

Ce manque d’options disponibles ne date pas d’hier et a déjà fait l’objet d’une remontée de « bug« , transformée en « feature request » puisqu’en effet il s’agit plutôt de cela.

Un patch a été proposé par Daniel Fischer, en charge du « bug » chez MySQL, il permet de configurer le port et la socket.

A des fins de tests j’avais pour ma part simplement rajouté quelques lignes dans mysql_secure_installation. D’abord au tout début du script :

# Assigne l'ip et le port à partir des 1er et 2nd paramètres, ex :
# mysql_secure_installation 127.0.0.1 3307
cmd_line_ip="$1"
cmd_line_port="$2"

Puis dans la fonction make_config() qui construit le my.cnf temporaire :

make_config() {
echo "# mysql_secure_installation config file" >$config
echo "[mysql]" >>$config
echo "user=root" >>$config
echo "password=$rootpass" >>$config
if [ $# == 2 ]; then
echo "host=$cmd_line_ip" >>$config
echo "port=$cmd_line_port" >>$config
fi
}

Une fois généré le my.cnf ressemble à ceci :

# mysql_secure_installation config file
[mysql]
user=root
password=xxxxxxxx
host = 127.0.0.1
port = 3307

Grâce à ces deux options supplémentaires, le client mysql se connecte par TCP et le port est pris en compte, j’ai donc pu faire « pointer » mysql_secure_installation vers mon serveur MySQL (3307).

Autre façon de faire, tout simplement taper manuellement les requêtes effectuées quasi automatiquement par mysql_secure_installation.

Les requêtes concernées

Voici les requêtes effectuées par mysql_secure_installation :

// Met à jour le password de l’utilisateur root :
UPDATE mysql.user SET Password=PASSWORD('xxxxxxxx') WHERE User='root';

// Supprime les utilisateurs anonymes
DELETE FROM mysql.user WHERE User='';

// Supprime la possibilité à un utilisateur root de se connecter à partir d’un serveur distant
DELETE FROM mysql.user WHERE User='root' AND Host!='localhost'

// Supprime la base de données test
DROP DATABASE test;

// Supprime les privilèges associés à la base test
DELETE FROM mysql.db WHERE Db=’test’ OR Db=’test_%’

// Applique les changements effectués précedemment concernant la gestion des droits
FLUSH PRIVILEGES

Il existe d’autres façons de faire, comme par exemple utiliser mysqladmin :

mysqladmin -u root password 'new-password'

De même, pour modifier le password d’un utilisateur, plutôt que de mettre à jour directement les tables systèmes de mysql, il est conseillé de passer par les commandes suivantes :

mysql> SET PASSWORD FOR 'jeffrey'@'%' = PASSWORD('biscuit');
ou
mysql> GRANT USAGE ON *.* TO 'jeffrey'@'%' IDENTIFIED BY 'biscuit';

La commande FLUSH PRIVILEGES est alors inutile.

On obtient :

Benchmark
Average number of seconds to run all queries: 1.121 seconds
Minimum number of seconds to run all queries: 1.015 seconds
Maximum number of seconds to run all queries: 1.265 seconds
Number of clients running queries: 200
Average number of queries per client: 5

Nous avons ici 200 clients concurrents dont on limite le nombre de requêtes à 1000 au total, ce qui nous donne environ 5 requêtes par client.

En rajoutant la clause –csv et une concurrence variable :

undercat@u200:/usr/local/mysql5125$ ./bin/mysqlslap --user=mysql --csv=/tmp/slap.csv --concurrency=1,10,50,100,200 --iterations=10 --query="USE world;SELECT SQL_NO_CACHE ci.name, co.name from City ci, Country co where ci.countrycode = co.code and ci.name like 'c%'"

J’utilise ici SQL_NO_CACHE afin de ne pas placer la requête dans le query cache, ce qui fausserait les tests.

L’option –csv couplé à openoffice / impress par exemple, permet de créer rapidement un graphique issu de nos tests. Ci-dessous le csv généré et le graphique  :

undercat@u200:/tmp$ cat slap.csv
,mixed,0.002,0.000,0.004,1,1
,mixed,0.015,0.011,0.027,10,1
,mixed,0.063,0.061,0.068,50,1
,mixed,0.133,0.122,0.205,100,1
,mixed,0.245,0.105,0.298,200,1



supersmack

Disponible sur http://vegan.net/tony/supersmack/, cet outil n’évolue plus depuis trois ans mais il reste intéressant ! Initialement développé par Sasha Pachev (un ancien de chez MySQL), puis retouché par plusieurs autre contributeurs dont Jéremy Zawodny, supersmack est moins intuitif que mysqlslap mais il se rattrape par ailleurs puisqu’il est plus largement disponible (pas seulement sur MySQL 5) et offre des réglages plus fins. Il est notamment possible de construire dynamiquement une requête à partir d’un « dictionnaire »… supersmack peut en effet « piocher » dans un fichier texte une liste d’identifiants par exemple, nous verrons comment.

Note : en plus des avantages suscités, supersmack peut également être interfacé avec PostgreSQL et Oracle.

Installation de supersmack

Le binaire n’étant pas distribué avec mysql, nos tests sous supersmack vont nécessiter quelques étapes supplémentaires.

Première étape, récupérer les sources :

wget http://vegan.net/tony/supersmack/super-smack-1.3.tar.gz

puis

./configure --with-mysql=/usr/local/mysql5125

A ce stade vous devriez voir s’afficher ceci :

Building with the following options:

MySQL Support………………… yes
PostgreSQL Support……………. no
Oracle Support……………….. no

Thanks for using super-smack!

Faites suivre d’un make, et make install : supersmack devait être opérationnel.

Si ça n’est pas le cas, veillez à avoir installé les paquets suivants (ubuntu) :

apt-get install libmysqlclient15-dev
apt-get install build-essential

supersmack : fonctionnement

Le répertoire /smacks contient deux exemples : select-key.smack et update-select.smack.
Prenons comme base le premier fichier et voyons comment le configurer.

Evoquée en introduction, supersmack dispose d’une fonctionnalité très pratique dans certains cas, il s’agit du « dictionnaire ». Ce dernier permet de construire des requêtes dynamiques, comme si votre requête était directement issue de votre script. Exemple :

SELECT Capital FROM Country WHERE Code = « $code_pays »

Difficile d’exécuter une telle requête avec mysqlslap… Il faudrait s’arranger pour récupérer le code pays via une jointure mais dans certains cas cette information n’est tout simplement pas disponible. Il se peut que vous souhaitiez exécuter une série de requête construites dynamiquement à partir d’informations contenues dans un fichier.

Construisons à titre d’exemple un tel dictionnaire à partir de l’une de nos tables (la fameuse base « world » est encore une fois mise à contribution).

mysql> select distinct(countrycode) into outfile '/tmp/code_pays_pop_under_2M.txt' from City where population < 2000000;

On a ainsi exporté dans /tmp/code_pays_under_2M.txt la liste des codes pays qui possèdent des villes inférieures à 2 000 000 d’habitants. Le fichier contient des lignes stockés sous la forme suivante :

AFG
NLD
ANT
…

Notre « dictionnaire » désormais construit, supersmack pourra y piocher les informations requises et construire dynamiquement nos requêtes.

Voyons maintenant à quoi ressemble un fichier .smack. Nous partons ici du fichier select-key.smack pour construire un dbnewz.smack allégé pour notre exemple :

//define a dictionary
dictionary "code_pays"
{
type "rand"; // autres valeurs possibles : "seq" ou "unique"
source_type "file"; // nous utiliserons le fichier contenant nos codes pays
source "/tmp/code_pays_pop_under_2M.txt"; // emplacement du fichier "dictionnaire"
delim ","; // take the part of the line before ,
file_size_equiv "45000"; // if the file is greater than this
//divide the real file size by this value obtaining N and take every Nth
//line skipping others. This is needed to be able to target a wide key
// range without using up too much memory with test keys
} 

//define a query
query "find_capital"
{
query "SELECT SQL_NO_CACHE ci.Name, ci.Population
FROM City ci
INNER JOIN Country co ON ci.CountryCode = co.Code
WHERE co.Code = '$code_pays'";
type "req_code_pays"; // libellé de votre requete, permet de s'y retrouver dans les resultats
has_result_set "y"; // On attend des resultats (a la difference d'un UPDATE par ex).
parsed "y"; // signale que supersmack doit construire dynamiquement la requete a partir du dictionnaire
}

// define database client type
client "dbnewz"
{
user "root"; // connect as this user
pass "XXXXXXX"; // use this password
host "localhost"; // connect to this host
db "world"; // switch to this database
#socket " /var/run/mysqld/mysqld.sock";  // j'utilise ici la valeur de SHOW VARIABLES LIKE 'socket';
query_barrel "1 find_capital"; // Execute 1 fois la requete "find_capital" a chaque iteration.
}

main
{
dbnewz.init(); // initialize the client
dbnewz.set_num_rounds($2); // le 2eme argument recu par supersmack est le nombre d'iterations.
dbnewz.create_threads($1); // permet de definir combien de clients simultanés l'on souhaite.
dbnewz.connect();
dbnewz.unload_query_barrel(); // for each client fire the query barrel
dbnewz.collect_threads();
dbnewz.disconnect();
}

Il est également possible pour supersmack de créer automatiquement les tables dans lesquelles se dérouleront les tests, ouvrez le fichier select-key.smack pour davantage d’informations, il fournit la syntaxe relative à cette fonctionnalité.

Nous pouvons désormais lancer le test, ici 50 clients concurrents et 1000 itérations :

root@u200:/opt/super-smack-1.3/smacks# super-smack dbnewz.smack 50 1000

Query Barrel Report for client dbnewz
connect: max=888ms  min=7ms avg= 213ms from 50 clients
Query_type    num_queries    max_time    min_time    q_per_s
req_code_pays    50000    41    1    1327.08

Nous avons ici obtenu en moyenne 1327 requêtes / seconde pour cette requêtes et 50 clients concurrents entre le début et la fin de nos tests.

Connecté sur le serveur MySQL en question, on observe via un SHOW FULL PROCESSLIST des requêtes du type :

SELECT SQL_NO_CACHE ci.Name, ci.Population
FROM City ci
INNER JOIN Country co ON ci.CountryCode = co.Code
WHERE co.Code = 'LKA'

Le code ‘LKA’ a été remplacé par supersmack lui-même, le dictionnaire a donc bien fonctionné.

Vous venez de faire connaissance avec ces deux outils de benchmark (si ça n’était pas déjà fait), pensez à les utiliser lors de vos prochaines évaluations de performance (serveur / requêtes). Il est en effet toujours appréciable de pouvoir qualifier la situation de départ afin de mesurer l’étendue des progrès effectués par la suite.

Cet outil n’est pas nouveau, son successeur officiel est même déjà connu, il s’agit de MySQL Workbench. Celui-ci n’étant pas encore disponible sous linux, nous utiliserons son ancêtre et plus particulièrement sa fonctionnalité de « reverse engineering » : une fois connecté à votre base, DBDesigner 4 va générer sous forme graphique vos tables, leurs descriptions, et si tout se passe bien, les relations entre vos tables.

Installation (fastidieuse) sous linux

L’installation de DBDesigner 4 sous linux (ubuntu 8.04 pour ma part) n’est pas de tout repos… J’ai rencontré toutes les erreurs potentielles croisées sur les différents tutoriels sur le sujet. Résultat des courses : il apparaît plus simple d’installer DBDesigner 4 en passant par wine, les problèmes de librairies manquantes disparaissent et les polices sont plus travaillées.
Si néanmoins vous souhaitez vous passer de wine, voici quelques pistes : http://wiki.splitbrain.org/dbdesigner et un how-to tiré des forums ubuntu. Des solutions sont proposées pour ces fameuses libraries manquantes, cela dit j’avais toujours des problèmes malgré ces manipulations.

Une fois wine installé (apt-get install wine), téléchargez simplement le fichier d’installation de DBDesigner 4 pour windows.

L’installation s’effectue simplement :

root@u200:/opt# wine DBDesigner4.0.5.6_Setup.exe

Si vous êtes sous MySQL 5, vous devez modifier le mot de passe de l’utilisateur à partir duquel vous vous connectez à DBDesigner de la façon suivante :

mysql> SET PASSWORD FOR 'dbdesign'@'localhost' = OLD_PASSWORD('dbdesign');

Depuis sa version 5, MySQL utilise en effet un mécanisme d’authentification qui est incompatible avec les versions précédentes (< 4.1). Afin d’assurer une rétro compatibilité, il est néanmoins possible avec MySQL 5 d’utiliser la commande « OLD_PASSWORD« , le format utilisé pour le mot de passe sera alors compatible avec MySQL 4 (short hash contre long hash pour MySQL 5).

Lancement de l’application:

root@u200:~/.wine/drive_c/Program Files/fabFORCE# wine DBDesigner4.exe

Obtenir le schéma de sa base

Pour générer votre MCD, et selon votre langue d’installation :

- Choisissez le menu « Database », puis « Reverse Engineering ».

- Selectionnez une connexion à la base de données ou créez la vôtre : « Localhost 127.0.0.1″ par exemple, puis renseignez vos login/pwd et validez, n’oubliez pas la commande « OLD_PASSWORD » si besoin.

- La fenêtre « Reverse Engineering » affiche alors la liste des tables de la base, par défaut elles sont toutes cochées. Remarquez un peu plus bas l’option « Build Relations« , cochez-là puis indiquez « Build Relations based on primary keys ». C’est grâce à cette option que vous indiquez à DBDesigner de relier vos tables entre elles (si possible).

- Si tout s’est bien passé, l’étape suivante affiche vos tables, leurs champs, leurs clés…

Remarques :

- DBDesigner ne parvient pas à joindre les tables de la base « world » entre elles, les noms des clés primaires sont différents et les clés étrangères absentes de la définition des tables (MyISAM), vous pouvez néanmoins rajouter vos différentes relations à la main.

- En ce qui concerne la base « sakila » les relations entre les tables sont bien présentes :

Vous pouvez à présent d’un seul coup d’oeil construire vos requêtes, les jointures entre les tables sont ici évidentes.

- La console dans laquelle vous lancez DBDesigner va peut-être contenir quelques messages d’erreur du type:

QPixmap::operator=: Cannot assign to pixmap during painting
QPopupMenu: (unnamed) Popup has invalid menu item

Cela n’a pas bloqué le comportement de l’application lors de mes tests cependant DBDesigner a la facheuse tendance à ouvrir des boites de dialogues sous les fenêtres déjà existantes, n’hésitez pas notamment lors de votre connexion à la base, à déplacer vos fenêtres (la principale et celle consacrée au reverse engineering) pour faire apparaître la boîte de dialogue vous invitant à renseigner vos identifiants de connexion. A noter qu’il existe là aussi des solutions pour régler ce problème de pop-up, cf les tutoriels cités en début d’article.

Pour explorer les autres fonctionnalités de DBDesigner 4, ou bien encore tester (sous windows uniquement pour le moment) son successeur MySQL Workbench, rendez-vous sur fabforce.net, vous y trouverez les fichiers d’installation, des captures d’écran et de la documentation.

Si vous connaissez d’autres outils intéressants disposant d’un module de « reverse engineering », partagez-les dans les commentaires, ils sont là pour ça.

DorsalSource est une idée qui a germée peu après l’annonce fin 2006 des versions « communauté » et « entreprise », MySQL ne fournissant plus les binaires aussi souvent pour la version communauté, version pour tout utilisateur sans contrat de support.

A la conférence MySQL, le projet de collaboration pour satisfaire les besoins de la communauté sur les mises à jour, les patches ou bugfix a été officiellement lancé. DorsalSource. Le jour même 40 versions des binaires 40 pour MAC OS X, Linux et Windows étaient déjà disponibles au téléchargement.

Nous attendons impatiemment les évolutions à venir de DorsalSource ( je ne suis pas encore authorisé à en parler ) et attendant je vais pouvoir faire le malin avec mon tshirt DorsalSource .

Cet outil est sensé me simplifier la vie pour migrer des bases Sybase, Informix et DB2 vers de l’Oracle. (Oracle9i et Oracle10g). Il s’occupe du schéma, des triggers, des procédures stockées. Serait ce l’outil magique? Bon il n’est pas encore capable de modifier votre application client si vous utiliser du SQL spécifique à votre SGDB mais qui sait.

Premier bémol, il ne semble supporter que du DB2 sous Windows. En 8 ans de carrière je n’ai encore jamais joué avec des serveurs DB2 sous Windows, de l’AIX du Linux oui. Pour moi Windows s’arrête avec MSSQL serveur. La suite de cet aventure pour les mois à venir.