MariaDB Sans Trembler — Amine RAITI

100%

GRIMOIRE❦

Grimoire Corpus Dindon Volumes de Synthèse Le Socle du Fer

RATIO

TUTORIEL TECHNIQUE · OPÉRATION DINDON · JUIN 2026

◆◆◆

MARIADB
SANS TREMBLER
Migration et Réplication en Flux Tendu
XtraBackup · Streaming SSH · Multi-To sans saturer le disque

◆

◆ CONTEXTE DE CE TUTORIEL

Dupliquer plusieurs To de données en production ne s'improvise pas. Si tu satures ton disque ou bloques tes tables, tu n'es plus un ingénieur — tu es un saboteur. Ce tutoriel documente la méthode complète : streaming SSH sans stockage local, préparation des données, réplication binlog et GTID, vérification post-déploiement. Propre et direct.

VOLUME

Multi-To

DOWNTIME

Zéro

STOCKAGE LOCAL

Zéro

◆◆◆

Amine RAITI — Architecte Infrastructure & SRE
Ancien professeur en école d'ingénieurs · Formateur infrastructure
Document public · CC BY-NC-SA 4.0 · AI Powered by Amine · Opération Dindon

RATIO

SECTION 1 · POURQUOI XTRABACKUP — ET PAS LES AUTRES

CHOISIR LA BONNE MÉTHODE AVANT DE COMMENCER

◆

◆ COMPARATIF DES MÉTHODES DE MIGRATION

mysqldump / mariadb-dump : simple, universel, lisible. Mais il verrouille les tables (ou produit des données incohérentes sans lock), génère un fichier SQL à réimporter ligne par ligne, et devient impraticable au-delà de quelques dizaines de Go. À réserver aux petites bases ou aux migrations ponctuelles sans contrainte de temps.

Snapshot LVM : rapide et cohérent si le volume MySQL est sur LVM. Mais requiert une configuration LVM préalable, un espace snapshot suffisant, et une fenêtre de maintenance de quelques secondes pour la prise du snapshot.

Galera Cluster (SST/IST) : idéal pour les clusters multi-maîtres déjà en place. Hors de propos pour une migration one-shot source → cible.

XtraBackup / Mariabackup : backup physique à chaud, sans verrouillage des tables InnoDB, streaming direct vers la cible, cohérence garantie par les logs de transaction. C'est la méthode pour les bases multi-To en production sans downtime.

⚠️ XTRABACKUP VS MARIABACKUP — NE PAS CONFONDRE

À partir de MariaDB 10.2+, Percona XtraBackup n'est plus pleinement compatible. Il faut utiliser Mariabackup — le fork officiel de MariaDB. Les commandes sont quasi-identiques mais les binaires diffèrent : mariabackup au lieu de xtrabackup. Vérifier la version : mariadb --version. Ce tutoriel utilise la syntaxe xtrabackup pour la lisibilité — adapter selon la version installée.

◆ QUAND UTILISER LE STREAMING SSH

Le streaming SSH pipe la donnée directement de la SOURCE vers la CIBLE sans jamais écrire sur le disque de la SOURCE. Trois avantages critiques :
— Zéro saturation disque sur la source : une base de 3 To ne nécessite pas 3 To libres supplémentaires sur le serveur source.
— Transfert en temps réel : la donnée arrive sur la cible au fur et à mesure qu'elle est lue, réduisant le temps total de migration.
— Un seul point de contrôle : si le transfert échoue, on recommence. Pas de fichier intermédiaire corrompu à gérer.

Prérequis : connexion SSH sans mot de passe entre les deux serveurs (clé publique déployée) et bande passante réseau suffisante entre SOURCE et CIBLE.

RATIO

SECTION 2 · PRÉPARATION — CHECKLIST AVANT DE TOUCHER QUOI QUE CE SOIT

L'ALIGNEMENT DES ASTRES

◆

✅ CHECKLIST PRÉ-MIGRATION

□ Versions identiques de MariaDB sur SOURCE et CIBLE (mariadb --version)
□ Versions identiques de XtraBackup/Mariabackup sur les deux serveurs
□ Espace disque CIBLE ≥ taille des datafiles SOURCE + 20% de marge (du -sh /var/lib/mysql)
□ Connexion SSH sans mot de passe SOURCE → CIBLE et CIBLE → SOURCE
□ Toutes les tables critiques sont InnoDB (si MyISAM présent, voir avertissement ci-dessous)
□ Binlog activé sur la SOURCE (SHOW VARIABLES LIKE 'log_bin')
□ GTID activé ou non — décider de la méthode de réplication avant de commencer
□ Pare-feu : port MySQL (3306 ou custom) ouvert entre SOURCE et CIBLE

⚠️ DANGER MyISAM — LIRE AVANT D'UTILISER --no-lock

--no-lock est sûr UNIQUEMENT si toutes les tables sont InnoDB. Une seule table MyISAM dans la base produit une incohérence silencieuse — le backup semblera réussir mais les données MyISAM seront potentiellement corrompues. Vérifier : SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='votre_base' AND ENGINE != 'InnoDB'; Si résultat non vide : convertir en InnoDB ou utiliser --lock-ddl-per-table à la place de --no-lock.

