Aller au contenu principal

Qu'est-ce que la réplication

La réplication est un processus par lequel :

  • les données d'une base de données MariaDB sont copiées (répliquées) d'un serveur MariaDB (appelé le serveur principal)
  • vers un ou plusieurs serveurs MariaDB (appelés serveurs secondaires).

Cela peut être utilisé :

  • pour des raisons de performance (répartir la charge de lecture entre plusieurs serveurs),
  • pour des raisons de sécurité (avoir une copie des données en cas de panne du serveur principal)
  • ou pour des raisons de disponibilité des données (avoir les données disponibles à plusieurs endroits).

Notions théoriques​

  1. Configuration du serveur principal : Le serveur principal doit être configuré pour enregistrer toutes les modifications apportées aux données dans un journal binaire. Cela est fait en modifiant le fichier de configuration de MariaDB (généralement situé à /etc/mysql/mariadb.conf.d/50-server.cnf) et en ajoutant/modifiant les lignes suivantes :

    log_bin = /var/log/mysql/mariadb-bin
    log_bin_index = /var/log/mysql/mariadb-bin.index
    server-id = 1

    Si le dossier mysql n'existe pas dans /var/log, il faut le créer avec la commande mkdir -p /var/log/mysql.

    Le server-id doit être unique pour chaque serveur impliqué dans la réplication.

  2. Configuration du serveur secondaire : Le serveur secondaire doit également être configuré pour enregistrer les modifications dans un journal de relais. Cela est fait en ajoutant les lignes suivantes au fichier de configuration de MariaDB :

    relay_log = /var/log/mysql/mariadb-relay-bin
    relay_log_index = /var/log/mysql/mariadb-relay-bin.index
    server-id = 2

    Le server-id doit être différent de celui du serveur principal.

  3. Création d'un utilisateur de réplication : Sur le serveur principal, un utilisateur de réplication doit être créé. Cet utilisateur est utilisé par le serveur secondaire pour se connecter au serveur principal et copier les modifications. La commande pour créer un utilisateur de réplication est la suivante :

    CREATE USER 'replication'@'adresse_ip_du_serveur_secondaire' IDENTIFIED BY 'password';
    GRANT REPLICATION SLAVE ON *.* TO 'replication'@'adresse_ip_du_serveur_secondaire';

  4. Affichage des informations : Sur le serveur principal, on peut afficher les informations utiles ( MASTER_LOG_FILE et de MASTER_LOG_POS) pour le serveur secondaire en exécutant la commande suivante :

    SHOW MASTER STATUS;

  5. Démarrage de la réplication : Sur le serveur secondaire, la réplication est démarrée en exécutant la commande suivante, à l'aide des informations indiquées par la commande précédente ( MASTER_LOG_FILE et de MASTER_LOG_POS) :

    CHANGE MASTER TO 
      MASTER_HOST='adresse_ip_du_serveur_principal', 
      MASTER_USER='replication', 
      MASTER_PASSWORD='password', 
      MASTER_LOG_FILE='fichier-log-principal', 
      MASTER_LOG_POS=pos-log-principal;
    START SLAVE;
    • MASTER_LOG_FILE spécifie le nom du fichier de log binaire sur le serveur principal à partir duquel le secondaire doit commencer la réplication.
    • MASTER_LOG_POS indique la position dans le fichier de log binaire à partir de laquelle le secondaire doit commencer à lire.
    info

    Vous obtenez les valeurs de MASTER_LOG_FILE et MASTER_LOG_POS à partir du serveur principal, en exécutant la commande SHOW MASTER STATUS sur le principal.

Qu'est-ce que le failover ?

Le failover est essentiel pour garantir la continuité de service d'une application.

Failover avec la réplication MariaDB​

Le failover est un mécanisme crucial pour assurer la haute disponibilité dans une configuration de réplication MariaDB. Il permet de basculer automatiquement vers un serveur secondaire en cas de défaillance du serveur principal.

Principe de fonctionnement​

Dans une configuration principal-secondaire classique :

  • Le serveur principal gère les opérations d'écriture et de lecture
  • Les serveurs secondaires répliquent les données du principal et peuvent gérer des lectures

En cas de panne du principal, le failover consiste à :

  1. Détecter la panne du principal
  2. Promouvoir un secondaire en nouveau principal
  3. Rediriger les connexions clients vers le nouveau principal
  4. Reconfigurer les autres secondaires pour répliquer depuis le nouveau principal

Types de failover​

  • Manuel : Un administrateur déclenche manuellement le basculement
  • Semi-automatique : Des outils détectent la panne et assistent l'administrateur
  • Automatique : Le basculement est entièrement géré par un système tiers

Configurations courantes​

  • Principal-secondaire : Un principal et un ou plusieurs secondaires
  • Multi-principaux : Plusieurs nœuds peuvent être principaux
  • Hybride : Combinaison de nœuds principaux et secondaires

Exemple pratique​

Supposons que nous ayons deux serveurs MariaDB, un serveur principal avec l'adresse IP 192.168.1.10 et un serveur secondaire avec l'adresse IP 192.168.1.20.

1. Sur le serveur principal​

Sur le serveur principal, modifiez le fichier de configuration de MariaDB :

sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf

