J’ai assiste au Keynotes:

• Our Ever-Evolving MySQL Ecosystem – Peter Zaitsev (Percona)
• Databases in the Cloud: Present and Future – Simone Brunozzi (Amazon Web Services)
• Driving MySQL Innovation – Tomas Ulin (Oracle)

et a 2 presentations dans l’apres midi:

• Scaling MySQL for the Web – Tamar Bercovici (Box)
• High performance replication – Domas Mituzas (Facebook)

Beaucoup d’energie, beaucoup d’innovation… il me semble que l’eco system autour de MySQL est plus present que jamais. Je suis heureux de voir l’investissement d’Oracle, non seulement pour MySQL 5.6 mais aussi pour son investissement dans cette conference 2013. Je mentionnerai aussi le discount ( $700 ) pour MySQL Connect en marge d’Oracle Open World.

PS: Je m’excuse apres de ceux qui ont laisse de commentaires. Le niveau de SPAM étant assez eleve, nous filtrons tous les commentaires et un de nous doit les approuver. Chose que nous ne faisons helas pas souvent! En aucun cas, nous voulons vous empêcher de vous exprimer!

InnoDB est un moteur extrêmement complexe qui mériterait un livre complet pour expliquer son fonctionnement. Selon les versions, il peut exister plus de 80 paramètres pour contrôler son fonctionnement : pas question de les examiner tous ! Je vais me concentrer sur les 2 principaux, qui devraient suffir dans la majorité des cas.

Le 1er, innodb_buffer_pool_size, contrôle la taille du cache mémoire pour les données et les index. Il s’agit assurément du paramètre de base pour obtenir de bonnes performances InnoDB puisqu’il vous permet de remplacer de nombreuses lectures ou écritures sur disque par des lectures ou écritures en mémoire. Pour le configurer, c’est simple, essayez de mettre la valeur la plus élevée possible… Evidemment, il faut penser à garder un peu de mémoire pour les connexions, les tables temporaires, les éventuelles tables MyISAM… et l’OS !

Le 2nd, innodb_log_file_size, contrôle la taille des redo logs. A quoi servent ces redo logs en quelques mots ? Pour des raisons de performance, quand un client fait une modification dans une table, InnoDB exécute la modification en mémoire instantanément (dans le fameux buffer pool que nous avons appris à configurer ci-dessus) mais garde pour plus tard l’exécution de la modification sur le disque.
Que se passe-t-il si le serveur subit un crash entre le moment où la donnée est écrite en mémoire et le moment où la donnée est écrite sur le disque ? La donnée est perdue tout simplement. Il faut donc un mécanisme supplémentaire pour assurer la persistence des données en cas de crash : ce sont les fameux redo logs. En réalité, au moment où on exécute une modification, InnoDB l’exécute en mémoire et la note également dans ses redo logs avant de signaler au client que la modification est bien enregistrée. En cas de crash, la lecture des redo logs va permettre de reconstituer les données qui étaient en mémoire mais pas encore sauvegardées sur le disque.

Quel est l’intérêt des redo logs par rapport à une écriture directe dans le fichier de données ? En général, les modifications de données successives ont lieu à des endroits radicalement différents, ce qui se traduit pour le disque par de nombreuses écritures aléatoires, extrêmement lentes. Au contraire, écrire des modifications successives dans les redo logs consiste à écrire chaque modification à la fin du fichier : il s’agit là d’écritures séquentielles, nettement plus rapides. Au moment de retranscrire le contenu des redo logs vers les tables, InnoDB pourra en profiter pour regrouper les écritures pour les rendre les plus séquentielles possibles. Ce mécanisme permet donc d’éviter de nombreuses et coûteuses écritures aléatoires.

Et que se passe-t-il quand les redo logs sont pleins ? Il n’est tout simplement plus possible de faire de modifications ! InnoDB tente donc de nettoyer régulièrement ces logs pour qu’il reste toujours de la place.

