Réplication des données : bases de données, fichiers et stockage

La réplication recopie automatiquement les modifications d'un système (une base de données, un dossier partagé, un disque) vers une ou plusieurs copies, pour qu'une autre machine puisse reprendre le service avec des données à jour. Selon qu'elle est synchrone ou asynchrone, elle fixe la quantité de données qu'on risque de perdre lors d'une bascule. Ce chapitre explique cette différence, puis la réplication des bases MariaDB et MySQL, celle des fichiers avec DFS et sous Linux, et les pièges qui transforment une réplication en perte de données.

Réplication, RAID et sauvegarde : trois protections différentes

Ces trois techniques font des copies, mais elles ne protègent pas contre les mêmes choses.

La réplication est un outil de disponibilité ; la sauvegarde, de récupération. Une infrastructure sérieuse a les deux : le cours sauvegarde et PRA traite de la seconde.

Synchrone ou asynchrone

En réplication synchrone, une écriture n'est confirmée à l'application qu'une fois enregistrée sur la copie. Si le serveur principal tombe, la copie a tout : aucune donnée validée n'est perdue (RPO nul). En contrepartie, chaque écriture attend l'aller-retour réseau vers la copie, ce qui ralentit l'application et limite la distance entre les deux sites ; et si la copie ne répond plus, le principal doit soit bloquer les écritures, soit passer temporairement en asynchrone.

En réplication asynchrone, l'écriture est confirmée dès qu'elle est enregistrée sur le principal, puis envoyée à la copie juste après. L'application ne ralentit pas, la copie peut être loin, mais elle a toujours un peu de retard : si le principal tombe, les écritures pas encore transmises sont perdues. Le RPO vaut ce retard, en général moins d'une seconde, davantage en cas de forte charge ou de réseau lent.

En réplication semi-synchrone, une solution intermédiaire de MySQL et MariaDB, le principal attend seulement qu'au moins une copie ait reçu la transaction (pas forcément appliquée) avant de la confirmer.

Répliquer une base MariaDB ou MySQL

Le principe est le même pour MariaDB (le SGBD fourni par Debian 13, en version 11.8) et MySQL : le serveur source écrit chaque modification dans son journal binaire (binary log), et chaque réplica lit ce journal, le recopie dans un journal local, puis rejoue les modifications sur ses propres données. La réplication est asynchrone par défaut. Le chapitre sur la sauvegarde d'une base MySQL du cours SQL en présente le principe ; voici sa mise en place pour Ravelle Conseil, avec la source SRV-DB (10.10.20.35) et un réplica SRV-DB2 (10.10.20.36).

Sur la source, dans un fichier /etc/mysql/mariadb.conf.d/60-replication.cnf :

[mariadb]
server_id = 1
log_bin   = mariadb-bin
bind-address = 10.10.20.35

Chaque serveur d'une réplication a un server_id unique. Le journal binaire n'est pas actif par défaut dans MariaDB (il l'est dans MySQL depuis la version 8.0) : log_bin l'active. Après un redémarrage de MariaDB, on crée le compte de réplication, limité à l'adresse du réplica et au seul droit nécessaire :

CREATE USER 'repl'@'10.10.20.36' IDENTIFIED BY 'Une-Longue-Phrase-De-Passe';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'10.10.20.36';

La copie initiale. Le réplica doit partir d'une copie exacte des données, avec la position correspondante dans le journal binaire. mariadb-dump --all-databases --single-transaction --master-data=1 --gtid produit un fichier qui contient les données et cette position ; pour une grosse base, mariadb-backup copie les fichiers à chaud, plus vite.

Sur le réplica, avec server_id = 2 et read_only = ON dans sa configuration, puis, une fois la copie initiale importée :

CHANGE MASTER TO
    MASTER_HOST = '10.10.20.35',
    MASTER_USER = 'repl',
    MASTER_PASSWORD = 'Une-Longue-Phrase-De-Passe',
    MASTER_USE_GTID = slave_pos;
START REPLICA;
SHOW REPLICA STATUS\G

Les trois lignes à lire dans le résultat :

       Slave_IO_Running: Yes
      Slave_SQL_Running: Yes
  Seconds_Behind_Master: 0

Slave_IO_Running dit que le réplica reçoit le journal de la source ; Slave_SQL_Running, qu'il rejoue les modifications ; Seconds_Behind_Master, son retard estimé. Sous MySQL 8.4, les commandes et les colonnes ont été renommées (CHANGE REPLICATION SOURCE TO, SOURCE_HOST, Replica_IO_Running, Seconds_Behind_Source), mais leur rôle est identique. Les identifiants de transaction globaux (GTID) permettent au réplica de savoir exactement où il en est, ce qui simplifie les bascules.

La bascule vers le réplica. Si SRV-DB tombe, la promotion de SRV-DB2 se fait ainsi :

1. Vérifier que le réplica a appliqué tout ce qu'il a reçu (Seconds_Behind_Master à 0, ou l'arrêt du rejeu constaté).
2. Arrêter la réplication et en effacer la configuration : STOP REPLICA; puis RESET REPLICA ALL;.
3. Autoriser les écritures : SET GLOBAL read_only = OFF;.
4. Diriger l'application vers le nouveau serveur : en changeant l'adresse dans sa configuration, ou mieux en déplaçant une adresse virtuelle que l'application utilise toujours.
5. Empêcher l'ancienne source de revenir comme source : à son redémarrage, elle se croirait encore principale, et deux serveurs accepteraient des écritures. On la reconstruit comme réplica du nouveau principal.

