Commençons par le plus simple : que contient ce journal ? Facile : toutes les erreurs rencontrées par le serveur. Mais vous y trouverez également d’autres informations, comme par exemple les arrêts et démarrages du serveur. Par défaut, l’option log_warnings est activée (valeur à 1), ce qui signifie que les messages d’avertissement sont également présents. Si vous ne souhaitez pas avoir les message d’avertissement, il vous suffit de positionner cette variable à 0. A l’inverse, si vous voulez avoir des informations supplémentaires, telles que les problèmes réseaux, vous pouvez positionner cette variable à 2.
Pour les utilisateurs de Windows, sachez que certaines données sont reprises dans le journal des événements.

Voilà pour la partie facile. Les choses se compliquent déjà un peu plus quand on cherche à savoir où se trouve le fichier d’erreur… A priori pourtant, ce n’est pas difficile, il suffit de regarder du côté de la variable log_error. Celle-ci peut prendre 3 valeurs :

• chaîne vide (par défaut), le journal d’erreurs s’appelle alors [hostname].err et se trouve dans le répertoire de données
• un nom d’un fichier, dans ce cas, le journal se trouve dans le répertoire de données et porte le nom indiqué
• le chemin absolu d’un fichier, alors le journal se trouve à l’emplacement indiqué

Cela signifie que dans les deux premiers cas, il faut également regarder la variable datadir pour connaître l’emplacement du répertoire de données.

Deux petites remarques au passage :

• il n’est pas possible de désactiver le journal d’erreurs
• le journal est toujours écrit dans un fichier et jamais dans une table comme vous pouvez le faire pour la general log et la slow log à partir de la version 5.1

En réalité, c’est encore un peu plus compliqué. Dans certaines distributions Linux, comme Debian ou Ubuntu par exemple, le journal passe par syslog. Les événements ont alors un tag mysqld_safe ou mysqld selon leur origine. La raison en est une petite variable bien cachée dans un fichier … lui aussi bien caché : si vous regardez dans le répertoire /etc/mysql/conf.d/, vous y trouverez un fichier mysld_safe_syslog.cnf qui contient simplement la directive suivante :
[mysqld_safe]
syslog

A partir de la version 5.1, la variable syslog est disponible en standard (mais pas pour Windows bien sûr !).

Est-ce un bon choix d’utiliser cette variable syslog ? La réponse va sans doute dépendre de votre manière de surveiller les logs : si vous ne vous intéressez qu’à MySQL, devoir retrouver les événements liés à MySQL parmi tous les autres événements va être laborieux, mais au contraire, si MySQL n’est qu’une application parmi tant d’autres, il vous sera bien agréable d’avoir un journal d’erreurs dans un format standard.

Subtilité ou complication supplémentaire, vous pouvez même avoir votre journal d’erreur en double, une première fois via syslog et une deuxième fois dans le fichier d’erreur classique. Comment faire ? Il vous faut activer en même temps la variable syslog et la variable log_error :
[mysqld_safe]
syslog

[mysqld]
log_error = error.log

Quel est l’intérêt ? A vrai dire, je n’en vois pas vraiment …

Voyons maintenant quelques bonnes pratiques.

La première question à vous poser, en supposant que vous êtes sous Linux et que votre version ou votre distribution vous en donne la possibilité, est de savoir si vous souhaitez utiliser syslog ou pas.

Si oui, il vous suffit de positionner la variable syslog dans la section [mysqld_safe] du fichier my.cnf et la configuration est terminée.

