Créer un serveur High Availability : la réplication des bases de données

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.cnf

On é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 -p

On 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.cnf

On é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 -p

On 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)

  1. Créer un serveur High Availability : la réplication des bases de données
  2. Créer un serveur High Availability : la réplication des fichiers
  3. Serveur High Availability : créer un load balancer avec une IP flottante

Vous avez un projet WordPress ou WooCommerce en tête? Transformez votre vision en réalité avec mon expertise reconnue.

Parlons de votre projet dès aujourd'hui »

Articles conseillés :

Matt

Matt Biscay est développeur WordPress et WooCommerce certifié chez Codeable, ainsi que sysadmin qualifié et enseignant-chercheur. Passionné par le code performant et les solutions sécurisées, je m'efforce d'offrir une expérience utilisateur exceptionnelle sur chaque projet.

Vous avez aimé cet article ? Vous avez un projet en tête et vous pensez que je pourrais vous aider à le concrétiser ? N'hésitez pas à me contacter, je serais ravi de discuter avec vous de votre projet !

Opinions