Faite à la main, en suivant une procédure écrite, cette bascule prend quelques minutes. Des outils l'automatisent : MaxScale pour MariaDB, InnoDB Cluster (réplication de groupe et MySQL Router) pour MySQL. Pour PostgreSQL, l'équivalent est la réplication en continu (streaming replication), automatisée par des outils comme Patroni.

Le cluster multi-maître synchrone : Galera. MariaDB Galera Cluster réunit au moins trois nœuds, tous accessibles en écriture : chaque transaction est certifiée par l'ensemble du cluster avant d'être validée, ce qui évite les conflits, et un nœud qui perd le quorum refuse les requêtes. Placé derrière HAProxy, un cluster Galera supprime la bascule manuelle : la panne d'un nœud ne coupe rien. En contrepartie, les écritures sont plus lentes (chaque validation attend le cluster), il faut trois nœuds et un réseau fiable, et certaines opérations (les très grosses transactions) s'y comportent mal.

Répliquer des fichiers sous Windows : DFS

Sous Windows Server, deux rôles complémentaires portent le nom DFS (Distributed File System) :

• DFS-N (espaces de noms) donne aux utilisateurs un chemin unique, par exemple \\ravelle.lan\partages\commun, qui pointe vers une ou plusieurs cibles réelles : \\SRV-FIC1\commun et \\SRV-FIC2\commun. Si une cible ne répond plus, le client utilise l'autre ;
• DFS-R (réplication) tient les cibles synchronisées : une réplication multi-maître (on peut modifier un fichier sur n'importe quel serveur), qui ne transfère que les parties modifiées des fichiers (la compression différentielle à distance, RDC), selon une planification et une bande passante réglables.

# Sur les deux serveurs de fichiers
Install-WindowsFeature FS-DFS-Namespace, FS-DFS-Replication -IncludeManagementTools

# Le groupe de réplication et ses membres
New-DfsReplicationGroup -GroupName "RG-Partages"
New-DfsReplicatedFolder -GroupName "RG-Partages" -FolderName "Commun"
Add-DfsrMember -GroupName "RG-Partages" -ComputerName SRV-FIC1, SRV-FIC2
Add-DfsrConnection -GroupName "RG-Partages" -SourceComputerName SRV-FIC1 -DestinationComputerName SRV-FIC2
Set-DfsrMembership -GroupName "RG-Partages" -FolderName "Commun" -ComputerName SRV-FIC1 `
    -ContentPath "D:\Partages\Commun" -PrimaryMember $true
Set-DfsrMembership -GroupName "RG-Partages" -FolderName "Commun" -ComputerName SRV-FIC2 `
    -ContentPath "D:\Partages\Commun"

# Le retard de réplication : les fichiers en attente d'envoi
Get-DfsrBacklog -GroupName "RG-Partages" -FolderName "Commun" `
    -SourceComputerName SRV-FIC1 -DestinationComputerName SRV-FIC2

Le membre principal (-PrimaryMember) fait autorité lors de la première synchronisation : son contenu l'emporte sur celui de l'autre serveur. La connexion créée par Add-DfsrConnection fonctionne dans les deux sens par défaut.

La limite de DFS-R : pas de verrou partagé. Deux utilisateurs qui ouvrent le même fichier, l'un sur SRV-FIC1, l'autre sur SRV-FIC2, peuvent le modifier en même temps : DFS-R ne verrouille pas un fichier d'un serveur à l'autre. À la réplication, la dernière version enregistrée gagne, et l'autre est déplacée dans un dossier caché de conflits (ConflictAndDeleted). Pour des fichiers modifiés par plusieurs personnes, on configure donc DFS-N pour que tous les utilisateurs d'un site travaillent sur la même cible, l'autre ne servant qu'en secours. Pour une vraie haute disponibilité d'un serveur de fichiers, avec bascule transparente des fichiers ouverts, Windows Server propose le serveur de fichiers en cluster de basculement.

DFS-R réplique aussi le dossier SYSVOL des contrôleurs de domaine, qui contient les stratégies de groupe et les scripts d'ouverture de session (chapitre 10).

Répliquer des fichiers sous Linux

Pour les serveurs web de Ravelle Conseil, la solution la plus simple consiste à ne garder aucune donnée sur WEB1 et WEB2 : le code est déployé à l'identique sur les deux, les données sont dans la base, et les documents déposés par les utilisateurs dans un stockage commun. Les serveurs deviennent interchangeables, et leur panne ne fait rien perdre.

Choisir une solution de réplication

Exercices

       Slave_IO_Running: Yes
      Slave_SQL_Running: No
  Seconds_Behind_Master: NULL
         Last_SQL_Error: Could not execute Write_rows event on table intranet.document;
                         Duplicate entry '1542' for key 'PRIMARY'