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.

Il s’agit ici du type de schéma que nous avons tous griffonné pour un collègue ou soi-même afin de clarifier un processus : pas de powerpoint, pas de visio mais un brouillon, un stylo, et hop.

La règle du jeu : le schéma doit dans l’idéal se suffire à lui-même et ne pas forcément engendrer un billet qui ferait office de « légende »… Néanmoins quelques mots d’explications ne sont parfois pas de trop, même à côté d’un schéma, donc tout est possible.

La « richesse » des schémas/dessins viendra également des commentaires qui leur seront attribués, de la même façon que les commentaires enrichissent les billets d’un blog en ajoutant au billet initial les questions/retours d’expérience des lecteurs. Je vous encourage donc à poster des commentaires les concernant : questions, remarques, etc.

Voici ce que donne cette première tentative…

Que pensez-vous de ce premier schéma/prototype ? Lisible ? La résolution ? Des remarques ?

J’attends vos retours/suggestions afin de déterminer si l’idée vous plaît, auquel cas ce premier essai pourrait se transformer en une série au doux nom de « Dessine-moi MySQL » qui pourrait s’avérer très sympa… à condition bien sûr de savoir déchiffrer mes hiéroglyphes, ce qui je vous l’accorde représente un certain challenge.

A vos claviers !

Quand un slave se connecte au master, par la entendez le Slave I/O thread, il enregistre la valeur dm = SELECT UNIX_TIMESTAMP() ce qui revient à connaître la date actuelle du master (dm: date master) puis fait la même chose sur lui même ds = SELECT UNIX_TIMESTAMP() (ds: date slave). De la il calcule la différence D = ts – tm.

Dans les log de réplication (binlog) sont enregistrés les dates d’exécutions de chaque requête. Ainsi lorsque le Slave SQL thread rejoue ces même requêtes, il calcule:

seconds_behind_master = SELECT UNIX_TIMESTAMP() sur le slave – date d’exécution de la requête sur le master – D

Premier point, ce paramètre nous donne la différence entre le moment où une requête est mise dans le relay log et le moment ou elle a été executé sur le master. En aucun cas nous connaissons le temps qu’il a fallu pour la récupérer du master. Donc imaginons maintenant que votre slave est lent à les récupérer mais une fois récupérées, elles soient exécutées instantanément… Votre valeur Seconds_behind_master sera 0 alors qu’en réalité votre slave peut ne pas être à jour.

Quand le SQL thread est au niveau, pas d’autre relay log à jouer, Seconds_behind_master sera 0. Si votre connexion réseau est rapide, le slave I/O thread sera proche du masteret donc ce champ vous donnera une bonne approximation. Dans le cas contraire, le valeur sera 0 car le SQL thread est en attente du I/O thread et non car votre slave est à jour.

NULL est un autre valeur possible pour ce champ, si l’I/O thread est en pause ou en train de se reconnecter, celle valeur est mise à NULL.

En résumé, celle valeur est informative et peut éventuellement vous mettre sur la piste d’un problème réseau mais elle n’est pas à prendre pour argent comptant.

Un slave n’enregistre pas dans son journal (ses binlogs) les commandes qu’il reçoit de son master. Donc dans notre cas (B) est à jour mais (C) n’a aucun moyen de connaître les commandes car (C) lit juste les binlogs de (B).

En rajoutant log-slave-updates dans le my.cnf de (B), il écrira toutes les commandes dans les binlogs et (C) sera ainsi à jour.

C’est aussi un bon moyen pour contrôler toutes les commandes exécutées sur votre slave. Cela m’a permis un jour de trouver la source d’un problème. Un client mal configuré venait mettre à jour un slave et faisait ainsi planter la réplication.

Il est conseillé en général de dédier un disque pour ces fichiers car beaucoup d’écriture entraîne une baisse de vos performances. Dans le cas qui nous intéresse, l’activité du CPU m’a très étonné. En effet jusqu’à 60% du temps CPU étaient utilisé par ‘USER’ juste en activant la réplication.

Suite à cela j’ai décidé avec mon ami Laurent de faire un peu de profiling… sommes nous un peu DBCSI? (comprenez database crime scene investigators ) Pour cela un outil intéressant est oprofile.

Pour tester ça, nous avons un DELL 2850 sous RHEL4 1 disque (hélas) et 2Go de RAM. Le programme de test à été exécuté pendant 30 minutes, et voila les résultats surprenant.

• Avec binlog

Profiling through timer interrupt
samples % image name symbol name
1680924 47.9708 /lib64/tls/libc-2.3.4.so __ctype_toupper_loc
1651101 47.1197 /usr/libexec/mysqld dict_create_foreign_constraints_low
54986 1.5692 /usr/libexec/mysqld yylex(void*, void*)
9083 0.2592 /usr/libexec/mysqld __do_global_ctors_aux
8541 0.2437 /usr/libexec/mysqld buf_pool_init
8284 0.2364 /lib64/tls/libc-2.3.4.so memcpy
5918 0.1689 /usr/libexec/mysqld my_snprintf_ucs2
4934 0.1408 /usr/libexec/mysqld log_buffer_flush_to_disk
4640 0.1324 /usr/libexec/mysqld my_strntod_ucs2
4268 0.1218 /usr/libexec/mysqld MD5Transform
3650 0.1042 /usr/libexec/mysqld my_parse_charset_xml

• Sans binlog

Profiling through timer interrupt
samples % image name symbol name
34847 9.7094 /usr/libexec/mysqld __do_global_ctors_aux
30416 8.4748 /lib64/tls/libc-2.3.4.so memcpy
30041 8.3703 /usr/libexec/mysqld buf_pool_init
20615 5.7439 /usr/libexec/mysqld my_snprintf_ucs2
17065 4.7548 /usr/libexec/mysqld my_strntod_ucs2
16656 4.6408 /usr/libexec/mysqld log_buffer_flush_to_disk
14908 4.1538 /usr/libexec/mysqld dict_create_foreign_constraints_low
9154 2.5506 /lib64/tls/libpthread-2.3.4.so pthread_mutex_trylock
8354 2.3277 /lib64/tls/libc-2.3.4.so __ctype_toupper_loc
8216 2.2892 /lib64/tls/libpthread-2.3.4.so pthread_mutex_unlock
5347 1.4898 /usr/lib/debug/lib/modules/2.6.9-22.ELsmp/vmlinux copy_user_generic
3380 0.9418 /usr/libexec/mysqld buf_flush_try_page

On remarque que lorsque les logs binaires sont activés, beaucoup de temps CPU est utilisé par cette fonction « dict_create_foreign_constraints_low ». Ce qui très étrange, car elle est supposé être utilisé lorsque d’une modification de DDL (création de tables,…) pour effectuer des vérifications sur les clés étrangères. Et sur cette application, même si nous sommes en InnoDB, il n’y en a aucune.

Des que nous aurons un peu de temps devant nous, nous referons le test sous MySQL 5.0.