Ce tutoriel aborde la réplication des données d’un VPS ou serveur dédié : les bases de données seront répliquées d’un serveur principal (master) sur un autre serveur auxiliaire (backup).
En cas de défaillance du serveur principal, le serveur auxiliaire prendra le relais automatiquement.
Ce guide considère que vous avez :
- deux VPS ou Droplets chez Digital Ocean dans le même datacenter;
- une IP flottante qui peut être assignée à l’un ou l’autre des serveurs, à la demande;
- le même système d’exploitation sur les deux serveurs, pour des raisons de compatibilité.
Créer une image du VPS principal pour le VPS de sauvegarde
Commençons par la base du système : le système d’exploitation (OS). Lorsque j’ai pris le projet en main, le site était déjà en production et tournait sur la dernière version d’Ubuntu Server, avec NginX, MariaDB et SSL activé.
On aurait pu tout réinstaller sur le nouveau VPS mais autant gagner du temps : Digital Ocean permet de faire une image du VPS existant et de l’installer sur un nouveau droplet. C’est quelques heures d’installation et de configuration d’économisées.
Voici les données de mes deux VPS :
MASTER
ipv4: 104.xxx.xxx.133
Private IP: 10.134.23.164Code language: CSS (css)BACKUP
ipv4: 104.xxx.xxx.186
Private IP: 10.134.4.220Code language: CSS (css)Floating IP
Floating IP: 138.xxx.xxx.177Code language: CSS (css)Je masque les IP publiques puisque mes serveurs sont en production mais ces IP serviront pour le tuto : l’IP qui se termine en .133 est le Master, l’IP qui se termine en .186 est le Backup, et l’IP qui se termine en .177 est l’IP flottante.
Réplication de la base de données
Les deux serveurs LEMP sont maintenant identiques, même les fichiers et bases de données. Mais nous avons besoin d’avoir une base de données synchronisée en temps réel, dans les deux sens, master-master.
Si un serveur tombe, l’autre prend le relais. Lorsque le serveur Master revient à lui, le serveur Backup lui redonne les données SQL manquantes.
1. Configuration du serveur MASTER
On édite la configuration MariaDB:
nano /etc/mysql/my.cnfOn édite et remplace/ajoute :
# MATT - skyminds.net : MariaDB replication instructions.
# https://www.skyminds.net/?p=28739
# 1. bind-adress : replace 127.0.0.1 with Internal IP.
# bind-address = 127.0.0.1
bind-address = 10.134.23.164
# 2. enable log_bin
log_bin = /var/log/mysql/mariadb-bin
log_bin_index = /var/log/mysql/mariadb-bin.index
# 3. add server-id AND binlog_do_db
# NOTE : server-id is a way to identify this server in MariaDB configs.
# NOTE : binlog_do_db contains the names of the databases to replicate
server-id = 1
binlog_format=mixed
# first DB
binlog_do_db = first_wpdb
# second DB
binlog_do_db = second_wp
# /MATTCode language: PHP (php)Nous allons maintenant lancer quelques commandes sur le serveur SQL:
mysql -u root -pOn crée un utilisateur, replicator, qui utilise le mot de passe replicateME! et on lui donne les droits de réplication :
create user 'replicator'@'%' identified by 'replicateME!';
grant replication slave on *.* to 'replicator'@'%';
FLUSH PRIVILEGES;Code language: JavaScript (javascript)On regarde maintenant l’état de notre serveur:
show master status;Résultat:
+--------------------+----------+---------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+--------------------+----------+---------------+------------------+
| mariadb-bin.000232 | 839505 | first_wpdb,second_wp | |
+--------------------+----------+---------------+------------------+
1 row in set (0.00 sec)Code language: JavaScript (javascript)Il vous faut absolument noter le nom du fichier binaire et son numéro de position.
2. Configuration du serveur BACKUP
On édite la configuration MariaDB:
nano /etc/mysql/my.cnfOn édite et remplace/ajoute :
# MATT - skyminds.net : MariaDB replication instructions.
# https://www.skyminds.net/?p=28739
# 1. bind-adress : replace 127.0.0.1 with Internal IP.
# bind-address = 127.0.0.1
bind-address = 10.134.4.220 # droplet internal IP
# 2. enable log_bin
log_bin = /var/log/mysql/mariadb-bin
log_bin_index = /var/log/mysql/mariadb-bin.index
# 3. add server-id AND binlog_do_db
# NOTE : server-id is a way to identify this server in MariaDB configs.
# NOTE : binlog_do_db contains the names of the databases to replicate
server-id = 2
binlog_format=mixed
# first DB
binlog_do_db = first_wpdb
# second DB
binlog_do_db = second_wp
# /MATTCode language: PHP (php)Nous allons maintenant lancer quelques commandes sur le serveur SQL:
mysql -u root -pOn crée un utilisateur, replicator, qui utilise le mot de passe replicateME! et on lui donne les droits de réplication :
create user 'replicator'@'%' identified by 'replicateME!';
grant replication slave on *.* to 'replicator'@'%';
FLUSH PRIVILEGES;Code language: JavaScript (javascript)Vérification de la synchronisation
A ce stade, vous pouvez tester pour voir si BACKUP reçoit bien les données de MASTER:
SHOW SLAVE STATUS\G;Résultat :
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 10.134.23.164
Master_User: replicator
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mariadb-bin.000105
Read_Master_Log_Pos: 1693167
Relay_Log_File: mysqld-relay-bin.000006
Relay_Log_Pos: 738965
Relay_Master_Log_File: mariadb-bin.000105
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 1693167
Relay_Log_Space: 1694046
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 1
Master_SSL_Crl:
Master_SSL_Crlpath:
Using_Gtid: No
Gtid_IO_Pos:
Replicate_Do_Domain_Ids:
Replicate_Ignore_Domain_Ids:
Parallel_Mode: conservative
1 row in set (0.00 sec)Code language: CSS (css)Les deux lignes critiques à vérifier sont :
Slave_IO_Running: Yes
Slave_SQL_Running: YesCode language: HTTP (http)Si ces deux variables sont à Yes, les données sont bien répliquées sur le serveur BACKUP.
A ce stade, la réplication des bases de données ne se fait que dans un sens : de MASTER vers BACKUP. Voyons maintenant comment on peut l’activer dans les deux sens.
La réplication dans les deux sens : Master-Master
Sur le serveur BACKUP, on vérifie l’état du serveur:
show master status;Notez le nom du fichier binaire et son numéro de position. Le serveur BACKUP a l’IP 10.134.4.220. Ici :
MASTER_LOG_FILE = 'mariadb-bin.000103',
MASTER_LOG_POS = 36986964Code language: JavaScript (javascript)Rendez-vous sur le serveur MASTER.
Nous allons stopper le slave, définir notre BACKUP VPS comme MASTER et relancer le slave :
stop slave;
CHANGE MASTER TO MASTER_HOST = '10.134.4.220', MASTER_USER = 'replicator', MASTER_PASSWORD = 'replicateME!', MASTER_LOG_FILE = 'mariadb-bin.000103', MASTER_LOG_POS = 36986964;
start slave;Code language: JavaScript (javascript)Et voilà, la réplication des données se fait dans les deux sens : MASTER-BACKUP et BACKUP-MASTER. J’ai mis ce système en place il y a quelques mois pour mes clients, ils en sont ravis.
Dans le prochain tutoriel, on aborde la réplication des fichiers.
Synopsis » Créer un serveur High Availability (HA)
- Créer un serveur High Availability : la réplication des bases de données
- Créer un serveur High Availability : la réplication des fichiers
- Serveur High Availability : créer un load balancer avec une IP flottante
Rencontrez-vous des défis avec votre site WordPress ou WooCommerce? Laissez-moi les résoudre pour vous.