Sinon, si vous laissez la variable à vide ou si vous mettez un nom de fichier, votre journal d’erreurs va se trouver dans le répertoire de données, ce qui n’est pas souhaitable. Même s’il existe peu de chances que le journal d’erreurs remplisse tout l’espace disque disponible dans le répertoire de données (c’est plus plausible avec les logs bins), il est en effet toujours mieux de ne pas mélanger les torchons et les serviettes : les données avec les données et les logs avec les logs ! De plus, vous risquez d’avoir des problèmes de droit : dans le répertoire de données, seul les utilisateurs du groupe mysql ont le droit d’accéder à ce fichier, alors que vous aurez peut-être besoin de donner des accès à d’autres utilisateurs sans pour autant leur laisser un accès aux données. Il est donc conseillé de saisir un chemin absolu vers un fichier, par exemple :
[mysqld]
log_error = /var/log/mysql/error.log

Un autre aspect à prendre en compte est celui de la rotation. En effet, si vous n’y faites pas attention, la rotation des logs risque de vous faire perdre une grande partie des informations du journal d’erreurs !
Le premier point à constater est que la rotation du journal d’erreurs ne se fait pas automatiquement au démarrage du serveur ou lorsque la taille du fichier dépasse une certaine limite. La seule possibilité consiste à exécuter la commande FLUSH LOGS (qui affecte également les autres logs).

Quand vous utilisez syslog, par défaut, votre système fait une rotation tous les jours, et les logs sont purgées après 7 jours. Sauf si vous prenez des mesures pour sauvegarder les logs après leur rotation, vous avez donc seulement le journal des erreurs des 7 derniers jours à votre disposition.

Mais quand vous utilisez un journal d’erreurs classique, la situation est beaucoup plus dangereuse ! En effet, l’appel de la commande FLUSH LOGS créé un nouveau journal d’erreurs et sauvegarde l’ancien dans un fichier avec le suffixe -old. Et si vous aviez déjà un fichier -old, celui-ci est purement et simplement supprimé !

Petite démo :
stephane@cilaos:/var/lib/mysql$ ll | grep error
-rw-rw---- 1 ... 2817 2010-04-16 10:46 error.log
-rw-rw---- 1 ... 939 2010-04-16 10:45 error.log-old

J’ai bien un journal d’erreurs ainsi qu’un journal en -old. J’exécute FLUSH LOGS pour voir l’effet :

stephane@cilaos:/var/lib/mysql$ mysql -uroot -p -e "FLUSH LOGS"
Enter password:
stephane@cilaos:/var/lib/mysql$ ll | grep error
-rw-rw---- 1 ... 0 2010-04-16 10:47 error.log
-rw-rw---- 1 ... 2817 2010-04-16 10:46 error.log-old

Et voilà, mes anciennes erreurs sont perdues à tout jamais…

Conclusion : mieux vaut sauvegarder régulièrement son journal d’erreurs car nul n’est à l’abri d’un FLUSH LOGS non prévu.

Notre exploration du journal d’erreurs est terminée, et nous reviendrons bientôt sur un autre journal extrêmement important : le journal des requêtes lentes.

Quand vous ouvrez une console, le prompt est par défaut :

mysql>


Pour le modifier, une première possibilité consiste à utiliser la commande prompt (ou son équivalent \R) suivie d’une ou plusieurs options. Exemple :

mysql> prompt \u\h
PROMPT set to '\u\h'
rootlocalhost

Ce premier exemple permet d’indiquer l’utilisateur connecté ainsi que la machine. C’est déjà intéressant, mais pas très lisible, puisque tout est collé. Heureusement vous pouvez ajouter n’importe quels caractères pour séparer les différents champs du prompt. Il sera donc plus lisible de saisir le prompt suivant :

rootlocalhostprompt \u@\h>
PROMPT set to '\u@\h> '
root@localhost>

Notez l’espace après le >, bien pratique pour séparer le prompt des commandes que vous allez saisir.
Parmi les options très utiles du prompt, en plus de \u et \h, vous avez \v (version du serveur) et \d (base sélectionnée). Les options disponibles sont nombreuses et si vous souhaitez en avoir la liste complète, le mieux est de regarder dans la page de man consacrée à mysql ou de consulter la documentation en ligne.

