Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
💥 1 livre papier acheté 
= la version en ligne automatiquement offerte. Cliquez ici
  1. Livres et vidéos
  2. MariaDB
  3. Réplication
Extrait - MariaDB Administration et optimisation
Extraits du livre
MariaDB Administration et optimisation
2 avis
Revenir à la page d'achat du livre

Réplication

Généralités sur la réplication

MariaDB dispose d’un système natif de réplication, simple à mettre en place et pouvant être utile dans de nombreuses situations. Quand un serveur (l’esclave) réplique les données d’un autre serveur (le maître), l’esclave est automatiquement synchronisé par rapport à son maître. La plupart des applications ayant MariaDB pour SGBD utilisent la réplication pour aider à tenir la charge, pour augmenter la disponibilité de la base de données, pour simplifier la mise en place de sauvegardes, pour décharger le maître de lourdes requêtes consommatrices de ressources et pour bien d’autres raisons encore.

Ce chapitre va, entre autres, vous expliquer quels sont les problèmes que la réplication peut résoudre, comment configurer un maître et un esclave et ce qu’il convient de faire si la réplication ne fonctionne plus.

1. Utilité de la réplication

La réplication est susceptible de vous aider pour un grand nombre de problèmes courants avec les bases de données :

  • La tenue à la montée en charge des lectures : bien souvent, une application ne fonctionne au départ qu’avec un seul serveur de bases de données. Mais si le trafic augmente, on arrive très vite à un point où le serveur n’a plus les capacités de faire face à toutes les lectures et toutes les écritures. Dans les applications web, les lectures sont généralement majoritaires par rapport aux écritures. Dans ce cas, en mettant en place des serveurs esclaves, il devient possible de transmettre les écritures sur le maître et de lire sur l’un des esclaves. Attention pour les applications où les écritures sont majoritaires, ce modèle ne fonctionne pas (nous y reviendrons).

  • Une aide aux sauvegardes : sauvegarder ses données est bien sûr indispensable mais l’impact sur le serveur est souvent loin d’être négligeable. En effectuant la sauvegarde sur un esclave, qui contient une copie des données du maître, il est beaucoup plus simple de diminuer l’impact des sauvegardes sur l’application. Attention, faire une sauvegarde sur un esclave signifie qu’il...

Mise en place de la réplication

1. Réplication maître-esclave(s)

a. Configuration

images/07EI02N.png

Commençons par le cas le plus simple : celui où le maître et l’esclave sont fraîchement installés, c’est-à-dire sans aucune donnée. Il vous faudra accomplir les étapes suivantes :

  • Créer un utilisateur pour la réplication sur le maître :

    L’esclave doit pouvoir se connecter sur le maître (IO_THREAD). Il faut donc créer un compte dédié sur le maître avec le droit REPLICATION SLAVE. En réalité, bien souvent, il est pratique de créer aussi un compte symétrique sur l’esclave (utile si l’esclave peut être promu en maître, dans ce cas la réplication devra s’exécuter dans le sens opposé) et d’ajouter le droit REPLICATION CLIENT qui permet des commandes importantes pour le monitoring de la réplication :


mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT on *.* to 
'repli_user'@'IP_esclave' IDENTIFIED BY 'mon_mdp';
 
  • Configurer le maître :

    Il faut activer les journaux binaires sur le maître et déclarer un identifiant appelé server_id, qui devra être unique parmi tous les serveurs associés par la réplication. Ces modifications se font dans le fichier my.cnf/my.ini et nécessitent un redémarrage du serveur :


[mysqld] 
log_bin = /var/lib/mysql/mysql-bin 
server_id = 100
 
  • Configurer l’esclave :

    Chaque esclave doit lui aussi avoir un server_id unique. Il est inutile d’activer les journaux binaires, sauf si l’esclave est lui-même maître d’autres esclaves :


[mysqld] 
server_id = 101
 
  • Saisir les coordonnées de réplication :

    Vous obtenez les coordonnées de réplication sur le maître avec l’instruction suivante :


mysql> SHOW MASTER STATUS; 
+---------------+----------+--------------+------------------+ 
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | 
+---------------+----------+--------------+------------------+ 
| mysql-bin.004 | 106      |              |                  | 
+---------------+----------+--------------+------------------+...

Résolution des problèmes opérationnels courants

1. Empêcher la réplication de certaines requêtes

Par défaut, toutes les écritures du maître sont écrites dans les journaux binaires. Ces journaux binaires sont copiés sur les esclaves, donc les esclaves répliquent toutes les requêtes du maître. Cependant, dans certains cas, vous ne souhaiterez pas répliquer certaines requêtes, par exemple si vous voulez avoir un esclave qui ne contient pas un des schémas du maître. Dans ce cas, vous devrez utiliser un filtre de réplication.

Le filtrage est possible sur le maître à l’aide des options binlog-do-db et binlog-ignore-db ou sur les esclaves à l’aide des options replicate-do-db et replicate-ignore-db. Sauf exception, vous préférerez toujours les filtres sur les esclaves. En effet, un filtre sur le maître va empêcher certaines requêtes d’être enregistrées dans les journaux binaires. Or, dans le pire des cas, vous pouvez avoir besoin de restaurer vos données en restaurant d’abord une sauvegarde, puis en appliquant toutes les écritures stockées dans les journaux binaires. Si des requêtes n’ont pas été enregistrées dans les journaux binaires, les écritures correspondantes seront perdues.

