MariaDB : Mise en place d'une réplication Master → Slave - LibrA-LinuX

MariaDB : Mise en place d’une réplication Master → Slave

20 juillet 2026 — par admin_libra

La réplication MariaDB est l’une des techniques fondamentales pour mettre en place une architecture de base de données résiliente. Dans un modèle Master → Slave, toutes les écritures s’effectuent sur le serveur primaire (Master), qui enregistre chaque modification dans un journal binaire (binlog). Le serveur secondaire (Slave) lit ce journal en continu et rejoue les opérations pour maintenir une copie synchronisée des données.

Cette architecture présente plusieurs avantages immédiats : la distribution de la charge en lecture (les requêtes SELECT peuvent être redirigées vers le Slave), la sauvegarde sans impact (on dump le Slave pendant que le Master continue de servir), et un socle solide pour la haute disponibilité en cas de panne du Master.

Ce tutoriel couvre l’installation et la configuration complète d’une réplication MariaDB 11.x sur deux serveurs Debian/Ubuntu, de la configuration des fichiers my.cnf jusqu’à la vérification du statut de synchronisation.

Prérequis

Deux serveurs Debian 12 / Ubuntu 24.04 (ou versions LTS récentes)
MariaDB 11.x installé sur les deux serveurs (voir ci-dessous)
Connectivité réseau entre les deux serveurs sur le port 3306/tcp
Accès root ou sudo sur les deux machines

Pour cet article, on utilisera :

Master : 192.168.1.10
Slave : 192.168.1.20

Installation de MariaDB 11.x sur Debian/Ubuntu

Si MariaDB n’est pas encore installé, utilisez le script officiel de MariaDB Foundation pour ajouter le dépôt et installer la version LTS 11.4 :

# Installer les dépendances nécessaires
apt update && apt install -y apt-transport-https curl gnupg

# Ajouter le dépôt officiel MariaDB 11.4 LTS
curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup 
  | bash -s -- --mariadb-server-version="mariadb-11.4"

# Installer MariaDB
apt install -y mariadb-server mariadb-client

# Activer et démarrer le service
systemctl enable --now mariadb

# Sécurisation initiale
mariadb-secure-installation

Répétez cette opération sur les deux serveurs.

Configuration du serveur Master

Activation du binlog et identifiant de serveur

Le binlog (journal binaire) est le mécanisme central de la réplication. Créez un fichier de configuration dédié sur le Master :

# Sur le Master (192.168.1.10)
cat > /etc/mysql/mariadb.conf.d/60-replication.cnf << 'EOF'
[mariadb]
# Identifiant unique du serveur (entier entre 1 et 2^32-1)
server-id               = 1

# Activation et nommage du binlog
log-bin                 = mariadb-bin
log-basename            = master1

# Format ROW : réplication ligne par ligne, plus fiable que STATEMENT
binlog-format           = ROW

# Purge automatique des binlogs après 7 jours
expire_logs_days        = 7

# Écouter sur toutes les interfaces réseau
bind-address            = 0.0.0.0
EOF

systemctl restart mariadb

Important : Le paramètre bind-address = 0.0.0.0 est nécessaire pour que le Slave puisse se connecter. En production, préférez restreindre l’accès via nftables ou en spécifiant l’IP du réseau interne.

Création de l’utilisateur de réplication

Sur le Master, connectez-vous à MariaDB et créez un utilisateur dédié à la réplication, en restreignant son accès à l’IP du Slave :

# Connexion à MariaDB sur le Master
mariadb -u root -p

-- Créer l'utilisateur de réplication restreint à l'IP du Slave
CREATE USER 'replicator'@'192.168.1.20' IDENTIFIED BY 'MotDePasseF0rt!';

-- Accorder uniquement le privilège de réplication
GRANT REPLICATION SLAVE ON *.* TO 'replicator'@'192.168.1.20';

-- Appliquer les privilèges
FLUSH PRIVILEGES;

Récupération des coordonnées du binlog

Avant d’exporter les données, verrouillez les tables en lecture pour obtenir une position cohérente du binlog :

-- Verrouillage en lecture (ne pas fermer cette session !)
FLUSH TABLES WITH READ LOCK;

-- Relever le fichier et la position courants
SHOW MASTER STATUS;
-- +--------------------+----------+
-- | File               | Position |
-- +--------------------+----------+
-- | master1-bin.000001 |      684 |
-- +--------------------+----------+

Notez le fichier et la position — vous en aurez besoin lors de la configuration du Slave.

Export des données du Master

Dans un deuxième terminal (laissez ouvert le terminal avec le verrou), exportez les données :

# Export avec inclusion automatique de la position binlog dans le dump
mariadb-dump 
  --user=root 
  --password 
  --all-databases 
  --master-data=2 
  --single-transaction 
  --routines 
  --triggers 
  > /tmp/master_dump.sql