Est-il possible de faire en sorte qu’une telle modification du prompt soit permanente ? Oui ! Et pour cela, il existe plusieurs solutions. La première consiste à enregistrer le prompt dans la variable MYSQL_PS1 :

$ export MYSQL_PS1="\u@\h \d > "
$ mysql -uroot -p
root@localhost (none) >


La seconde solution consiste à saisir le prompt dans la section [mysql] du fichier my.cnf ou my.ini. Dans ce cas, vous devrez penser à doubler les backslash :

[mysql]
prompt = "\\u@\\h \\d > "

Si vous êtes sous Linux, vous pouvez également placer ce même code dans le fichier .my.cnf (dans le HOME de votre utilisateur). Cette solution est intéressante car elle permet d’obtenir le résultat voulu sans avoir à modifier le fichier global my.cnf, pour lequel vous n’aurez pas nécessairement les droits de modification.

Notez que si vous êtes un utilisateur de MySQL Sandbox, le prompt sera automatiquement et intelligemment modifié pour que vous ne soyez pas perdu parmi toutes vos instances. Par exemple, j’obtiens le prompt suivant en me connectant sur un des nœuds d’une paire master-master :

$ ./n1
node1 [localhost] {msandbox} ((none)) >


Maintenant, vous n’aurez plus d’excuse si vous vous trompez de console … !

Pour plus de clarté, nous allons nous intéresser à 2 tables dont le schéma est le suivant :

mysql> CREATE TABLE parent (
id INT NOT NULL AUTO_INCREMENT,
data varchar(20) NOT NULL,
PRIMARY KEY (id)
) ENGINE = InnoDB;

et

mysql> CREATE TABLE enfant (
id int(11) NOT NULL AUTO_INCREMENT,
id_parent int(11) NOT NULL,
data2 varchar(20) NOT NULL,
PRIMARY KEY (id),
CONSTRAINT fk_parent FOREIGN KEY (id_parent) REFERENCES parent (id)
) ENGINE=InnoDB

Remplissons ces 2 tables avec quelques lignes pour faire nos tests :

mysql> INSERT INTO parent (data) VALUES ('test');
mysql> INSERT INTO enfant (id_parent,data2) VALUES (1,'test');
mysql> INSERT INTO enfant (id_parent,data2) VALUES (1,'test2');

Que se passe-t-il maintenant quand nous essayons de supprimer la ligne de la table parente ?

mysql> DELETE FROM parent WHERE id = 1;
ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails (`test`.`enfant`, CONSTRAINT `fk_parent` FOREIGN KEY (`id_parent`) REFERENCES `parent` (`id`))

Eh oui ! Quand on n’indique pas de clause particulière dans la définition de la clé étrangère, cela équivaut à indiquer la clause NO ACTION (ON DELETE NO ACTION ON UPDATE NO ACTION). Et cette action interdit la modification d’une ligne de la table parente si cette ligne est en liaison avec la table enfant par la clé étrangère. A noter : le mot-clé RESTRICT est équivalent à NO ACTION.

Testons maintenant le 3è mot-clé possible : SET NULL. Et pour cela, modifions la structure de la table enfant :

mysql> ALTER TABLE enfant DROP FOREIGN KEY fk_parent;
mysql> ALTER TABLE enfant ADD CONSTRAINT fk_parent FOREIGN KEY (id_parent) REFERENCES parent(id) ON DELETE SET NULL ON UPDATE SET NULL;
ERROR 1005 (HY000): Can't create table 'test.#sql-4fb_33' (errno: 150)

Ici MySQL ne permet pas la création de la clé étrangère. En effet, avec SET NULL, si la table parente est modifiée, les lignes liées par la clé étrangère sont mises à NULL dans la table enfant. Ceci ne fonctionne bien sûr que pour des colonnes qui peuvent être NULL, ce qui n’est pas le cas dans notre exemple. Vous pouvez vérifier le fonctionnement de SET NULL en ajoutant une nouvelle colonne autorisant les NULL dans nos 2 tables.

