MariaDB sur VPS : SQL libre, rapide et maîtrisé

MariaDB est un fork communautaire de MySQL, 100 % open source, reconnu pour ses performances, sa fiabilité et sa compatibilité totale avec les applications MySQL existantes. Hébergé sur un VPS, il vous libère des restrictions des hébergements mutualisés : pas de limites de connexions imposées, pas de quotas arbitraires sur la taille des bases, et la possibilité de tuner finement les paramètres du moteur InnoDB selon votre charge réelle. Vous gardez la maîtrise de vos sauvegardes, de vos utilisateurs et de la sécurité réseau, sans dépendre d'un prestataire tiers pour chaque opération de maintenance.

Deux versions LTS sont disponibles aujourd'hui : MariaDB 11.4 LTS (publiée en mai 2024, support garanti jusqu'en 2028+) et MariaDB 10.11 LTS (support jusqu'en février 2028). Les deux sont stables pour la production ; 11.4 apporte notamment l'abandon définitif du client mysql au profit de mariadb, un parallélisme amélioré des threads et des améliorations InnoDB.

Avant de commencer, vérifiez que vous disposez des éléments suivants :

- Un VPS ServOrbit : 2 Go de RAM minimum (usage léger ou test), 4 Go recommandés en production. MariaDB seul consomme peu, mais la mémoire tampon InnoDB (innodb_buffer_pool_size) doit représenter 60 à 70 % de la RAM disponible pour être efficace — sur 2 Go, il reste moins de 1,2 Go utile après le système d'exploitation.
- Accès SSH root ou sudo à votre VPS.
- Une version MariaDB récente : MariaDB 11.4 LTS (mai 2024, support jusqu'en 2028+) ou MariaDB 10.11 LTS (support jusqu'en février 2028). Évitez 10.6 et inférieures en production : elles approchent de leur fin de support.
- Un pare-feu actif (UFW ou équivalent) : le port 3306 ne doit jamais être exposé directement sur Internet.

Une base de données sans sauvegarde automatique est une bombe à retardement. Le script suivant crée une sauvegarde compressée chaque nuit, avec une rétention de 7 jours.

Créer le script de sauvegarde dans /usr/local/bin/backup-mariadb.sh :

#!/bin/bash
BACKUP_DIR="/var/backups/mariadb"
DATE=$(date +%Y%m%d_%H%M%S)
DB_USER="root"
DB_PASS="votre_mot_de_passe_root"
RETENTION=7

mkdir -p "$BACKUP_DIR"

# Lister toutes les bases (hors système)
DATABASES=$(mariadb -u"$DB_USER" -p"$DB_PASS" -e "SHOW DATABASES;" 2>/dev/null | \
  grep -vE "^(Database|information_schema|performance_schema|mysql|sys)$")

for DB in $DATABASES; do
  mariadb-dump \
    -u"$DB_USER" -p"$DB_PASS" \
    --single-transaction \
    --quick \
    --routines \
    --triggers \
    "$DB" | gzip > "$BACKUP_DIR/${DB}_${DATE}.sql.gz"
done

# Supprimer les sauvegardes de plus de RETENTION jours
find "$BACKUP_DIR" -name "*.sql.gz" -mtime +$RETENTION -delete

Rendez le script exécutable et ajoutez une tâche cron pour l'exécuter chaque nuit à 02h00 :

chmod +x /usr/local/bin/backup-mariadb.sh
crontab -e

Ajoutez la ligne suivante :

0 2 * * * /usr/local/bin/backup-mariadb.sh >> /var/log/backup-mariadb.log 2>&1

Pourquoi --single-transaction et --quick : --single-transaction prend un instantané cohérent sans poser de verrous sur les tables InnoDB (indispensable en production pour éviter les blocages d'écriture) ; --quick envoie les lignes une par une sans les charger en mémoire, ce qui évite les débordements RAM sur les grandes tables.

Pour restaurer une base depuis une sauvegarde :

zcat /var/backups/mariadb/mon_app_20261007_020000.sql.gz | mariadb -u root -p mon_app

La configuration par défaut de MariaDB est très conservatrice (quelques dizaines de Mo pour innodb_buffer_pool_size). Sur un VPS de production, ajustez les paramètres InnoDB pour exploiter la mémoire disponible.

Créer le fichier /etc/mysql/conf.d/performance.cnf :

[mysqld]
# Pool de tampons InnoDB : 60-70 % de la RAM totale
# Sur 4 Go de RAM → 2,5 Go
innodb_buffer_pool_size = 2560M

# Taille des fichiers journaux (recommandé : 25 % du pool)
innodb_log_file_size = 640M

# Nombre de fichiers journaux (défaut 2, suffisant)
innodb_log_files_in_group = 2

# Cache de requêtes désactivé sur MariaDB 10.3+ (dégradations mesurées)
query_cache_size = 0
query_cache_type = 0

# Connexions simultanées (ajuster selon la charge réelle)
max_connections = 150

# Journal des requêtes lentes (identifier les requêtes à optimiser)
slow_query_log = 1
long_query_time = 1
slow_query_log_file = /var/log/mysql/mariadb-slow.log

Adaptez innodb_buffer_pool_size selon la RAM de votre VPS : sur 2 Go, comptez 1,2 Go (1228M) ; sur 8 Go, comptez 5,5 Go (5632M).

Réutilisez les paramètres avec innodb_log_file_size à environ 25 % du buffer pool, puis redémarrez MariaDB pour appliquer la configuration :

systemctl restart mariadb

Vérifiez que les paramètres ont bien été pris en compte :

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
SHOW VARIABLES LIKE 'query_cache_size';

Par défaut, MariaDB écoute uniquement sur 127.0.0.1 — c'est la configuration sécurisée par défaut. Pour les accès depuis une application sur un autre serveur, deux approches existent.

Option 1 — Tunnel SSH (recommandée, sans ouvrir le port 3306)

Depuis votre machine locale ou votre serveur applicatif :

ssh -L 3306:127.0.0.1:3306 -N root@<ip-vps-mariadb>

Votre application se connecte ensuite à 127.0.0.1:3306 localement — le tunnel SSH chiffre le trafic. Ajoutez -f pour mettre le tunnel en arrière-plan.

Option 2 — Connexion inter-VPS avec allowlisting IP

Si votre application tourne sur un autre VPS ServOrbit (ex. : un VPS applicatif distinct du VPS base de données), ouvrez le port uniquement pour l'IP privée de ce serveur :

# Dans /etc/mysql/conf.d/network.cnf
[mysqld]
bind-address = 0.0.0.0

# Autoriser uniquement l'IP du serveur applicatif
ufw allow from <ip-app> to any port 3306

Créez l'utilisateur MariaDB en limitant son origine à l'IP du serveur applicatif :

CREATE USER 'app'@'<ip-app>' IDENTIFIED BY 'mot_de_passe_fort';
GRANT ALL PRIVILEGES ON mon_app.* TO 'app'@'<ip-app>';
FLUSH PRIVILEGES;

Ne créez jamais un compte 'user'@'%' (wildcard d'hôte) : cela autorise la connexion depuis n'importe quelle IP — si le port 3306 venait à s'ouvrir par erreur, le compte serait directement accessible depuis Internet.

Voici les quatre erreurs les plus fréquentes lors de l'exploitation de MariaDB sur VPS, et leur résolution.

1. Can't connect to local MariaDB server through socket

Le service MariaDB n'est pas démarré ou le socket est introuvable.

systemctl status mariadb
systemctl start mariadb

Si le service refuse de démarrer, lisez les journaux :

journalctl -xe -u mariadb --no-pager | tail -40

Cause fréquente : innodb_buffer_pool_size trop grand pour la RAM disponible — MariaDB s'arrête immédiatement sans message évident. Réduisez la valeur dans /etc/mysql/conf.d/performance.cnf.

2. Too many connections

Le nombre de connexions simultanées atteint la limite. Augmentez max_connections dans /etc/mysql/conf.d/performance.cnf puis rechargez :

systemctl reload mariadb

Inspectez les connexions actives avant d'augmenter : SHOW PROCESSLIST; dans le shell MariaDB. Des centaines de connexions inactives signalent souvent un pool de connexions mal configuré côté application.

3. Table '<nom>' is marked as crashed

Une table MyISAM est corrompue (crash système, coupure d'alimentation). Réparez-la :

mysqlcheck -u root -p --repair mon_app nom_de_la_table

Si vous utilisez InnoDB (cas général), cette erreur est rare ; une corruption InnoDB se résout par restauration de sauvegarde. C'est une raison supplémentaire d'activer les sauvegardes automatisées.

4. Access denied for user 'root'@'localhost'

Mot de passe root oublié ou plugin d'authentification modifié. Réinitialisez en mode sans authentification :

systemctl stop mariadb
mysqld_safe --skip-grant-tables &
mariadb -u root

Puis dans le shell MariaDB :

FLUSH PRIVILEGES;
ALTER USER 'root'@'localhost' IDENTIFIED BY 'nouveau_mot_de_passe';
FLUSH PRIVILEGES;
EXIT;

Relancez MariaDB normalement : systemctl restart mariadb.