Bref, si vous m’avez suivi, les redo logs permettent de gagner en performance en écriture, on a donc tout intérêt à configurer une valeur aussi grande que possible. Cependant, il faut également garder à l’esprit qu’en cas de crash, les redo logs vont être utilisés pour restaurer les données, et cette restauration sera d’autant plus longue que la taille des redo logs sera grande… Il va donc falloir trouver un compromis entre ces 2 exigences contradictoires.

Baron de Percona a écrit un très bon article sur le sujet. Sans reprendre dans le détail ce qu’il explique, le principe de son calcul est de déterminer le volume d’écriture en période de pleine charge et de faire en sorte que les redo logs puisse contenir 1 heure d’écriture à pleine charge.

J’en profite au passage pour vous inciter à la méfiance si vous lisez des articles vous parlant de fixer cette variable à 25% de la taille du buffer pool par exemple. C’est faux et d’ailleurs bien souvent irréalisable : à part en MySQL 5.6 et sur les versions récentes de Percona Server, la taille des redo logs est limitée à 4 Go. Avec un buffer pool de 32 Go ou plus, difficile de respecter cette « règle » des 25 %…

Je fais une petite parenthèse sur le paramètre innodb_file_per_table. Ce paramètre fait en sorte que les données de chaque table soient stockées dans un tablespace spécifique au lieu du tablespace principal. Il ne faut pas attendre de cette option des gains en performance, mais plutôt en flexibilité : si vous avez 200 Go de données, au lieu d’avoir un énorme fichier ibdata de 200 Go, vous aurez autant de fichiers que de tables. De plus, si jamais vous supprimez une table, le tablespace spécifique à la table sera supprimé et vous récupérerez l’espace disque correspondant, ce qui ne sera jamais le cas si vous stockez toutes vos données dans le tablespace principal.

A noter que Percona a mis en ligne un outil vous permettant d’obtenir un fichier de configuration basique (c’est-à-dire sans doute pas optimisé au micro-poil près, mais en tout cas sans grossière erreur pouvant coûter très cher).

Et voilà ! En configurant correctement ces 2 paramètres, vous aurez réalisé l’essentiel du paramétrage d’InnoDB ! Evidemment, ensuite, il est possible d’aller un peu plus loin en jouant sur d’autres paramètres comme innodb_flush_log_at_trx_commit ou innodb_flush_method. Mais ce sera peut-être pour un prochain article !

Cache de requêtes

Le cache de requêtes est une excellente idée des années 90 pour accélérer les performances des SELECT. Malheureusement ce cache n’est absolument pas scalable en terme de connexions simultanées, ce qui signifie que dans 99,9% des cas, les performances seront meilleures quand le cache est désactivée.

Par conséquent, le tuning du cache de requêtes est très simple, il vous suffit d’indiquer dans votre fichier de configuration :
query_cache = 0

Pour les plus curieux, sachez que la désactivation du cache de requêtes n’empêche pas le serveur d’utiliser la mutex d’accès au cache de requêtes : même désactivé, le cache de requêtes peut diminuer vos performances !! Dans Percona Server et MySQL 5.5, query_cache = 0 désactive également cette mutex, mais pour les versions antérieures, il vous faudra recompiler le serveur sans support du cache de requêtes pour vous débarasser de cette mutex.

Réplication

La réplication est tellement utile qu’il est difficile de s’en passer : scale-out, haute disponibilité, aide aux backups, slaves dédiés pour les statistiques… la liste des applications est longue !

Sur toutes les instances impliquées dans un schéma de réplication, il faut absolument que chaque instance ait un server-id unique. Si vous utilisez un système de déploiement de configuration, pensez à faire en sorte que le système de déploiement génère lui-même un id qui soit garanti comme étant unique.

Sur le master, il faut également activer le paramètre log_bin pour mettre en route les logs binaires nécessaires à la réplication (et qui sont aussi utiles pour le Point In Time Recovery), par exemple :
log_bin = /data/mysql-bin

