Réplication MySQL avec SSL sur CentOS 5.4

Objectif principal

Fournir une procédure reproductible pour répliquer la base exampledb du serveur server1.example.com (192.168.0.100) vers server2.example.com (192.168.0.101) en utilisant une connexion SSL pour sécuriser le trafic MySQL.

Important: cette procédure n’est pas une stratégie de sauvegarde complète — une suppression accidentelle sur le master est répliquée sur le slave.

Variantes de recherche liées

• réplication MySQL SSL
• MySQL replication CentOS 5.4
• MySQL master slave SSL
• activer SSL MySQL CentOS
• configurer réplication MySQL sécurisée

1 Note préalable

Je réalise toutes les commandes en tant que root. Adaptez les commandes si vous travaillez avec un utilisateur disposant de privilèges sudo.

Contexte de l’exemple:

• Master: server1.example.com — 192.168.0.100
• Slave: server2.example.com — 192.168.0.101
• Base à répliquer: exampledb
• Distribution: CentOS 5.4 (mais la configuration s’applique à d’autres distributions avec peu de modifications)

Si la base exampledb existe sur le master et pas sur le slave, cette procédure importe le dump initial sur le slave.

Notes rapides:

• Vérifiez la connectivité réseau entre master et slave (ports TCP 3306, SSH si vous utilisez scp).
• Assurez-vous que l’horloge système est correcte sur les deux serveurs.

2 Installer MySQL 5 et activer le support SSL

Si MySQL 5 n’est pas installé sur server1 et server2, installez-le :

server1/server2:

yum install mysql mysql-devel mysql-server

Créer les liens de démarrage système et démarrer MySQL :

chkconfig --levels 235 mysqld on
/etc/init.d/mysqld start

Définir le mot de passe root MySQL sur chaque serveur (exemple) :

server1:

mysqladmin -u root password yourrootsqlpassword
mysqladmin -h server1.example.com -u root password yourrootsqlpassword

server2:

mysqladmin -u root password yourrootsqlpassword
mysqladmin -h server2.example.com -u root password yourrootsqlpassword

Vérifier le support SSL dans MySQL :

mysql -u root -p

Puis dans le shell MySQL :

show variables like '%ssl%';

Si la sortie montre have_openssl et have_ssl à DISABLED, MySQL a été compilé avec SSL mais n’est pas actif.

Pour activer SSL, quittez le shell MySQL :

quit;

Éditez /etc/my.cnf et ajoutez la ligne ssl dans la section [mysqld] :

vi /etc/my.cnf

Ajoutez (ou modifiez) :

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1
ssl

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

Redémarrez MySQL :

/etc/init.d/mysqld restart

Reconnectez-vous au shell MySQL et exécutez :

show variables like '%ssl%';

La sortie doit indiquer have_openssl et have_ssl à YES.

quit;

3 Configuration du master

Préparer le répertoire de binlogs

server1 :

mkdir /var/log/mysql
chown mysql:mysql /var/log/mysql

Générer CA, certificat serveur et certificat client

Créez un dossier pour les certificats et placez-vous dedans :

mkdir -p /etc/mysql/newcerts && cd /etc/mysql/newcerts

Générer la clé CA et le certificat CA :

openssl genrsa 2048 > ca-key.pem
openssl req -new -x509 -nodes -days 1000 -key ca-key.pem > ca-cert.pem

Générer la clé et la requête du certificat serveur, puis signer :

openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem > server-req.pem
openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > server-cert.pem

Générer la clé et la requête du certificat client, puis signer :

openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem > client-req.pem
openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem

Vérifier les fichiers :

ls -l

Exemple de sortie :

