Comment configurer une réplication maître-esclave MariaDB

La réplication dans MariaDB consiste à copier les données d’une base de données vers une autre, voire plusieurs, afin de synchroniser l’ensemble des données – du moins, cela devrait être le cas. Si vous vous êtes déjà demandé pourquoi vos données n’apparaissent pas sur vos serveurs ou pourquoi vos sauvegardes ne sont pas opérationnelles, ce guide est là pour vous aider. Configurer la réplication n’est pas toujours simple, surtout sur CentOS 7, mais bien réalisée, elle peut vous simplifier considérablement la vie en vous offrant des options d’équilibrage de charge et de basculement sans trop de difficultés. Une fois configurée, vous pourrez créer ou mettre à jour des données sur un serveur principal et les propager automatiquement vers les sauvegardes ou d’autres serveurs maîtres. Assurez-vous simplement de bien maîtriser les fondamentaux pour éviter les pièges classiques tels que les problèmes de pare-feu ou les configurations incompatibles. Il faudra peut-être procéder par essais et erreurs, mais ce guide devrait constituer un bon point de départ pour quiconque souhaite mettre en place une infrastructure MariaDB résiliente.

Comment résoudre les problèmes de réplication MariaDB sur CentOS 7

Configurer la réplication maître-maître — Pourquoi pas presque toujours ?

Dans certaines configurations, ce type de synchronisation bidirectionnelle flottante peut se complexifier, mais il est extrêmement utile pour la haute disponibilité. Concrètement, les deux serveurs peuvent gérer les lectures et les écritures, servant de sauvegarde l’un pour l’autre. L’essentiel est de configurer correctement le journal binaire et de s’assurer que chaque serveur possède un identifiant unique. Sans cela, MariaDB se retrouve rapidement perturbé ; croyez-moi. Voici la marche à suivre.

Méthode 1 : Préparer les deux serveurs maîtres

Ouvrez le fichier /etc/my.cnf sur chaque serveur et ajoutez ce bloc (un pour Master-1, puis un server_id différent pour Master-2) :

#replication server_id = 1 report_host = master log_bin = /var/lib/mysql/mariadb-bin log_bin_index = /var/lib/mysql/mariadb-bin.index relay_log = /var/lib/mysql/relay-bin relay_log_index = /var/lib/mysql/relay-bin.index

Veillez à faire de même pour le deuxième serveur, mais remplacez server_id par 2 et ajustez report_host en conséquence, probablement par son adresse IP ou son nom d’hôte.

Redémarrez MariaDB après modification :

service mariadb restart

Parfois, un redémarrage suffit, mais un redémarrage complet est généralement la solution. Ensuite, créez un utilisateur dédié à la réplication :

mysql -e "CREATE USER 'repl_user'@'%' IDENTIFIED BY 'somepassword';" mysql -e "GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';"

Consultez les informations du journal binaire actuel de chaque maître pour obtenir le nom et la position du fichier journal binaire :

SHOW MASTER STATUS\G

Quelque chose comme :

File: mariadb-bin.000002 Position: 664

Si votre serveur principal n’affiche pas ces informations, il se peut que ces journaux ne soient pas activés ; vérifiez donc votre configuration.

Méthode 2 : Connexion des maîtres à l’aide des informations Binlog

Connectez-vous maintenant au deuxième serveur et configurez la réplication pour qu’elle pointe vers le premier, en utilisant les informations de SHOW MASTER STATUS.
Sur le deuxième serveur, exécutez :

STOP SLAVE; CHANGE MASTER TO MASTER_HOST='IP_of_Master1', MASTER_USER='repl_user', MASTER_PASSWORD='somepassword', MASTER_LOG_FILE='mariadb-bin.000002', MASTER_LOG_POS=664; START SLAVE;

Cela établit le lien de réplication. Répétez la même procédure sur le premier serveur, mais en remplaçant les informations du serveur maître par celles du second serveur.

Comment vérifier si la réplication fonctionne ?

Une fois que les deux serveurs ont confirmé la connexion, il est temps de tester. Créez une nouvelle base de données ou table sur Master-1 :

CREATE DATABASE test_replication; USE test_replication; CREATE TABLE test_table (id INT PRIMARY KEY, name VARCHAR(50));

