MariaDB et MySQL en production : installation, fichiers et my.cnf

Objectif

Installer un serveur MariaDB ou MySQL comme on le fait en production : la bonne version, le bon dépôt, des réglages dans vos propres fichiers, un système préparé pour une base de données, et la certitude de savoir quelle valeur le serveur a vraiment retenue.

L'essentiel

Une base de production, c'est un cycle de vie : on choisit une version LTS (support long) et on suit ses versions mineures de correctifs.
Les fichiers à connaître : le datadir (/var/lib/mysql), le socket (/run/mysqld/mysqld.sock), le journal d'erreurs, les fichiers my.cnf.
my.cnf est lu dans un ordre précis, avec des inclusions ; pour une option répétée, la dernière valeur gagne.
On ne modifie jamais les fichiers du paquet : on ajoute son fichier (90-production.cnf) et on vérifie la valeur effective.
Le serveur se règle aussi autour de la base : limites systemd, swap, volume dédié monté en noatime.

1. Le métier : ce que le DBA ajoute au « apt install »

Les cours Debian, Red Hat et Ubuntu vous ont montré comment installer MariaDB, créer une base et un compte. Ici, on prend la place de la personne qui répond de la base : elle doit tenir des années, encaisser la charge de la boutique MasterLinux le soir des soldes, être sauvegardée, répliquée, surveillée et mise à jour sans perte.

Questions à se poser avant d'installer :

Question	Pourquoi
Quelle version, jusqu'à quand supportée ?	MariaDB publie des versions LTS (10.11, 11.4, 11.8…) maintenues environ 5 ans ; MySQL a ses LTS 8.4 et des versions « Innovation » de courte durée.
Paquet de la distribution ou dépôt officiel ?	Debian 13 fournit MariaDB 11.8 ; le dépôt de MariaDB ou de MySQL donne une version précise et des mises à jour plus rapides. On choisit une source et on s'y tient.
Moteur de stockage ?	InnoDB pour tout (transactions, reprise après panne). MyISAM n'a pas sa place en production.
Quelle machine ?	RAM (le cache InnoDB), disques SSD/NVMe, volume dédié pour les données.

2. Installer et repérer les fichiers

apt install mariadb-server mariadb-backup        # Debian / Ubuntu
dnf install mariadb-server mariadb-backup        # Rocky / Alma (MySQL : dnf install mysql-server)

systemctl enable --now mariadb
mariadb -e "SELECT VERSION(), @@datadir, @@socket, @@log_error;"

Élément	Debian / Ubuntu	Rocky / Alma
Fichier principal	`/etc/mysql/my.cnf` → `mariadb.cnf`	`/etc/my.cnf`
Dossiers inclus	`/etc/mysql/conf.d/`, `/etc/mysql/mariadb.conf.d/`	`/etc/my.cnf.d/`
Données (datadir)	`/var/lib/mysql`	`/var/lib/mysql`
Journal d'erreurs	journal systemd (`journalctl -u mariadb`) ou `/var/log/mysql/error.log`	`/var/log/mariadb/mariadb.log`
Nom du service	`mariadb` (alias `mysql`)	`mariadb` ou `mysqld`

Les commandes ont été renommées : mariadb (client), mariadb-dump, mariadb-admin, mariadb-backup, mariadb-binlog. Les anciens noms mysql* existent encore comme liens sur beaucoup de systèmes, mais disparaissent peu à peu.

3. Comment my.cnf est lu

Sur Debian, /etc/mysql/mariadb.cnf ressemble à ceci :

[client-server]
socket = /run/mysqld/mysqld.sock

!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mariadb.conf.d/

Trois règles à graver :

Les sections (groupes) disent qui lit l'option : [mysqld], [server], [mariadb], [mariadb-11.8] (seulement cette version) pour le serveur ; [client], [mysql], [mariadb-dump] pour les outils.
!includedir lit les fichiers du dossier par ordre alphabétique, et seulement ceux qui finissent par .cnf.
Pour une option répétée, la dernière lue l'emporte. Un 99-vieux.cnf oublié bat votre 90-production.cnf.

Pour savoir ce que le serveur va lire, sans le redémarrer :

my_print_defaults --mysqld          # toutes les options du serveur, dans l'ordre de lecture
mariadbd --print-defaults           # même chose, vu par le binaire du serveur
mariadb -e "SELECT @@innodb_buffer_pool_size/1024/1024/1024 AS go, @@max_connections;"   # valeur EN COURS

Dans le lab, la commande cnf-effectif <option> donne la valeur finale qu'aurait le serveur au démarrage (l'équivalent de SELECT @@option).

Variables dynamiques et statiques

Une partie des réglages se change à chaud :

SET GLOBAL max_connections = 300;            -- immédiat, mais perdu au redémarrage
SET GLOBAL innodb_buffer_pool_size = 10*1024*1024*1024;   -- redimensionnement en ligne (InnoDB)

D'autres exigent un redémarrage (innodb_log_file_size sur les anciennes versions, bind_address…). Règle d'exploitation : tout changement à chaud est aussi écrit dans le fichier, sinon il disparaît au prochain redémarrage. MySQL 8 propose SET PERSIST, qui écrit dans mysqld-auto.cnf du datadir ; c'est pratique, mais ce fichier doit être connu de toute l'équipe, sinon personne ne comprend d'où vient une valeur.

4. Les réglages qui comptent pour un serveur dédié

# /etc/mysql/mariadb.conf.d/90-production.cnf — ml-db-01, 16 Go de RAM, dédié
[mysqld]
bind_address                   = 10.10.20.11   # l'adresse du réseau privé, jamais 0.0.0.0 sans pare-feu
skip_name_resolve              = ON            # pas de DNS inverse à chaque connexion (comptes par IP)
max_connections                = 300