# Vérifier que la position binlog est bien inscrite en commentaire
head -50 /tmp/master_dump.sql | grep "CHANGE MASTER"

Une fois le dump terminé, déverrouillez les tables dans le premier terminal :

-- Déverrouillage des tables sur le Master
UNLOCK TABLES;

Transférez ensuite le dump vers le Slave via scp :

# Depuis le Master, transfert vers le Slave
scp /tmp/master_dump.sql [email protected]:/tmp/

Configuration du serveur Slave

Paramétrage my.cnf

Sur le Slave, créez le fichier de configuration avec un server-id différent et activez le relay-log :

# Sur le Slave (192.168.1.20)
cat > /etc/mysql/mariadb.conf.d/60-replication.cnf << 'EOF'
[mariadb]
# Identifiant unique, différent du Master
server-id               = 2

# Relay log : journal local des événements reçus du Master
relay-log               = relay-bin
relay-log-index         = relay-bin.index

# Mode lecture seule : interdire les écritures directes sur le Slave
read_only               = 1

# Empêcher toute écriture même pour les comptes SUPER (MariaDB 10.5+)
super_read_only         = 1

# Propager les événements reçus dans le binlog local (utile pour chaînage)
log-slave-updates       = 1
EOF

systemctl restart mariadb

Import des données et connexion au Master

Importez le dump du Master sur le Slave, puis configurez la connexion de réplication :

# Import du dump sur le Slave
mariadb -u root -p < /tmp/master_dump.sql

-- Connexion à MariaDB sur le Slave
mariadb -u root -p

-- Configurer la connexion au Master avec les coordonnées relevées précédemment
CHANGE MASTER TO
  MASTER_HOST     = '192.168.1.10',
  MASTER_USER     = 'replicator',
  MASTER_PASSWORD = 'MotDePasseF0rt!',
  MASTER_LOG_FILE = 'master1-bin.000001',
  MASTER_LOG_POS  = 684;

-- Démarrer la réplication
START SLAVE;

Vérification du statut de la réplication

Immédiatement après avoir démarré le Slave, vérifiez le statut :

-- Vérification complète du statut (sortie formatée verticalement)
SHOW SLAVE STATUS G

Les deux lignes critiques à surveiller :

Slave_IO_Running: Yes    # Thread de lecture du binlog Master : actif
Slave_SQL_Running: Yes   # Thread d'exécution des requêtes : actif
Seconds_Behind_Master: 0 # Retard en secondes (0 = à jour)

Si l’un des threads affiche No ou Connecting, consultez le champ Last_Error dans la sortie pour diagnostiquer le problème (erreur de connexion, conflit de données, fichier binlog introuvable).

Aller plus loin : réplication via GTID

Les GTID (Global Transaction Identifiers) simplifient la gestion de la réplication en s’affranchissant des coordonnées binlog manuelles. MariaDB implémente son propre système GTID, activé par défaut depuis la version 10.x. Pour basculer vers la réplication GTID :

-- Sur le Slave : arrêter la réplication et reconfigurer avec GTID
STOP SLAVE;

CHANGE MASTER TO
  MASTER_HOST     = '192.168.1.10',
  MASTER_USER     = 'replicator',
  MASTER_PASSWORD = 'MotDePasseF0rt!',
  MASTER_USE_GTID = slave_pos;

START SLAVE;
SHOW SLAVE STATUS G

Avec les GTID, le Slave reprend automatiquement à la bonne position après un redémarrage, et le basculement vers un nouveau Master est facilité car il n’est plus nécessaire de rechercher les coordonnées binlog manuellement.

Bonnes pratiques et sécurité

Restreindre le port 3306 : n’exposez jamais le port MariaDB sur l’interface publique. Utilisez nftables pour limiter l’accès au seul IP du Slave.
Chiffrement du flux de réplication : ajoutez MASTER_SSL=1, MASTER_SSL_CA, MASTER_SSL_CERT et MASTER_SSL_KEY dans CHANGE MASTER TO pour chiffrer le canal entre Master et Slave.
Privilège minimal : l’utilisateur replicator n’a que le droit REPLICATION SLAVE — ne lui accordez aucun autre privilège.
Surveiller le retard : intégrez Seconds_Behind_Master dans votre outil de supervision (Prometheus, Zabbix, Netdata) et déclenchez une alerte si la valeur dépasse un seuil critique.
Tester le basculement : documentez et exercez régulièrement la procédure de promotion du Slave en Master (STOP SLAVE; RESET SLAVE ALL; puis reconfiguration applicative).
Purger les binlogs : expire_logs_days évite la saturation du disque sur le Master. Ajustez la valeur en fonction de votre volume d’écritures.