1. Architecture maitre-esclave ==============================

1.1 Réplication via GTID

La réplication basée sur les Global Transaction Identifiers (GTID) offre une gestion simplifiée et une haute disponibilité pour les bases de données MariaDB.

A. Configuration dans my.cnf

</div>### B. Création du compte de réplication sur le maitre

Exécution de la commande SQL suivante sur le serveur maitre :

grant replication slave, replication client on . to 'replic_user'@'192.168.1.20' identified by 'SecurePass123!'; flush privileges;

### C. Configuration de l'esclave

Commandes à exécuter sur le serveur esclave :

stop slave; reset slave; change master to master_host='192.168.1.10', master_port=3306, master_user='replic_user', master_password='SecurePass123!', master_use_gtid=slave_pos; start slave;

### D. Vérification du bon fonctionnement

Vérifier que les deux indicateurs suivants sont à YES :

- Slave\_IO\_Running
- Slave\_SQL\_Running

### E. Commandes utiles

-- Liste des utilisateurs select * from mysql.user;

-- Rechargement des privilèges flush privileges;

-- Suppression d'un utilisateur delete from mysql.user where User='replic_user';

-- Statut du maitre show master status;

-- Statut de l'esclave show slave status;

-- Variables GTID show global variables like 'gtid%';

1.2 Paramètre master\_use\_gtid
-------------------------------

Ce paramètre définit le comportement de la réplication GTID :

- **slave\_pos** : L'esclave enregistre la position du dernier GTID reçu du maitre. La variable gtid\_slave\_pos permet de visualiser ce dernier GTID.
- **current\_pos** : Utile lors d'un basculement. Si le maitre A tombe en panne et que B devient maitre, puis qu'après réparation A rejoind le cluster en tant qu'esclave, les GTID précédents n'existent pas (gtid\_slave\_pos vide). Ce mode permet une reconstitution automatique. Il est recommandé d'activer gtid\_strict\_mode=ON pour éviter les écritures concurrentes.
- **no** : Désactive la réplication GTID.

1.3 Paramètres de CHANGE MASTER
-------------------------------

change master to master_host='127.0.0.1', master_port=3306, master_user='replic_user', master_password='SecurePass123!', master_use_gtid=slave_pos;

**Note** : Utiliser slave\_pos lors de la première configuration. Utiliser current\_pos si le serveur était précédemment maitre.

| Paramètre | Description |
|---|---|
| master\_host | Adresse IP du serveur maitre |
| master\_port | Port de l'instance MariaDB maitre |
| master\_user | Compte utilisateur pour la connexion |
| master\_password | Mot de passe du compte |
| master\_use\_gtid | Mode de réplication GTID |
| master\_connect\_retry | Délai de reconnexion (défaut: 60s) |
| master\_retry\_count | Nombre max de tentatives (défaut: 86400) |
| master\_delay | Délai de réplication intentionnel |

1.4 Points importants
---------------------

### A. Auto-incrément

show session variables like '%auto_inc%';

### B. Configuration pour éviter les conflits

auto_increment_increment = 2 auto_increment_offset = 1

Sur le second serveur, utiliser offset = 2.

### C. Gestion des erreurs de réplication

slave_skip_errors = 1062,1032

- 1062 : Entrée en double (clé dupliquée)
- 1032 : Enregistrement introuvable

2. Surveillence du décalage de réplication
==========================================

2.1 Vérification manuelle
-------------------------

show slave status;

Le champ **Seconds\_Behind\_Master** indique le décalage en secondes.

2.2 Threads parallèles
----------------------

Le paramètre **slave-parallel-threads** définit le nombre de threads pour la réplication. Les opérations de lecture et de relecture sont traitées en parallèle.

2.3 Script de surveillance
--------------------------

#!/bin/bash while true do LAG_RESULT=docker exec mariadb mysql -h127.0.0.1 -uroot -pSecurePass123! -e "show slave status\G;" | grep 'Seconds_Behind_Master' echo -e "date +%Y-%m-%d\ %H:%M:%S ${LAG_RESULT}" sleep 3 done

3. Architecture maitre-maitre
=============================

La configuration maitre-maitre permet une réplication bidirectionnelle entre deux serveurs. Chaque serveur agit simultanément comme maitre et esclave.

Les étapes de configuration sont similaires à l'architecture maitre-esclave, en appliquant la procédure sur les deux serveurs avec les adresses IP appropriées.