Enfin, pour terminer, la célèbre action CASCADE transmet la modification faite sur la table parent vers la table enfant :

mysql> ALTER TABLE enfant ADD CONSTRAINT fk_parent FOREIGN KEY (id_parent) REFERENCES parent(id) ON DELETE CASCADE ON UPDATE CASCADE;
mysql> SELECT * FROM enfant;


+----+-----------+-------+
| id | id_parent | data2 |
+----+-----------+-------+
|  1 |         1 | test  |
|  2 |         1 | test2 |
+----+-----------+-------+


mysql> UPDATE parent SET id = id +1;
mysql> SELECT * FROM enfant;


+----+-----------+-------+
| id | id_parent | data2 |
+----+-----------+-------+
|  1 |         2 | test  |
|  2 |         2 | test2 |
+----+-----------+-------+

Il est également possible d’avoir des actions différentes pour la suppression et pour la mise à jour (par exemple ON DELETE RESTRICT ON UPDATE CASCADE).

Il reste encore 2 petites précisions à apporter :

• certains SGBD (c’est le cas de PostgreSQL par exemple) font une différence entre RESTRICT et NO ACTION : RESTRICT vérifie immédiatement l’intégrité référentielle alors que NO ACTION vérifie l’intégrité à la fin de l’exécution de la requete, ce qui laisse le temps à d’éventuelles triggers d’être déclenchés et à la contrainte d’intégrité d’être finalement respectée.
• il existe dans la norme SQL une 5è action possible : SET DEFAULT, mais elle n’est pas supportée par MySQL

Nous repartons de la table du post précédent, remplie avec 500 000 enregistrements :
CREATE TABLE product (
product_id int(11) NOT NULL AUTO_INCREMENT,
category_id int(11) NOT NULL DEFAULT 0,
reference varchar(20) NOT NULL DEFAULT '',
name varchar(25) NOT NULL DEFAULT '',
sold int(11) NOT NULL DEFAULT 0,
PRIMARY KEY (product_id)
) ENGINE=MyISAM;

Nous voulons, à partir de cette table de produits, trouver pour chaque catégorie le produit qui s’est le plus vendu.

Première idée : raisonner en terme de boucle, c’est-à-dire demander au SGBD de retrouver pour chaque catégorie le produit qui s’est le plus vendu. Cela donne en SQL la requête suivante :

mysql> SELECT sql_no_cache pdt.*
FROM product pdt
WHERE sold =
(SELECT MAX(sold) FROM product
WHERE category_id = pdt.category_id);


On note la sous-requête corrélée, qui traduit en SQL notre idée de boucle à travers l’ensemble des catégories.

Temps d’exécution : très long… en effet j’ai arrêté l’exécution de la requête au bout de 20 mn, et toujours pas de résultat en vue à ce moment-là ! Un bon index est sans doute nécessaire…

Examinons le résultat de la commande EXPLAIN :

mysql> EXPLAIN SELECT...\G
***************** 1. row *****************
id: 1
select_type: PRIMARY
table: pdt
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 500000
Extra: Using where
***************** 2. row *****************
id: 2
select_type: DEPENDENT SUBQUERY
table: product
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 500000
Extra: Using where
2 rows in set (0,00 sec)


Effectivement, ce n’est pas fameux : pour chaque ligne de la table product, MySQL va exécuter la sous-requête, qui elle-même fait un scan complet de la table product… On est dans une situation bien pire qu’un CROSS JOIN, ce qui explique la lenteur constatée.

Un index composite sur (category_id, sold) va bien nous permettre d’améliorer la sous-requête…

mysql> ALTER TABLE product add index idx_category_sold (category_id,sold);
mysql> EXPLAIN SELECT ...\G
***************** 1. row *****************
id: 1
select_type: PRIMARY
table: pdt
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 500000
Extra: Using where
***************** 2. row *****************
id: 2
select_type: DEPENDENT SUBQUERY
table: product
type: ref
possible_keys: idx_category_sold
key: idx_category_sold
key_len: 4
ref: test.pdt.category_id
rows: 500
Extra: Using index
2 rows in set (0,00 sec)