[root@server1 newcerts]# ls -l
total 32
-rw-r--r-- 1 root root 1375 Feb  8 17:37 ca-cert.pem
-rw-r--r-- 1 root root 1679 Feb  8 17:37 ca-key.pem
-rw-r--r-- 1 root root 1119 Feb  8 17:37 client-cert.pem
-rw-r--r-- 1 root root 1675 Feb  8 17:37 client-key.pem
-rw-r--r-- 1 root root  968 Feb  8 17:37 client-req.pem
-rw-r--r-- 1 root root 1119 Feb  8 17:37 server-cert.pem
-rw-r--r-- 1 root root 1679 Feb  8 17:37 server-key.pem
-rw-r--r-- 1 root root  968 Feb  8 17:37 server-req.pem
[root@server1 newcerts]#

Déployer les certificats vers le slave

Créez le dossier sur le slave :

server2 :

mkdir -p /etc/mysql/newcerts

Transférez les fichiers nécessaires du master vers le slave :

server1 :

scp /etc/mysql/newcerts/ca-cert.pem [email protected]:/etc/mysql/newcerts
scp /etc/mysql/newcerts/client-cert.pem [email protected]:/etc/mysql/newcerts
scp /etc/mysql/newcerts/client-key.pem [email protected]:/etc/mysql/newcerts

Note: conservez ca-cert.pem sur le master également. Ne transférez pas la clé CA (ca-key.pem) au slave. La clé CA doit rester secrète et stockée en lieu sûr sur le master (ou gestionnaire de clés).

Configurer MySQL pour utiliser les certificats

Éditez /etc/my.cnf sur le master et ajoutez les chemins vers les certificats :

vi /etc/my.cnf

Ajoutez :

ssl
ssl-ca=/etc/mysql/newcerts/ca-cert.pem
ssl-cert=/etc/mysql/newcerts/server-cert.pem
ssl-key=/etc/mysql/newcerts/server-key.pem

Exemple complet (avec options de réplication à ajouter plus bas) :

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
old_passwords=1
ssl
ssl-ca=/etc/mysql/newcerts/ca-cert.pem
ssl-cert=/etc/mysql/newcerts/server-cert.pem
ssl-key=/etc/mysql/newcerts/server-key.pem

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

Redémarrez MySQL :

/etc/init.d/mysqld restart

Créer l’utilisateur de réplication sécurisé

Connectez-vous au shell MySQL :

mysql -u root -p

Créez l’utilisateur utilisateur de réplication et autorisez uniquement les connexions SSL (optionnel mais recommandé) :

GRANT REPLICATION SLAVE ON *.* TO 'slave_user'@'%' IDENTIFIED BY 'slave_password' REQUIRE SSL;

Explication: REQUIRE SSL force l’utilisation d’une connexion chiffrée. Si vous omettez REQUIRE SSL, l’utilisateur pourra se connecter via des connexions non chiffrées.

Si l’utilisateur existe déjà et que vous souhaitez passer en mode SSL uniquement :

GRANT USAGE ON *.* TO 'slave_user'@'%' REQUIRE SSL;

Puis :

FLUSH PRIVILEGES;
quit;

Configurer MySQL en tant que master et définir la base à répliquer

Éditez /etc/my.cnf et ajoutez les paramètres de réplication dans la section [mysqld] :

server-id               = 1
log_bin                 = /var/log/mysql/mysql-bin.log
expire_logs_days        = 10
max_binlog_size         = 100M
binlog_do_db            = exampledb

Exemple complet :

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
old_passwords=1
ssl
ssl-ca=/etc/mysql/newcerts/ca-cert.pem
ssl-cert=/etc/mysql/newcerts/server-cert.pem
ssl-key=/etc/mysql/newcerts/server-key.pem
server-id               = 1
log_bin                 = /var/log/mysql/mysql-bin.log
expire_logs_days        = 10
max_binlog_size         = 100M
binlog_do_db            = exampledb