Le serveur s’occupe tout seul de numéroter les fichiers et d’en faire la rotation. A ce propos, il peut être pratique de forcer la rotation quand le fichier atteint une taille plus faible que celle par défaut (1 Go) :
max_binlog_size = 100000000
et de purger automatiquement les fichiers au bout d’un certain temps :
expire_logs_days = 7

Est également recommandé l’option sync_binlog = 1 qui assure le flush du log binaire à chaque commit (meilleure assurance contre les pertes de données en cas de crash).

Sur les slaves, il n’est en général pas nécessaire d’activer les logs binaires, sauf si le slave est lui-même un master. Dans ce cas, il faut penser à ajouter le paramètre log_slave_updates, qui indique au serveur d’écrire dans les logs binaires les écritures reçues par la réplication.

La seule autre option vraiment intéressante est read_only = 1, qui empêche tous les utilisateurs n’ayant pas le droit SUPER d’écrire sur le serveur. Cette option peut éviter des gros problèmes de désynchronisations si accidentellement une application tente d’écrire directement sur un slave au lieu d’écrire sur le master.

Ne pas oublier également de configurer un compte pour la réplication avec les droits REPLICATION SLAVE et REPLICATION CLIENT.

Journalisation

Avoir des traces de ce qui se passe dans le serveur est évidemment une très bonne idée, aussi bien pour résoudre les problèmes que pour prendre des mesures préventives. Il existe avec MySQL 3 types de logs : general log pour l’ensemble des connexions et requêtes, slow query log pour les requêtes lentes et error log pour les erreurs et warnings.

Il est préférable d’éviter d’activer le general log en production, hormis pour des périodes courtes pour investiguer sur un problème précis, car les performances s’en ressentent lourdement (et que vous risquez de vous retrouver très vite à court d’espace disque). Cela se traduit par :
general_log = OFF

Le slow query log est particulièrement utile pour repérer les requêtes les plus coûteuses de votre application. Toutes les requêtes au-delà d’un seuil que vous définissez sont écrites et peuvent servir à générer un rapport des requêtes les plus lentes. Une configuration typique est la suivante :
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 0.5

Enfin le log d’erreur devrait être activé, soit par le paramètre log_error soit en écrivant dans syslog, avec le paramètre syslog que vous trouverez généralement dans la section [mysqld_safe]. Sachez que les 2 solutions ont des avantages et des inconvénients, l’inconvénient étant toujours que vous risquez de perdre la trace d’erreurs à cause de la rotation de votre fichier de log. Vous trouverez plus d’informations dans ce billet.

Nous verrons dans le dernier article de cet série les paramètres les plus importants pour InnoDB. D’ici là, bonnes fêtes de fin d’année !

bind-address
Cette variable permet les connexions TCP à l’adresse IP indiquée. C’est la 1ère variable à regarder si vous constatez un problème d’accès et que les droits de l’utilisateur sont corrects.
En général, on utilise cette variable de 2 manières :
- bind-address = 127.0.0.1 pour n’autoriser que les connexions TCP en local
- en commentant la variable pour n’avoir aucune restriction

A noter qu’il n’est (malheureusement) pas possible d’indiquer une liste d’adresses IP pour restreindre les connexions TCP à plusieurs hôtes, dans ce cas, il faut passer par des règles de firewalls.

skip-name-resolve
Lorsqu’un client se connecte au serveur, celui-ci fait 2 requêtes DNS. Le DNS pouvant être lent, c’est souvent une bonne idée d’utiliser cette variable pour désactiver complètement les requêtes DNS. Seule conséquence contraignante : le champ host des utilisateurs ne peut plus être un nom de domaine, mais uniquement une adresse IP (vous pouvez continuer à utiliser les wildcards, par exemple 192.168.%).

max_connections
C’est la variable qui contrôle le nombre de connexions simultanées au serveur. Si vous voyez régulièrement des erreurs ‘Too many connections‘ lorsque des clients essaient de se connecter, il s’agit de la variable à regarder, la valeur par défaut (100 ou 150 selon les versions) pouvant être trop faible selon le type d’applications.