… mais il n’existe pas de moyen d’améliorer la requête principale.

Le temps d’exécution après ajout de l’index est maintenant de 2mn15, ce qui est encore loin d’être satisfaisant.

La limitation de notre requête, comme nous l’a montré la commande EXPLAIN, c’est que pour chacune des 500 000 lignes de la table, MySQL va devoir exécuter la sous-requête. Cela signifie que même en optimisant au mieux la sous-requête, celle-ci sera toujours exécutée 500 000 fois, ce qui est forcément couteux. Ajouter un index ne fait que limiter les dégâts, mais ne suffit pas pour obtenir des performances correctes.

La vraie solution à notre problème va consister à changer de point de vue sur la demande initiale formulée en langage courant, afin de pouvoir écrire la requête d’une toute autre manière, qui, espérons-le, sera plus efficace.

Nous allons donc raisonner de façon ensembliste. Avec notre table, il nous est possible de constituer deux ensembles : l’ensemble E1 des informations sur les produits (facile : SELECT * FROM product) et l’ensemble E2 des produits qui se sont le mieux vendus (facile aussi : SELECT category_id, MAX(sold) FROM product GROUP BY category_id). Si nous sommes capables de faire l’intersection entre E1 et E2, nous aurons résolu notre problème.

Or faire l’intersection de deux ensembles se traduit en SQL par une jointure entre deux tables. La solution est donc toute tracée :

mysql> SELECT sql_no_cache pdt.* FROM (
SELECT category_id, MAX(sold) as maxi
FROM product
GROUP BY category_id
) AS maxi_list
INNER JOIN product pdt
ON pdt.category_id = maxi_list.category_id
AND pdt.sold = maxi_list.maxi;


EXPLAIN nous montre comment est exécutée cette nouvelle requête :

mysql> EXPLAIN SELECT ... \G
***************** 1. row *****************
id: 1
select_type: PRIMARY
table:
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 1000
Extra:
***************** 2. row *****************
id: 1
select_type: PRIMARY
table: pdt
type: ref
possible_keys: idx_category_sold
key: idx_category_sold
key_len: 8
ref: maxi_list.category_id,maxi_list.maxi
rows: 1
Extra:
***************** 3. row *****************
id: 2
select_type: DERIVED
table: product
type: range
possible_keys: NULL
key: idx_category_sold
key_len: 4
ref: NULL
rows: 1001
Extra: Using index for group-by
3 rows in set (0,05 sec)


MySQL exécute d’abord la sous-requête puis place le résultat dans une table temporaire, qui est jointe à la table product. A noter que la jointure se fait avec deux conditions, qui sont nécessaires toutes les deux.

Quel est le temps d’exécution de cette requete ? 0.06s… Pas besoin de commentaire, le gain est vertigineux !

Ces deux articles nous ont donc permis de voir que la manière dont une requête est formulée peut avoir des conséquences très importantes sur les temps d’exécution. Il n’existe pas de règle pour savoir si une requête est bien écrite ou pas, mais quand vous rencontrez une requête utilisant de bons index mais qui est lente, il peut être très intéressant de réfléchir à son sens pour trouver une réécriture qui sera performante.

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 !

Il en ressort que pas mal d’affirmations et de recommendations sont hardcodées et ne tiennent absolument pas compte des spécificités de votre base. Un exemple ? Si le cache de requêtes est désactivé, alors le script va systématiquement vous remonter qu’il s’agit d’un problème, même si vous avez sciemment désactivé ce cache.

A partir de toutes ces constatations, Sheeri a commencé à faire évoluer le script, en ajoutant pour l’instant quelques options intéressantes, comme celle permettant de formater le rapport de manière à le rendre facilement lisible par un tableur : il devient ainsi plus facile de voir l’évolution de certains indicateurs dans le temps en lançant le script à intervalles réguliers. A suivre !