[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

Redémarrer MySQL :

/etc/init.d/mysqld restart

Préparer le dump initial et capturer la position du binlog

Verrouillez la base et demandez l’état du master pour connaître le fichier et la position du binlog avant de dumper :

mysql -u root -p

Dans le shell MySQL :

USE exampledb;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

La sortie sera similaire à :

mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 |  3096416 | exampledb    |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

mysql>

Notez le nom de fichier et la position. Ne quittez pas ce shell tant que vous n’avez pas pris le dump et transféré le fichier, car le verrou est actif.

Ouvrez une seconde session shell et créez le dump, puis transférez-le sur le slave :

server1 (seconde session) :

cd /tmp
mysqldump -u root -pyourrootsqlpassword --opt exampledb > snapshot.sql
scp snapshot.sql [email protected]:/tmp

Après le transfert, revenez à la session MySQL d’origine et déverrouillez :

server1 :

UNLOCK TABLES;
quit;

4 Configuration du slave (server2)

Sur server2, assurez-vous que MySQL est installé et que SSL est activé (mêmes étapes que sur le master pour activer ssl dans /etc/my.cnf si nécessaire). Copiez les certificats client et CA comme indiqué plus haut.

Importer le dump :

server2 :

cd /tmp
mysql -u root -pyourrootsqlpassword < snapshot.sql

Configurer le slave pour pointer vers le master (utilisez la position relevée précédemment) :

mysql -u root -p

Dans le shell MySQL du slave :

CHANGE MASTER TO
  MASTER_HOST='192.168.0.100',
  MASTER_USER='slave_user',
  MASTER_PASSWORD='slave_password',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=3096416,
  MASTER_SSL=1,
  MASTER_SSL_CA='/etc/mysql/newcerts/ca-cert.pem',
  MASTER_SSL_CERT='/etc/mysql/newcerts/client-cert.pem',
  MASTER_SSL_KEY='/etc/mysql/newcerts/client-key.pem';

START SLAVE;

Explications des options SSL du CHANGE MASTER TO :

• MASTER_SSL=1 active l’utilisation de SSL.
• MASTER_SSL_CA, MASTER_SSL_CERT, MASTER_SSL_KEY pointent vers les fichiers que nous avons transférés.

Vérifiez l’état du slave :

SHOW SLAVE STATUS\G

Vérifiez surtout :

• Slave_IO_Running: Yes
• Slave_SQL_Running: Yes
• Last_IO_Error: (vide)
• Last_SQL_Error: (vide)

Si les deux sont à Yes, la réplication fonctionne.

5 Vérifications et dépannage rapides

Checklist de validation :

• Le slave se connecte au master via SSL (vérifiez les logs MySQL si doute).
• Les binlogs du master avancent quand vous effectuez des écritures sur exampledb.
• SHOW SLAVE STATUS\G ne retourne pas d’erreurs.

Dépannage courant :

• Erreur d’accès: vérifiez les permissions GRANT du slave_user et l’adresse source.
• Erreur SSL: vérifiez que les chemins de certificats sont corrects et que les fichiers ont des permissions adéquates (600 pour clés privées).
• Positions incorrectes: si les positions ne correspondent pas, regénérez un dump à partir d’un état verrouillé et recommencez.

Bonnes pratiques de sécurité

• Ne transférez jamais la clé CA (ca-key.pem) au slave. Conservez-la hors ligne et en accès restreint.
• Restreignez la connexion SSH et utilisez des clés SSH pour scp.
• Restreignez l’accès MySQL de l’utilisateur slave_user à l’adresse IP du slave si possible (‘slave_user’@’192.168.0.101’).
• Utilisez des mots de passe forts et changez-les selon la politique de sécurité.
• Stockez les certificats et clés sous un répertoire avec permissions strictes (chmod 600 pour clés privées, 644 pour certificats publics).

Modèles de décision (diagramme)

Si vous hésitez entre réplication simple et options plus avancées, ce diagramme aide à choisir :

flowchart TD A[Démarrage: besoin de réplication ?] –> B{Récupération après panne ?} B – Oui –> C[Répliquer + sauvegardes régulières] B – Non –> D[Répliquer pour répartition lecture] C –> E{Données sensibles ?} D –> E E – Oui –> F[Activer SSL + RBAC + monitoring] E – Non –> G[SSL recommandé mais optionnel] F –> H[Mettre en place monitoring et alertes] G –> H

Note: le bloc mermaid ci-dessus est un diagramme d’aide à la décision. Adaptez selon vos contraintes opérationnelles.

Rôles et responsabilités — checklists rapides

Administrateur base (DBA):

• Installer MySQL et vérifier ssl.
• Générer et signer certificats.
• Configurer /etc/my.cnf sur master et slave.
• Créer l’utilisateur de réplication avec REQUIRE SSL.
• Valider SHOW SLAVE STATUS.

Opérateur système:

• Vérifier connectivité réseau et pare-feu.
• Assurer la rotation des binlogs et l’espace disque.
• Sauvegarder ca-key.pem dans coffre-fort de clés.

Opérateur sécurité:

• Valider permissions des fichiers de clés.
• Auditer logs de connexion MySQL.
• Valider conformité (ex: conserver preuve de chiffrement actif si requis).

Quand cette méthode échoue / alternatives

Cas où la procédure risque d’échouer :

• Versions de MySQL compilées sans support SSL complet.
• Restrictions réseau bloquant port 3306 ou SSH.
• Incompatibilités entre formats anciens de mot de passe et clients modernes.

Alternatives :

• Utiliser SSH tunnel (moins performant, plus simple si SSL MySQL impossible).
• Utiliser VPN entre datacenters pour chiffrer tout le trafic.
• Migrer vers une version de MySQL plus récente (recommandé pour sécurité et fonctionnalités).

Fiche méthode résumée (mini-méthodologie)

1. Installer MySQL sur master et slave.
2. Activer ssl dans /etc/my.cnf et redémarrer.
3. Générer CA et certificats serveur/client sur le master.
4. Copier ca-cert.pem + client-cert/key.pem sur le slave.
5. Configurer ssl-ca/ssl-cert/ssl-key dans /etc/my.cnf du master.
6. Créer utilisateur de réplication avec REQUIRE SSL.
7. Configurer binlog et server-id sur le master.
8. Verrouiller la DB, noter SHOW MASTER STATUS, dumper la DB et transférer.
9. Importer le dump sur le slave.
10. CHANGE MASTER TO … MASTER_SSL=1 et démarrer le slave.
11. Vérifier SHOW SLAVE STATUS\G.

Critères de réussite

• Le slave affiche Slave_IO_Running: Yes et Slave_SQL_Running: Yes.
• Les erreurs Last_IO_Error et Last_SQL_Error sont vides.
• Le trafic MySQL entre master et slave est chiffré (vérifiable via les paramètres MASTERSSL* et logs MySQL).

Glossaire (une ligne)

• binlog: journal binaire des changements sur le master utilisé par les slaves pour se synchroniser.
• CA: autorité de certification qui signe les certificats.
• MASTER_SSL: option de CHANGE MASTER TO qui active SSL pour la réplication.

Résumé

Ce guide détaille la configuration d’une réplication MySQL chiffrée par SSL entre deux serveurs CentOS 5.4. Vous avez appris à activer SSL dans MySQL, générer et déployer les certificats, créer un compte de réplication en mode SSL, produire un dump initial verrouillé et configurer le slave pour se connecter au master via SSL.

Points clés:

• Protégez toujours la clé CA (ca-key.pem).
• REQUIRE SSL pour forcer les connexions chiffrées.
• Testez régulièrement SHOW SLAVE STATUS\G et la rotation des binlogs.

Notes importantes:

• N’utilisez pas la réplication comme seule sauvegarde.
• Adaptez les chemins et mots de passe à vos politiques internes.

Fin.