A noter qu’il n’est pas conseillé de mettre systématiquement cette variable à un nombre très élevé, puisque plus le nombre de connexions simultanées est élevé, plus le serveur risque d’être sujet à des problèmes de contentions internes et risque d’être peu performant. Parfois un trop grand nombre de connexions simultanées cache un problème de conception dans l’application.

A noter également que même quand le nombre de connexions ouvertes a atteint max_connections, il est toujours possible de se connecter au serveur avec un utilisateur qui dispose du droit SUPER. Le but est de pouvoir faire des SHOW PROCESSLIST pour comprendre ce qu’il se passe (et éventuellement quelques KILL bien sentis…).

datadir
Il s’agit de l’emplacement du répertoire de données. Vous n’avez pas besoin de le changer si votre volumétrie de données reste dans la gamme des centaines de Mo ou moins, mais dès que vous prévoyez d’atteindre des tailles conséquentes, il est plus que conseillé d’indiquer un répertoire se trouvant dans une partition où l’espace disque est suffisant.

old_passwords
Avant la version 4.1, MySQL utilisait une méthode de cryptage des mots de passe très faible, toujours disponible sur les versions actuelles quand on active ce fameux paramètre (old_passwords = 1).

En général, on trouve ce fameux paramètre sur de vielles applications « parce qu’on ne va pas s’amuser à changer tous les mauvais de passe même si on sait que ce serait mieux ».

En réalité, même quand on désactive ce paramètre, un client est toujours capable de se connecter lorsque son mot de passe est crypté avec l’ancienne méthode. Il n’y a donc que des avantages à désactiver old_passwords, sauf si bien sûr vous utilisez encore des librairies ne connaissant que l’ancien cryptage (ce qui devrait être hautement improbable, le changement dans MySQL datant de 2004 !).

Quelques autres variables intéressantes
Selon les cas, il peut aussi être pertinent de regarder du côté des variables suivantes : thread_cache_size, tmp_table_size, max_heap_table_size, table_definition_cache, table_open_cache.

Je signale également un cas particulier : sort_buffer_size. Vous avez tout intérêt à la laisser à sa valeur par défaut et donc à la commenter si vous la trouvez dans un fichier de configuration. Pour la petite histoire, j’ai mis fin aux crashes aléatoires d’un serveur en commentant simplement cette petite variable. Le scénario était le suivant avant cette modification : sort_buffer_size = 512M + plusieurs requêtes simultanées avec des gros tris => la RAM vient à manquer => OOM killer se met en route et tue mysqld…

Dans le prochain épisode, nous verrons les variables les plus importantes concernant le cache de requêtes, la réplication et les journaux.

Le programme de la rencontre est déjà disponible, n’oubliez pas de vous inscrire si vous comptez venir, le nombre de places étant limité.

Voici le code magique qui vous donnera droit à une réduction de 40£ : come-c-talk, que vous pourrez saisir en vous enregistrant.

Pour plus d’informations sur Percona Live, vous pouvez aller voir le site, et surtout le programme.
Enfin, vous pouvez vous inscrire au groupe LinkedIn créé pour l’occasion par notre ami Cédric.

See you there!

PS : promis, dans le prochain post, vous trouverez plus de technique et moins de liens !!

Une de mes tables a une tendance marquée à la fragmentation, ce qui a pour conséquence de faire gonfler artificiellement sa taille et de faire baisser les performances de certaines requêtes. Je dois donc de temps à autre la défragmenter. Pas de problème : je commence par regarder la taille sur le disque du fichier .ibd (il s’agit d’une table InnoDB sur un serveur pour lequel innodb_file_per_table est activé). Quand la table est défragmentée, elle fait environ 8 Go :

# cd /data/mysql/main_revshare
# du -sh bris_statistic_video.ibd
11G bris_statistic_video.ibd

Pas de doute, une séance de défragmentation s’impose. Je me connecte donc au serveur MySQL pour exécuter un OPTIMIZE TABLE :

