Chapitre 11.3 — MySQL / MariaDB

⏱️ TL;DR — PostgreSQL n’est pas seul : MySQL et son fork libre MariaDB font tourner une immense partie du web (WordPress en tête). L’installation est symétrique de Postgres : apt install mariadb-server, puis un geste incontournable — sudo mysql_secure_installation, l’assistant de durcissement qui pose un mot de passe root, supprime les utilisateurs anonymes et la base de test, et coupe le login root distant. Ensuite, même logique : CREATE DATABASE, CREATE USER, GRANT, connexion par mysql -u ... -p, et écoute verrouillée en local (bind-address = 127.0.0.1). MySQL ou Postgres ? Les deux sont d’excellents choix ; on tranche sans dogme.

🎯 Objectifs

• Installer MariaDB (ou MySQL) et lancer son durcissement.
• Exécuter mysql_secure_installation et comprendre chaque décision qu’il propose.
• Créer une base, un utilisateur applicatif et lui accorder les droits.
• Te connecter et verrouiller l’écoute en local (bind-address).
• Savoir quand choisir MySQL/MariaDB plutôt que PostgreSQL, sans dogme.

MariaDB ou MySQL ?

MySQL est la base relationnelle historique du web. MariaDB en est un fork communautaire, né quand MySQL est passé sous la tutelle d’Oracle ; il reste très largement compatible (mêmes commandes, mêmes clients, mêmes pilotes dans l’écrasante majorité des cas). Sur Debian et Ubuntu, mariadb-server est le choix par défaut, libre et sans friction. Tout ce chapitre s’applique aux deux ; on écrit « MySQL/MariaDB » et le client s’appelle mysql dans les deux cas.

Installer

sudo apt update
sudo apt install mariadb-server     # installe le serveur et le client mysql
 
systemctl status mariadb            # le service doit etre "active"

Comme pour Postgres, le service démarre et est activé au boot. Là aussi, l’écoute par défaut est locale sur la plupart des installations récentes — mais on va le vérifier explicitement, car la valeur par défaut a varié selon les versions et distributions.

Le geste qui compte : mysql_secure_installation

Une installation MySQL/MariaDB fraîche est volontairement permissive pour faciliter la découverte : utilisateurs anonymes, base de test ouverte, parfois pas de mot de passe root. En production, c’est inacceptable. Un assistant règle tout ça d’un coup :

🐚 Au terminal — Lancer le durcissement, juste après l’installation :

sudo mysql_secure_installation

L’assistant pose une série de questions. Voici ce que chacune fait et la bonne réponse en prod :

🔒 Sécurité — mysql_secure_installation n’est pas optionnel. Une base MySQL laissée dans son état d’installation, avec utilisateurs anonymes et root sans mot de passe, est une porte grande ouverte. Ce script est le strict minimum avant de mettre quoi que ce soit en prod. Fais-le tout de suite après apt install, avant même de créer ta base applicative.

Créer la base et l’utilisateur applicatif

Même principe que Postgres : un utilisateur dédié, des droits limités à sa base. On ouvre une console admin, puis on tape du SQL.

sudo mysql       # ouvre le client en tant que root de la base (via socket)

Dans la console MariaDB [(none)]> :

-- 1. Creer la base
CREATE DATABASE formacampus CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
 
-- 2. Creer l'utilisateur applicatif, limite a la connexion LOCALE
CREATE USER 'formacampus'@'localhost' IDENTIFIED BY 'REMPLACE-par-un-secret-fort';
 
-- 3. Lui donner les droits sur SA base uniquement
GRANT ALL PRIVILEGES ON formacampus.* TO 'formacampus'@'localhost';
 
-- 4. Recharger les privileges
FLUSH PRIVILEGES;

Décryptage. CREATE DATABASE ... utf8mb4 crée la base avec l’encodage Unicode complet (indispensable pour gérer emojis et caractères internationaux — l’ancien utf8 de MySQL était tronqué). La subtilité MySQL, c’est que l’identité d’un utilisateur est un couple 'nom'@'hôte' : 'formacampus'@'localhost' ne peut se connecter que depuis la machine locale. GRANT ALL PRIVILEGES ON formacampus.* limite ses droits à la base formacampus et à toutes ses tables (.*), rien d’autre. FLUSH PRIVILEGES applique le tout.