Ajoutez/modifiez les lignes suivantes et sauvegardez le fichier :

log_bin = /var/log/mysql/mariadb-bin
log_bin_index = /var/log/mysql/mariadb-bin.index
server-id = 1

Redémarrez le service MariaDB :

sudo service mariadb restart

Connectez-vous à MariaDB en tant qu'utilisateur root et créez un utilisateur de réplication :

sudo mysql
CREATE USER 'replication'@'192.168.1.10' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'replication'@'192.168.1.10';

Exécutez la commande suivante, pour récupérer les valeurs de MASTER_LOG_FILE et de MASTER_LOG_POS :

SHOW MASTER STATUS
astuce

Notez les valeurs de MASTER_LOG_FILE et de MASTER_LOG_POS, vous en aurez besoin pour configuer le serveur secondaire.

2. Sur le serveur secondaire​

Sur le serveur secondaire, modifiez le fichier de configuration de MariaDB :

sudo nano /etc/mysql/mariadb.conf.d/50-server.cnf

Ajoutez/Modifiez les lignes suivantes et sauvegardez le fichier :

relay_log = /var/log/mysql/mariadb-relay-bin
relay_log_index = /var/log/mysql/mariadb-relay-bin.index
server-id = 2

Redémarrez le service MariaDB :

sudo service mariadb restart

Connectez-vous à MariaDB en tant qu'utilisateur root et démarrez la réplication :

CHANGE MASTER TO 
  MASTER_HOST='192.168.1.10', 
  MASTER_USER='replication', 
  MASTER_PASSWORD='password', 
  MASTER_LOG_FILE='mysql-bin.000001', 
  MASTER_LOG_POS=120;

  1. MASTER_LOG_FILE spécifie le nom du fichier de log binaire sur le serveur principal à partir duquel le secondaire doit commencer la réplication.

    Dans cet exemple, c'est 'mysql-bin.000001'.

  2. MASTER_LOG_POS indique la position dans le fichier de log binaire à partir de laquelle le secondaire doit commencer à lire.

    Dans cet exemple, c'est 120.

START SLAVE;

Créer une copie cohérente des données​

Afin de créer une copie cohérente des données du serveur primaire et obtenir un point de départ précis pour la réplication, tout en minimisant la durée pendant laquelle le serveur primaire est verrouillé en lecture seule, il est conseillé d'utiliser les commandes FLUSH TABLES WITH READ LOCK et UNLOCK TABLES.

FLUSH TABLES WITH READ LOCK​

Cette commande effectue deux actions importantes :

  1. Elle vide tous les tables en mémoire sur le disque, assurant que toutes les modifications en attente sont écrites.

  2. Elle place un verrou en lecture global sur toutes les tables, empêchant toute écriture ultérieure.

L'utilisation de cette commande est essentielle pour obtenir un point de cohérence lors de la création d'une sauvegarde ou de l'initialisation d'un réplica. Elle garantit que l'état des données reste figé pendant que vous effectuez les opérations nécessaires, comme l'obtention des coordonnées du journal binaire ou la copie des données.

UNLOCK TABLES​

Cette commande est utilisée pour libérer le verrou en lecture global placé par FLUSH TABLES WITH READ LOCK. Elle est généralement exécutée une fois que les opérations nécessitant un état cohérent des données sont terminées, comme la copie des données ou l'obtention des informations de position du journal binaire.

Utilisation dans le contexte de la réplication​

Dans un scénario de réplication, ces commandes sont généralement utilisées dans l'ordre suivant :

  1. Exécuter FLUSH TABLES WITH READ LOCK sur le serveur primaire.
  2. Obtenir la position actuelle du journal binaire avec SHOW MASTER STATUS.
  3. Effectuer une copie des données du serveur primaire vers le serveur réplica.
  4. Exécuter UNLOCK TABLES sur le serveur primaire pour libérer le verrou.

Cette séquence permet de créer une copie cohérente des données du serveur primaire et d'obtenir un point de départ précis pour la réplication, tout en minimisant la durée pendant laquelle le serveur primaire est verrouillé en lecture seule.

Test de mémorisation/compréhension​


Quelle est l'utilité du journal binaire sur le serveur principal ?


Quelle est l'utilité du journal de relais sur le serveur secondaire ?


Quelle commande permet de créer un utilisateur de réplication sur le serveur principal ?


Quelle commande permet de changer les paramètre du maitre puis de commencer la réplication ?


Quelle est la première action effectuée par la commande `FLUSH TABLES WITH READ LOCK` ?


Quel est l'objectif principal de la commande `FLUSH TABLES WITH READ LOCK` ?


Que se passe-t-il après l'exécution de `UNLOCK TABLES` ?


Pourquoi est-il important de minimiser la durée de verrouillage du serveur primaire ?


Quelle commande permet d'obtenir la position actuelle du journal binaire ?


Dans quel ordre les commandes doivent-elles être exécutées dans le contexte de la réplication ?


Quel type de verrou est placé par `FLUSH TABLES WITH READ LOCK` ?


Quel est le rôle principal de la commande `UNLOCK TABLES` dans le processus de réplication ?


Quel est l'effet d'un verrou en lecture sur le serveur primaire ?


Travail à faire​

Atelier sur la réplication​

et​

Rédiger une documentation technique​