mysql> OPTIMIZE TABLE bris_statistic_video\G
******** 1. row ********
Table: dailymotion.bris_statistic_video
Op: optimize
Msg_type: Error
Msg_text: Table 'dailymotion.bris_statistic_video' doesn't exist
******** 2. row ********
Table: dailymotion.bris_statistic_video
Op: optimize
Msg_type: error
Msg_text: Corrupt

Et là, c’est le drame ! Quoi, ma table est corrompue ? Impossible, l’application fonctionne toujours et la table est utilisée partout !

Comment sortir de ce problème : redémarrer le serveur en espérant qu’InnoDB répare la table, récupérer un backup ? En fait non, il faut simplement rester calme et bien regarder le message : si à la 2ème ligne, MySQL nous annonce que la table est corrompue, à la 1ère MySQL nous annonce que la table n’existe pas … alors que nous avons vu que le fichier .ibd existe bien. Louche cette histoire !

Un tour dans le journal d’erreurs confirme bien qu’il n’existe aucune erreur : il doit donc y avoir une erreur avec la commande OPTIMIZE. Réfléchissons, réfléchissons … ça y est : j’ai exécuté la commande OPTIMIZE dans la base main alors que ma table se trouve dans la base main_revshare. Il suffit donc de se positionner dans main_revshare et de relancer l’OPTIMIZE, avec succès cette fois.

Moralité : Mieux vaut se méfier des messages d’erreurs qui ne vous sont pas familiers et bien réfléchir à la cause de l’erreur avant de se lancer dans la correction d’un problème qui n’existe peut-être pas !

Idée générale

Si vous avez bien lu l’article précédent, vous avez probablement remarqué que la principale difficulté est qu’il n’existe quasiment jamais de règle absolue permettant de savoir à coup sûr qu’un index est inutile (exception notable : les index en doublon repérés par mk-duplicate-key-checker et qui peuvent être supprimés dans 99% des cas sans problème). Finalement, la seule méthode qui semble marcher est la suivante :
- Récupérer les requêtes exécutées sur le serveur
- Regarder le plan d’exécution de ces requêtes pour voir les index utilisés
- Comparer avec le schéma des tables pour en déduire les index non utilisés
- Supprimer les index repérés
La difficulté se situe surtout dans la 2ème étape (construire la liste des index utilisés à partir du plan d’exécution). Heureusement il existe au moins 2 manières, en fonction de votre version de MySQL, pour réussir cette étape.

Index_statistics

Les heureux utilisateurs de MariaDB ou Percona Server ont la chance d’avoir userstats v2, un patch exceptionnel développé à l’origine par Google. Ce patch ajoute un nombre incalculable de statistiques sur les utilisateurs, les tables mais aussi, ce qui nous intéresse ici, les index. Pour activer la fonctionnalité, il suffit de changer une variable :
mysql> SET GLOBAL userstat_running = 1;

A partir de ce moment, la table INDEX_STATISTICS de la base INFORMATION_SCHEMA va se remplir. Les colonnes sont très simples à comprendre : TABLE_SCHEMA, TABLE_NAME et INDEX_NAME localisent l’index et ROWS_READ donne le nombre de lignes lues dans l’index. Evidemment, pour obtenir des statistiques significatives et fiables, il faut attendre suffisamment longtemps avant de consulter le contenu de la table. Une bonne question est de savoir ce que signifie « suffisamment longtemps » : disons qu’il faut que chaque requête potentielle de l’application ait pu être exécutée, en pensant bien aux requêtes rares telles que les requêtes faites dans des cronjobs par exemple.

Un petit exemple sur des données réelles ?

mysql> SELECT * FROM INFORMATION_SCHEMA.INDEX_STATISTICS WHERE TABLE_NAME='main';
+--------------+------------+------------+-----------+
| TABLE_SCHEMA | TABLE_NAME | INDEX_NAME | ROWS_READ |
+--------------+------------+------------+-----------+
| biz          | main       | user_id    | 231751890 |
| biz          | main       | created    | 4456658   |
| biz          | main       | PRIMARY    | 1748023896 |
| biz          | main       | modified_idx    | 266636148 |
| biz          | main       | mobile_idx    | 550 |
+--------------+------------+---------------+------------+