Un autre point important est que les règles de filtrage ne fonctionnent pas de la même manière selon le format des journaux binaires.

Avec le format SBR (Statement-Based Replication), seule la base courante est vérifiée. Par exemple, si vous utilisez binlog-do-db=db1, l’ordre INSERT suivant sera tout de même répliqué :


mysql> USE db1;  
Database changed  
mysql > INSERT INTO db2.t1 values(10);
 

Inversement, la requête suivante ne sera pas répliquée, bien que la table t2 appartienne à la base db1 que nous répliquons :


mysql> USE db2;  
Database changed  
mysql > INSERT INTO db1.t2 values(10);
 

Avec le format RBR, les ordres de modification sont répliqués si les objets auxquels ils s’appliquent sont concernés par les règles. Si la table modifiée n’appartient pas à la base db1 alors elle ne sera pas répliquée, même...

Réplication et haute disponibilité

1. Promotion d’un esclave

La réplication est très utile pour assurer la disponibilité des serveurs MariaDB : si le maître devient inutilisable (crash logiciel, problème matériel, par exemple), il est bien souvent beaucoup plus rapide de remplacer le maître par un esclave plutôt que d’essayer de remettre en route le maître. Les opérations nécessaires pour la promotion ne sont en théorie pas trop complexes, mais elles doivent être effectuées minutieusement, en particulier pour ne pas faire d’erreur dans les coordonnées de réplication. De plus, ces opérations sont souvent seulement nécessaires en cas de crise, et il est bien connu que sous la pression, il est bien plus facile de commettre des erreurs. C’est pourquoi nous vous recommandons de bien maîtriser les techniques expliquées dans cette section et d’essayer de vous entraîner afin de vous sentir à l’aise pour le jour où vous en aurez besoin.

Avant de commencer la promotion d’un esclave, il est conseillé d’interrompre les écritures sur l’ancien maître. Voici ensuite la liste des étapes à effectuer :

  • Identifier l’esclave que vous allez promouvoir si plusieurs esclaves sont disponibles. Il suffit d’utiliser la commande...

Réplication et scalabilité

1. Scalabilité en lecture

L’une des utilisations les plus courantes de la réplication est de permettre d’offrir à une application plusieurs serveurs pour effectuer les lectures. En effet, si toutes les écritures doivent être exécutées sur le maître, les lectures peuvent en théorie être effectuées indifféremment sur le maître ou sur n’importe quel esclave, et dans la majorité des applications utilisant MariaDB, les lectures sont majoritaires par rapport aux écritures.

Comme il a déjà été mentionné, la réalité est différente : la réplication MariaDB est asynchrone, il n’est donc pas possible de savoir si un esclave contient exactement les mêmes données que le maître. Notez que le retard de réplication donné par la variable Seconds_behind_master dans le résultat de SHOW SLAVE STATUS n’est d’ailleurs pas un indicateur fiable puisque la granularité du compteur est la seconde.

Si le maître exécute 1000 écritures par seconde, un retard de 100 ms (qui apparaîtra comme étant 0 avec Seconds_Behind_Master) signifie un retard de 100 requêtes.

Par conséquent, l’application devra sans doute avoir une logique suffisamment fine pour savoir quelles lectures...

Fonctionnalités avancées

1. Identifiants de transaction

Depuis la version 10.0, MariaDB construit automatiquement un identifiant unique (GTID - Global Transaction Identifier) pour chaque transaction. Cet identifiant est beaucoup plus intéressant que les classiques coordonnées de réplication car il est le même sur tous les serveurs impliqués dans un système de réplication. Nous avons vu que la reconstruction d’un esclave à partir d’un autre esclave pouvait être rendue difficile par le fait qu’une même transaction n’a pas les mêmes coordonnées de réplication sur le maître et sur les esclaves (deux esclaves ont d’ailleurs eux-mêmes des positions différentes pour une même transaction). Les GTID résolvent ce problème.

Il est important de noter que les GTID de MySQL et les GTID de MariaDB sont incompatibles. Leur utilisation peut donc rendre difficile une migration de MySQL vers MariaDB (ou inversement).

Dans MariaDB, un GTID a la forme suivante : A-B-C, où A, B et C sont des nombres entiers :

  • A est le domaine. Il peut être utilisé pour signaler à MariaDB que des flux d’écritures proviennent de sources différentes, ce qui est par exemple utile pour la réplication multisource.

  • B est le server_id.

  • C est un identifiant strictement croissant, à la manière d’un champ avec auto_increment.

Notez que si les GTID sont activés par défaut (contrairement à MySQL), la réplication n’utilise pas les GTID par défaut. Il vous faudra explicitement reconfigurer chaque esclave. Le principe est simple, mais il existe deux cas de figures distincts :

  • Si le serveur est déjà un esclave de réplication, vous exécuterez la commande suivante :


mysql> CHANGE MASTER TO master_use_gtid = slave_pos;
 
  • Si le serveur n’est pas esclave de réplication, vous exécuterez la commande suivante :


mysql> CHANGE MASTER TO master_use_gtid = current_pos;
 
  • Si vous ne savez pas dans quelle situation vous vous trouvez, exécutez cette requête :


mysql> SELECT @@global.gtid_slave_pos;
 

Si vous obtenez un résultat non vide, vous êtes dans le premier cas et sinon vous êtes dans le second cas.

2. Réplication parallèle...