💡 Réflexe — Le @'localhost' dans le nom d’utilisateur MySQL est ta première barrière : un compte 'app'@'localhost' est physiquement incapable de se connecter depuis l’extérieur, quel que soit l’état du réseau. Ne crée un 'app'@'%' (depuis n’importe quel hôte) que si tu as une base réellement distante — et alors avec TLS et filtrage IP, comme au chapitre précédent.

Se connecter

mysql -u formacampus -p formacampus
# -u : l'utilisateur    -p : demande le mot de passe (ne le mets JAMAIS en clair sur la ligne)
# le dernier argument est le nom de la base

Le -p sans valeur accolée est le bon réflexe : il fait demander le mot de passe interactivement, au lieu de l’écrire en clair dans la commande (où il resterait dans l’historique du shell et visible dans la liste des processus). Si l’invite MariaDB [formacampus]> apparaît, c’est bon.

La chaîne de connexion côté app suit le même esprit que Postgres, avec le protocole mysql:// :

# .env sur le serveur (jamais dans git)
DATABASE_URL=mysql://formacampus:LE-MOT-DE-PASSE@localhost:3306/formacampus

Note le port : MySQL/MariaDB écoute par défaut sur 3306 (contre 5432 pour Postgres). Et là aussi, l’hôte est localhost : la connexion ne quitte pas le VPS.

Verrouiller l’écoute : bind-address

L’équivalent MySQL du listen_addresses de Postgres s’appelle bind-address, dans un fichier de configuration (typiquement sous /etc/mysql/).

# /etc/mysql/mariadb.conf.d/50-server.cnf (chemin variable selon la distribution)
bind-address = 127.0.0.1

Avec 127.0.0.1, le serveur n’écoute que sur la boucle locale : injoignable de l’extérieur. Après modification, on redémarre le service.

sudo systemctl restart mariadb
 
# Verification reflexe : la base ne doit ecouter qu'en local
sudo ss -tulpn | grep 3306    # attendu : 127.0.0.1:3306, PAS 0.0.0.0:3306

⚠️ Piège — bind-address = 0.0.0.0 fait écouter MySQL sur toutes les interfaces, IP publique comprise. C’est le pendant exact du listen_addresses = '*' de Postgres, et tout aussi dangereux : port 3306 scanné, bruteforce, fuite. Garde 127.0.0.1 sauf base réellement distante, et bloque 3306 au pare-feu (Partie 5).

MySQL/MariaDB ou PostgreSQL ? Choisir sans dogme

Les deux sont des bases relationnelles matures, rapides et fiables. Le débat religieux n’a pas d’intérêt ; voici des repères honnêtes.

💡 Réflexe — Le meilleur choix est souvent celui que ton équipe et ton écosystème maîtrisent. Pour un WordPress, MariaDB est l’évidence. Pour une nouvelle app Symfony ou Next.js, PostgreSQL est le défaut recommandé de ce cours (types riches, robustesse). Dans les deux cas, les gestes de prod — utilisateur dédié, écoute locale, sauvegardes testées — sont identiques. C’est ça qui compte, pas la marque.

🧭 Sur FormaCampus — L’API Symfony tourne sur PostgreSQL. Mais FormaCampus héberge aussi un blog WordPress (marketing) qui, lui, réclame MariaDB. L’équipe applique donc à MariaDB exactement la même discipline qu’à Postgres : mysql_secure_installation dès l’install, utilisateur 'wp'@'localhost' limité à la base du blog, bind-address = 127.0.0.1, port 3306 bloqué au pare-feu, et dumps chiffrés (chapitre 11.5). Deux moteurs, une seule doctrine de sécurité.

✏️ Exercices

Exercice 1 — Le durcissement. Tu viens de faire apt install mariadb-server sur un serveur de prod. Quelle commande lances-tu immédiatement, et cite trois choses qu’elle corrige.

Exercice 2 — Crée l’utilisateur. Écris le SQL qui crée un utilisateur blog connectable uniquement en local, avec un mot de passe, et lui donne tous les droits sur la seule base wordpress. N’oublie pas de recharger.

CREATE USER 'blog'@'localhost' IDENTIFIED BY 'un-secret-long-et-aleatoire';
GRANT ALL PRIVILEGES ON wordpress.* TO 'blog'@'localhost';
FLUSH PRIVILEGES;

🧠 Quiz de révision

Chapitre suivant : Tuning & connexions — faire tenir la base sous charge, et choisir où l’héberger.