et voyons en parallèle le schéma de la table :

mysql> SHOW CREATE TABLE main\G
********* 1. row *********
Table: main
Create Table: CREATE TABLE main (
  ...
  PRIMARY KEY (main_id),
  KEY user_id (user_id),
  KEY created (created),
  KEY language_idx (language),
  KEY mobile_idx (mobile,deleted,web,published),
  KEY country_mobile_idx (country,mobile),
  KEY modified_idx (modified)
) ENGINE=InnoDB;

Qu’en déduit-on ? En premier lieu, que les index language_idx et country_mobile_idx ne sont jamais utilisés, ils ne servent donc à rien et peuvent être supprimés. Ensuite, en comparant les chiffres, on voit que le serveur a lu 1,7 milliards de lignes dans la clé primaire, 550 dans l’index mobile_idx : aucun doute mobile_idx ne sert à rien lui non plus !

Et voilà, de manière très simple, nous avons trouvé des index qui peuvent être supprimés.
On peut même automatiser la découverte des index non utilisée avec une petite requête qui va bien.

Quelles sont les limitations de cette méthode ? Très simple, autant les index qui ne sont jamais utilisés sont visibles immédiatement, autant on peut se poser la question de la pertinence de certains index. Et malheureusement, les chiffres donnés par la table INDEX_STATISTICS ne sont pas suffisants. Exemple : l’index created affiche un nombre de lignes lues environ 500 fois plus faibles que la clé primaire : cela signifie-t-il qu’il n’est pas très utile ou qu’au contraire il est très utile mais seulement sur certaines requêtes ?

mk-index-usage

Quand on ne dispose de userstats, la seule solution consiste à collecter toutes les requêtes pendant une période suffisamment longue, par exemple en mettant long_query_time à 0 pour que toutes les requêtes aboutissent dans le slow query log, et à se tourner vers Maatkit en espérant y trouver notre bonheur. Ca tombe bien, mk-index-usage est justement un outil lisant un fichier de log et délivrant de nombreuses informations intéressantes (en déterminant en particulier le plan d’exécution des requêtes).

Par défaut, mk-index-usage prend en entrée un fichier de log au format slow query log et affiche une liste de requêtes SQL pour supprimer les index inutiles :

$ mk-index-usage slow.log
slow.log: 5% 08:28 remain
slow.log: 11% 07:20 remain
slow.log: 14% 08:36 remain
...
slow.log: 93% 00:37 remain
slow.log: 97% 00:12 remain

ALTER TABLE `main`.`adfit` DROP KEY `status`; — type:non-unique
…
ALTER TABLE `main`.`biz` DROP KEY `created`, DROP KEY `modified_idx`; — type:non-unique

Surprise ! Le script a bien identifié modified_idx comme inutile, mais pas mobile_idx. Et il a décidé que created pouvait être supprimé alors que nous avons vu que ce n'était pas forcément évident.

Comme d'habitude avec Maatkit, si vous êtes curieux et que vous lisez la documentation, vous verrez qu'il existe une multitude d'options permettant d'obtenir bien plus d'informations sur l'usage des index sur votre plate-forme. De plus, cette méthode est compatible avec toutes les versions de MySQL

Conclusion

Les deux méthodes présentées ici peuvent vous faire gagner beaucoup de temps en vous aidant à identifier les index candidats à la suppression. Bien entendu, comme souvent, il ne serait pas très prudent de faire confiance aveuglément à un script pour gérer votre plate-forme : votre travail consistera à vérifier s'il faut effectivement enlever les index qui sont susceptibles d'être supprimés. Normalement, ce type d'index ne devrait représenter qu'une petite portion des index de votre application, le gain de temps sera donc appréciable.