innodb_buffer_pool_size        = 10G           # 60 à 70 % de la RAM d'un serveur DÉDIÉ
innodb_log_file_size           = 2G            # journal redo : assez grand pour lisser les écritures
innodb_flush_log_at_trx_commit = 1             # 1 = aucune transaction validée perdue en cas de panne
innodb_file_per_table          = ON            # un fichier par table (défaut)

Buffer pool : le cache des pages InnoDB. Trop petit, tout part sur le disque ; trop grand, le serveur swappe ou est tué par l'OOM killer. On laisse de la RAM au système, aux connexions (chacune consomme des tampons) et au cache de fichiers.
innodb_flush_log_at_trx_commit : 1 est le seul réglage qui garantit la durabilité. 2 ou 0 vont plus vite mais peuvent perdre la dernière seconde de transactions en cas de coupure : à réserver à une base qu'on peut reconstruire.
Jeu de caractères : utf8mb4 partout (l'ancien utf8 de MySQL ne stocke que 3 octets et casse les emojis et certains caractères).

5. Préparer le système

# /etc/systemd/system/mariadb.service.d/limites.conf
[Service]
LimitNOFILE=65535        # une table = des fichiers ouverts ; 1 024 par défaut ne suffit pas
TimeoutStopSec=900       # laisser le temps de vider un gros buffer pool à l'arrêt

systemctl daemon-reload && systemctl restart mariadb
cat /proc/$(pidof mariadbd)/limits | grep 'open files'

Si systemd tue le serveur au bout de 90 secondes pendant l'arrêt, la base redémarre en récupération après panne (crash recovery) : plus long, et inquiétant un soir de maintenance.

echo 'vm.swappiness = 1' > /etc/sysctl.d/60-mariadb.conf && sysctl --system   # swap en dernier recours

Le datadir sur un volume dédié (LVM) : la base ne remplit pas /, on agrandit le volume sans toucher au système, on peut prendre un instantané. noatime évite une écriture à chaque lecture de fichier.

/dev/vg_bdd/lv_mysql  /var/lib/mysql  xfs  defaults,noatime  0 2

Selon la version

Point	MariaDB 10.11	MariaDB 11.4 / 11.8	MySQL 8.4 LTS
Nom du binaire serveur	`mariadbd` (`mysqld` en lien)	`mariadbd`	`mysqld`
Collation par défaut d'utf8mb4	`utf8mb4_general_ci`	`uca1400_ai_ci` (Debian 13)	`utf8mb4_0900_ai_ci`
Changer `innodb_log_file_size`	à chaud depuis 10.11	à chaud	`innodb_redo_log_capacity` à chaud
Réglages persistants à chaud	non (écrire le fichier)	non	`SET PERSIST` (`mysqld-auto.cnf`)
TLS des connexions	à configurer	activé par défaut depuis 11.4	activé par défaut (certificats générés)

Pièges fréquents

Modifier 50-server.cnf : il est remplacé ou provoque une question à chaque mise à jour du paquet. Votre fichier 90-… reste à vous.
Un vieux fichier qui gagne : un 99-…cnf ou un zz-…cnf d'un ancien prestataire annule vos réglages. Toujours vérifier la valeur effective.
Renommer en .bak dans le mauvais sens : fichier.cnf.bak n'est plus lu (bien), mais fichier.bak.cnf l'est encore.
Buffer pool à 90 % de la RAM sur un serveur qui fait aussi tourner PHP ou Java : le noyau tue mariadbd en pleine journée.

Cas réel

Un vendredi soir, la boutique MasterLinux devient très lente. Le serveur a pourtant 16 Go de RAM et l'équipe a « mis le buffer pool à 10 Go » dans 90-production.cnf six mois plus tôt. SELECT @@innodb_buffer_pool_size répond… 256 Mo. Un fichier 99-optimisation-2023.cnf, copié depuis un ancien serveur, était lu en dernier. Tout le jeu de données passait par le disque. Le correctif a pris deux minutes ; la leçon, elle, reste : on vérifie la valeur effective après chaque changement.

Lab

Sur une machine Debian 13 qui imite l'arborescence de MariaDB 11.8, vous allez :

écrire votre fichier de réglages de production ;
découvrir pourquoi le serveur ne les retiendrait pas, et corriger sans rien supprimer ;
ajouter la surcharge systemd ;
régler le swap ;
déclarer le volume dédié aux données dans /etc/fstab.

Les commandes my_print_defaults --mysqld et cnf-effectif <option> vous montrent ce que le serveur lirait.

Quiz

Dans un dossier inclus par !includedir, dans quel ordre les fichiers sont-ils lus, et lesquels ?
Deux fichiers définissent max_connections : lequel gagne ?
Pourquoi innodb_flush_log_at_trx_commit = 1 en production ?
Quelle part de la RAM donner au buffer pool sur un serveur dédié, et pourquoi pas plus ?
Que se passe-t-il si systemd tue MariaDB pendant un arrêt trop long ?

Réponses

Par ordre alphabétique, et seulement les fichiers qui finissent par .cnf.
Celui qui est lu en dernier.
C'est le seul réglage qui écrit le journal redo sur disque à chaque validation : aucune transaction validée n'est perdue en cas de panne.
Environ 60 à 70 % : il faut laisser de la mémoire au système, aux connexions et au cache de fichiers, sinon swap ou OOM killer.
Le serveur redémarre en récupération après panne (crash recovery), plus longue, avec un risque accru ; d'où TimeoutStopSec plus long.