Vérifiez ensuite si le processus apparaît automatiquement sur Master-2. Ne soyez pas surpris s’il ne s’affiche pas immédiatement : un délai de réplication peut parfois survenir, surtout en cas d’écritures intensives. Si, après un certain temps, il n’est toujours pas là, consultez vos journaux SHOW SLAVE STATUS\Get recherchez des erreurs telles que « Arrêté » ou d’autres problèmes. Généralement, le blocage provient du pare-feu : le port par défaut de MariaDB (3306) doit être ouvert sur chaque nœud pour un fonctionnement optimal.

Comment configurer un système maître-esclave classique

Ce mode correspond à ce que la plupart des utilisateurs recherchent lorsqu’ils parlent de « sauvegarde de base de données » et de « répartition de la charge de lecture ».Vous choisissez un serveur principal pour l’écriture et un ou plusieurs serveurs secondaires pour les copies en lecture seule. La configuration du serveur secondaire est similaire : indiquez le même ID de serveur, activez les journaux binaires et spécifiez l’emplacement du serveur principal. N’oubliez pas de configurer read_only=ONle serveur secondaire pour éviter les écritures accidentelles. Il est fortement recommandé d’effectuer une sauvegarde initiale de votre base de données afin d’éviter toute modification du fichier my.cnf lors d’une mise à niveau ou d’une synchronisation initiale.

En gros, vous faites ceci :

Modifiez le fichier /etc/my.cnf sur l’esclave : assurez-vous que server_id est unique et définissez log_bin.
Redémarrez MariaDB, puis exécutez :

STOP SLAVE; CHANGE MASTER TO MASTER_HOST='IP_of_Master', MASTER_USER='repl_user', MASTER_PASSWORD='somepassword', MASTER_LOG_FILE='mariadb-bin.000001', MASTER_LOG_POS=664; START SLAVE;

Surveillez les erreurs SHOW SLAVE STATUS\G. Si Slave_IO_Running et Slave_SQL_Running valent tous deux « Oui », tout est en ordre.

Certains pièges, comme le blocage du port 3306 par firewalld sur CentOS, sont fréquents. Vous devrez ouvrir ce port pour établir une connexion externe ; pensez aux règles iptables :

iptables -I INPUT -p tcp -s slave_ip --dport 3306 -j ACCEPT

Si vous utilisez firewalld, pensez à configurer des règles firewalld, ou au moins à le désactiver temporairement lors de la configuration (déconseillé à long terme !).

Je vérifie si tout fonctionne correctement.

Effectuez une modification sur votre serveur maître (par exemple, créez une base de données, ajoutez des tables, insérez des données), puis vérifiez le serveur esclave. Si les données apparaissent, c’est parfait. Sinon, la SHOW SLAVE STATUS\Gsortie vous indiquera la cause du problème : erreurs, déconnexion ou latence. Il est parfois nécessaire de redémarrer le serveur esclave ou de corriger les permissions, surtout si le champ Last_Error est renseigné. Sur certaines machines, cette configuration échoue la première fois, puis fonctionne comme par magie après un redémarrage ou la correction des règles du pare-feu. C’est assez étrange, mais c’est le propre de CentOS.

Résumé

Configurez correctement le fichier my.cnf avec des identifiants de serveur uniques et des chemins d’accès aux journaux binaires.
Créez un utilisateur de réplication dédié disposant des autorisations appropriées.
Récupérez les informations binlog actuelles auprès des serveurs maîtres.
Configurez soigneusement les commandes CHANGE MASTER TO en les faisant pointer vers les adresses IP et les journaux appropriés.
Vérifiez régulièrement l’état des esclaves et corrigez les erreurs dès qu’elles apparaissent.
Ouvrez le port 3306 dans votre pare-feu si les connexions externes ne fonctionnent pas.

Conclure

La réplication MariaDB sur CentOS 7 peut parfois s’avérer délicate, notamment à cause des pare-feu et des fichiers de configuration. Cependant, si les éléments essentiels sont correctement configurés (identifiants de serveur, journaux binaires, permissions utilisateur), elle est très fiable. Il arrive que la configuration ne fonctionne pas du premier coup, surtout avec des règles de pare-feu ou des configurations incompatibles, mais une fois opérationnelle, elle offre de nombreux avantages. Il faut s’attendre à quelques tâtonnements ; mais avec de la patience, vous obtiendrez une configuration qui non seulement se sauvegarde automatiquement, mais qui répartit également la charge et garantit une haute disponibilité.