◆ CRÉATION DES UTILISATEURS SUR LA SOURCE

SQL — EXÉCUTER SUR LA SOURCE

-- Utilisateur pour XtraBackup (backup physique)
CREATE USER 'xtrabackup'@'localhost' IDENTIFIED BY 'SuperStrongPass';
GRANT RELOAD, LOCK TABLES, PROCESS, REPLICATION CLIENT
  ON *.* TO 'xtrabackup'@'localhost';

-- Utilisateur pour la réplication continue
CREATE USER 'repl_user'@'%' IDENTIFIED BY 'REPL_PASSWORD';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';
FLUSH PRIVILEGES;

Note : REPLICATION CLIENT permet à XtraBackup de lire la position binlog. RELOAD est requis pour FLUSH TABLES. LOCK TABLES est utilisé même avec --no-lock pour les tables non-InnoDB.

RATIO

SECTION 3 · LE STREAMING SSH — L'ASPIRATION PAR LE VIDE

ON PIPE LA DONNÉE DIRECTEMENT — RIEN NE TOUCHE LE DISQUE SOURCE

◆

◆ LA COMMANDE DE STREAMING — EXÉCUTÉE SUR LA CIBLE

BASH — EXÉCUTER SUR LA CIBLE (elle tire la donnée depuis la SOURCE)

ssh root@source-db-server "bash -c '
  ulimit -n 1048576
  xtrabackup --backup \
    --user=xtrabackup \
    --password="SuperStrongPass" \
    --socket=/var/run/mysqld/mysql.sock \
    --no-lock \
    --parallel=4 \
    --stream=xbstream
'" | xbstream -x -C /backup/source-db-server

◆ DÉCRYPTAGE OPTION PAR OPTION

ulimit -n 1048576 : augmente le nombre maximum de descripteurs de fichiers ouverts simultanément. Sur les grandes bases avec beaucoup de tables, XtraBackup peut atteindre la limite système par défaut (1024) et échouer. Cette ligne l'évite.

--no-lock : supprime le FLUSH TABLES WITH READ LOCK global. La production continue sans interruption. UNIQUEMENT sûr avec 100% InnoDB (voir Section 2).

--parallel=4 : nombre de threads de lecture en parallèle. Adapter selon les CPU disponibles sur la SOURCE. Commencer à 4, monter si la bande passante réseau n'est pas le goulot.

--stream=xbstream : format de streaming propriétaire XtraBackup, plus efficace que tar pour les fichiers MySQL.

--socket : chemin vers le socket Unix de MariaDB. Varie selon la distribution : /var/run/mysqld/mysql.sock (Debian/Ubuntu) ou /tmp/mysql.sock (CentOS/RHEL). Vérifier : SHOW VARIABLES LIKE 'socket';

xbstream -x -C /backup/source-db-server : extraction du stream sur la CIBLE dans le répertoire cible. S'assurer que ce répertoire existe et a l'espace suffisant.

✅ SURVEILLER LE TRANSFERT EN COURS

# Sur la CIBLE — surveiller la progression
watch -n 5 "du -sh /backup/source-db-server"

# Sur la SOURCE — surveiller le processus XtraBackup
tail -f /var/log/mysql/xtrabackup.log

RATIO

SECTION 4 · PREPARE ET RESTORE — LA MÉTAMORPHOSE

RENDRE LA DONNÉE VIVANTE — PUIS L'INJECTER

◆

◆ ÉTAPE 1 — PREPARE : CONSOLIDATION DES LOGS DE TRANSACTION

Le backup physique capturé en flux tendu contient des pages de données potentiellement incohérentes — des transactions ouvertes au moment de la capture. --prepare applique le redo log et rollback les transactions incomplètes, rendant le backup cohérent et restaurable. Cette étape est obligatoire. Sans elle, MariaDB refusera de démarrer sur les fichiers restaurés.

BASH — EXÉCUTER SUR LA CIBLE

# Consolidation des logs — rend le backup cohérent
xtrabackup --prepare --target-dir=/backup/source-db-server

# Vérifier que la préparation s'est terminée sans erreur
echo $? # doit retourner 0

◆ ÉTAPE 2 — RESTORE : DÉPLOIEMENT SUR LA CIBLE

⚠️ ARRÊTER MARIADB SUR LA CIBLE AVANT LE RESTORE

systemctl stop mariadb — Le répertoire de données doit être vide. Ne jamais restaurer sur un MariaDB en cours d'exécution.

BASH — EXÉCUTER SUR LA CIBLE

