Comprendre son fichier de configuration – 1ère partie

16 décembre 2011 par stephane

Des outils tels que mysql tuning primer ou mysqltuner proposent de vous aider à configurer correctement votre serveur MySQL. Il est vrai qu’il est facile de se perdre dans la profusion d’options disponibles. Pourtant les recommendations de ces outils sont bien souvent complètement absurdes ! Il est bien plus fiable de connaître les grandes lignes de la configuration du serveur pour obtenir rapidement un paramétrage correct. Je vous propose dans cette série d’articles de faire le tour des principales variables à regarder.

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.

Mots-clefs : , ,

Laisser une réponse