Quand on commence une application, un seul serveur SQL suffit généralement à absorber la charge. Si le trafic augmente et que les performances du serveur commencent à s’écrouler, on peut utiliser la réplication. Mais la réplication ne permet que d’augmenter le nombre de lectures possibles (read scaling) et pas le nombre d’écritures (write scaling). Cette limitation provient du fonctionnement même de la réplication car toutes les écritures doivent arriver sur le serveur maître. On peut alors imaginer de séparer les données selon certaines règles (dépendantes de l’application) de manière à avoir plusieurs masters sur lesquels on peut utiliser la réplication. Et voilà, nous venons d’inventer le sharding.

Giuseppe nous explique que le sharding est simple à mettre en place : il suffit de créer des règles permettant de dispatcher les données entre les différents masters. Malheureusement, le sharding est fragile : si, par exemple, vous changez les règles de dispatch, vous risquez de casser vos shards ! Pour simplifier le sharding, il existe un moteur de stockage récent, installable en tant que plugin pour MySQL 5.1 : Spider. Spider est basé sur le partitionnement et permet de créer des tables sur un serveur dont les données seront stockées sur des hosts distants. En gros, on utilise une pincée de partitionnement et une pincée de Federated…

Les démonstrations faites par Giuseppe montrent quand même que si Spider peut nous simplifier la tâche du sharding, la mise en place de tables avec Spider n’est pas si simple et demande un peu de doigté et de réflexion…

Les challenges chez CL:

• high ad churn rate – la durée de vie des annonces sur le site. Vous ne voulez plus recevoir de mails sur un item déjà vendu
• croissance
• trés gros traffic
• outil d’analyse & backend
• croissance ( et oui )
• besoin d’archiver tous les messages ( 100s de milions ) et pour toujours
• Internationalisation& utf8

Les briques logicielles sont:

• Load Balancer
• Read Proxy ( Perl + Memcached ) & Write Procxy
• Wed Read Proxy ( apache / mod_perl )
• Object Cache ( Perl / Memcached ) & Search Cluster ( Sphinx )
• Read DB Cluster ( MySQL 5.0 )

Toutes les datas sont en clusters avec un content specifique – User DB, Stats, Archive, Classified, Forum

Full Text Search chez CL en quelques points

• partition par ville
• attributs vs keywords
• connections persistantes
• 2 clusters ( 1 master, 4 slaves )
• indexing incremental
• slaves – requètes live
• 1000 QPS
• 25 MySQL -> 10 Sphinx
• recherche alentour
• 50M QPD ( par jour )
• archive des messages – une DB sans schema – couchdb?

Cette année, toutes les certifications se font en ligne, plus besoin d’avoir un crayon et une gomme. De plus, il y a une nouvelle certification MySQL 5.1 DBA, où le candidat doit s’occuper d’une instance de MySQL. Il y a 5 taches obligatoires à faire et 5/10 optionnelles. Pouvoir tester ce qu’un candidat peut faire devant un serveur, me parait intéressant comme approche.

Un autre avantage d’être présent à la conférence, s’inscrire aux examens coute seulement $25, le problème… Il faut vraisembablement rater une présentation pour pouvoir le faire en parallèle.

Voila ce qu’un DBA doit connaître:

• l’architecture de MySQL
• comment démarrer, arrêter et configurer MySQL
• comment fonctionnent les programmes clients ( pour DBA )
• les jeux de caractères
• les verrous
• les moteurs de stockage
• la maintenance des tables
• l’INFORMATION_SCHEMA apparu avec la 5.0
• les Backup/Recovery
• la réplication
• Backup et Replication
• l’art de l’indexation

Je vais finir par un grand bravo pour Kai pour avoir rendu interessant un sujet que je connais en long, large et travers