# Vider le répertoire de données (IRRÉVERSIBLE — vérifier deux fois)
rm -rf /var/lib/mysql/*

# Restaurer les fichiers depuis le backup préparé
xtrabackup --copy-back   --target-dir=/backup/source-db-server   --datadir=/var/lib/mysql

# Corriger les permissions (OBLIGATOIRE)
chown -R mysql:mysql /var/lib/mysql

# Démarrer MariaDB
systemctl start mariadb
systemctl status mariadb

◆ NASSIHA — NE PAS OUBLIER LES PERMISSIONS

XtraBackup restaure les fichiers avec les permissions de l'utilisateur qui exécute la commande (souvent root). Sans le chown -R mysql:mysql, MariaDB refusera de démarrer avec une erreur de permissions. C'est l'erreur la plus fréquente à cette étape.

RATIO

SECTION 5 · LA RÉPLICATION — LE LIEN SACRÉ

CONNECTER SOURCE ET CIBLE — DEUX MÉTHODES

◆

◆ RÉCUPÉRER LES COORDONNÉES DE RÉPLICATION

XtraBackup a créé le fichier xtrabackup_binlog_info dans le répertoire de backup. Il contient la position exacte dans le binlog au moment de la capture.

BASH — LIRE LES COORDONNÉES

cat /backup/source-db-server/xtrabackup_binlog_info
# Exemple de sortie :
mysql-bin.000123    456789    0-1-12345
# Colonne 1 : fichier binlog
# Colonne 2 : position (méthode classique)
# Colonne 3 : GTID position (si GTID activé)

◆ MÉTHODE A — BINLOG CLASSIQUE (SANS GTID)

SQL — EXÉCUTER SUR LA CIBLE

STOP SLAVE;
CHANGE MASTER TO
  MASTER_HOST='source-db-server',
  MASTER_PORT=3306,
  MASTER_USER='repl_user',
  MASTER_PASSWORD='REPL_PASSWORD',
  MASTER_LOG_FILE='mysql-bin.000123',
  MASTER_LOG_POS=456789;
START SLAVE;

◆ MÉTHODE B — GTID (RECOMMANDÉ MARIADB 10.2+)

Plus robuste — survit aux redémarrages et aux failovers sans reconfiguration manuelle de la position.

SQL — EXÉCUTER SUR LA CIBLE

STOP SLAVE;
-- Injecter la position GTID depuis xtrabackup_binlog_info (3ème colonne)
SET GLOBAL gtid_slave_pos = '0-1-12345';
CHANGE MASTER TO
  MASTER_HOST='source-db-server',
  MASTER_PORT=3306,
  MASTER_USER='repl_user',
  MASTER_PASSWORD='REPL_PASSWORD',
  MASTER_USE_GTID=slave_pos;
START SLAVE;

RATIO

SECTION 6 · VÉRIFICATION — NE PAS PARTIR AVANT D'AVOIR CONFIRMÉ

SHOW SLAVE STATUS — DÉCRYPTAGE COMPLET

◆

◆ LA COMMANDE DE VÉRIFICATION

SQL — EXÉCUTER SUR LA CIBLE

SHOW SLAVE STATUS\G

Slave_IO_Running: Yes — le thread I/O est connecté à la SOURCE et lit le binlog. Si No : problème réseau ou credentials incorrects.
Slave_SQL_Running: Yes — le thread SQL applique les événements sur la CIBLE. Si No : erreur SQL, voir Last_SQL_Error.
Seconds_Behind_Master: 0 — la CIBLE est synchronisée. Une valeur non nulle indique un retard de réplication — normal juste après le démarrage, doit converger vers 0.
Last_IO_Error / Last_SQL_Error — si non vides : lire et traiter avant de continuer.

⚠️ ERREURS FRÉQUENTES ET CORRECTIONS

Error 1236 — Could not find first log file : la position binlog dans xtrabackup_binlog_info est dépassée (les binlogs ont été purgés sur la SOURCE). Solution : purge_logs_before ou refaire le backup.

Error 1062 — Duplicate entry : une ligne existe déjà sur la CIBLE. Si non critique : SET GLOBAL slave_skip_errors = 1062; et redémarrer le slave. Analyser l'origine.

Error 2003 — Can't connect to MySQL server : vérifier le pare-feu sur la SOURCE, le bind-address dans my.cnf (bind-address = 0.0.0.0 ou l'IP de la CIBLE).

Slave_IO_Running: Connecting : credentials incorrects ou compte repl_user non autorisé depuis l'IP de la CIBLE. Vérifier SHOW GRANTS FOR 'repl_user'@'%';

✅ SURVEILLANCE POST-DÉPLOIEMENT

# Surveiller le rattrapage du retard en temps réel
watch -n 2 "mysql -e 'SHOW SLAVE STATUS\G' | grep -E 'Running|Behind|Error'"

# Vérifier la cohérence d'une table entre SOURCE et CIBLE
# Sur SOURCE :
SELECT COUNT(*), MAX(id) FROM ma_table;
# Sur CIBLE (après Seconds_Behind_Master = 0) :
SELECT COUNT(*), MAX(id) FROM ma_table;

◆◆◆

Si tu satures le disque ou bloques les tables, tu n'es plus un ingénieur — tu es un saboteur. Cette méthode évite les deux. Propre et direct.

NEMO SUPRA LEGEM EST