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

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

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

BACKUP

ipv4: 104.xxx.xxx.186
Private IP:  10.134.4.220

Floating IP

Floating IP:  138.xxx.xxx.177

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.

A lire :  Rapidshare impose de nouvelles limites : espace limité à 50 Go par défaut pour les comptes premium

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

# /MATT

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;

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)

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

# /MATT

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;

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)

Les deux lignes critiques à vérifier sont :

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

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.

A lire :  Bash : supprimer tous les fichiers et sous-répertoires d'un répertoire

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 = 36986964

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;

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.

Sommaire de la série 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

Pour développer votre projet WordPress ou Woocommerce, faites appel à mon expertise pour réaliser un site rapide, performant et fonctionnel.

Contactez-moi

Si vous avez trouvé une faute d’orthographe, informez-nous en sélectionnant le texte en question et en appuyant sur Ctrl + Entrée s’il vous plaît.

Articles en rapport:

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

par Matt Lecture: 6 min
0

Pin It on Pinterest

Share This

Spelling error report

The following text will be sent to our editors: