Comment configurer la réplication de groupe MySQL sur Ubuntu 16.04

introduction

La réplication MySQL reflète de manière fiable les données et les opérations d'une base de données à une autre. La réplication conventionnelle implique un serveur principal configuré pour accepter les opérations d'écriture de base de données avec des serveurs secondaires qui copient et appliquent des actions du journal du serveur principal à leurs propres ensembles de données. Ces serveurs secondaires peuvent être utilisés pour des lectures, mais sont généralement incapables d'exécuter des écritures de données.

La réplication de groupe est un moyen d'implémenter un mécanisme de réplication plus souple et tolérant aux pannes. Ce processus implique la création d'un pool de serveurs, chacun assurant que les données sont copiées correctement. Si le serveur principal rencontre des problèmes, les élections des membres peuvent sélectionner un nouveau principal du groupe. Cela permet aux nœuds restants de continuer à fonctionner, même en cas de problème. La négociation d'appartenance, la détection des échecs et la remise des messages sont fournies par une implémentation desPaxos concensus algorithm.

Dans ce tutoriel, nous allons configurer la réplication de groupe MySQL en utilisant un ensemble de trois serveurs Ubuntu 16.04. La configuration couvrira la manière d’exploiter un groupe de réplication principal ou multi-primaire.

Conditions préalables

Pour suivre, vous aurez besoin d’un groupe de trois serveurs Ubuntu 16.04. Sur chacun de ces serveurs, vous devrez configurer un utilisateur non root avec les privilègessudo et configurer un pare-feu de base. Nous utiliserons lesinitial server setup guide for Ubuntu 16.04 pour satisfaire ces exigences et mettre chaque serveur dans un état prêt.

La version de MySQL dans les référentiels par défaut d’Ubuntu n’inclut pas le plug-in de réplication de groupe dont nous avons besoin. Heureusement, le projet MySQL gère ses propres référentiels pour la dernière version de MySQL, qui inclut ce composant. Suivez notre guide surinstalling the latest MySQL on Ubuntu 16.04 pour installer une version de MySQL compatible avec la réplication de groupe sur chaque serveur.

Générer un UUID pour identifier le groupe MySQL

Avant d'ouvrir le fichier de configuration MySQL pour configurer les paramètres de réplication de groupe, nous devons générer un UUID que nous pouvons utiliser pour identifier le groupe MySQL que nous allons créer.

Surmysqlmember1, utilisez la commandeuuidgen pour générer un UUID valide pour le groupe:

uuidgen
Output959cf631-538c-415d-8164-ca00181be227

Copiez la valeur que vous recevez. Nous devrons faire référence à cela dans un moment lors de la configuration d'un nom de groupe pour notre pool de serveurs.

Configurer la réplication de groupe dans le fichier de configuration MySQL

Nous sommes maintenant prêts à modifier le fichier de configuration de MySQL. Ouvrez le fichier de configuration principal de MySQL sureach MySQL server:

sudo nano /etc/mysql/my.cnf

Par défaut, ce fichier est uniquement utilisé pour générer des fichiers supplémentaires à partir de sous-répertoires. Nous devrons ajouter notre propre configurationbeneath aux lignes!includedir. Cela nous permet de remplacer facilement tous les paramètres des fichiers inclus.

Pour commencer, ouvrez une section pour les composants du serveur MySQL en incluant un en-tête[mysqld]. En dessous, nous allons coller les paramètres nécessaires à la réplication de groupe. Le préfixeloose- permet à MySQL de gérer gracieusement les options qu'il ne reconnaît pas correctement sans échec. Nous devrons définir et personnaliser plusieurs de ces paramètres en un instant:

/etc/mysql/my.cnf

. . .
!includedir /etc/mysql/conf.d/
!includedir /etc/mysql/mysql.conf.d/

[mysqld]

# General replication settings
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
binlog_checksum = NONE
log_slave_updates = ON
log_bin = binlog
binlog_format = ROW
transaction_write_set_extraction = XXHASH64
loose-group_replication_bootstrap_group = OFF
loose-group_replication_start_on_boot = OFF
loose-group_replication_ssl_mode = REQUIRED
loose-group_replication_recovery_use_ssl = 1

# Shared replication group configuration
loose-group_replication_group_name = ""
loose-group_replication_ip_whitelist = ""
loose-group_replication_group_seeds = ""

# Single or Multi-primary mode? Uncomment these two lines
# for multi-primary mode, where any host can accept writes
#loose-group_replication_single_primary_mode = OFF
#loose-group_replication_enforce_update_everywhere_checks = ON

# Host specific replication configuration
server_id =
bind-address = ""
report_host = ""
loose-group_replication_local_address = ""

Nous avons divisé la configuration ci-dessus en quatre sections. Allons-y maintenant.

Paramètres de réplication du groupe de plaques de cuisson

La première section contient les paramètres généraux requis pour la réplication de groupe qui ne nécessitent aucune modification:

/etc/mysql/my.cnf

. . .
# General replication settings
gtid_mode = ON
enforce_gtid_consistency = ON
master_info_repository = TABLE
relay_log_info_repository = TABLE
binlog_checksum = NONE
log_slave_updates = ON
log_bin = binlog
binlog_format = ROW
transaction_write_set_extraction = XXHASH64
loose-group_replication_bootstrap_group = OFF
loose-group_replication_start_on_boot = OFF
loose-group_replication_ssl_mode = REQUIRED
loose-group_replication_recovery_use_ssl = 1
. . .

Ces paramètres activent les identificateurs de transaction globaux, configurent la journalisation binaire requise pour la réplication de groupe et configurent SSL pour le groupe. La configuration configure également quelques autres éléments qui facilitent la récupération et l’amorçage. Vous n'avez rien à modifier dans cette section, vous pouvez donc continuer après l'avoir collée.

Paramètres de réplication de groupe partagé

La deuxième section définit les paramètres partagés pour le groupe. Nous devrons personnaliser cela une fois, puis utiliser les mêmes paramètres sur chacun de nos nœuds. Cela inclut l'UUID du groupe, une liste blanche de membres acceptables et des membres de départ à contacter pour obtenir des données initiales.

Définissez lesloose-group_replication_group_name sur l'UUID que vous avez généré précédemment avec la commandeuuidgen. Collez l'UUID que vous avez copié comme valeur pour cette variable.

Ensuite, définissezloose-group_replication_ip_whitelist sur une liste de toutes les adresses IP de votre serveur MySQL, séparées par des virgules. Le paramètreloose-group_replication_group_seeds doit être presque le même que la liste blanche, mais doit ajouter le port de réplication de groupe que nous utiliserons à la fin de chaque membre. Pour ce guide, nous allons utiliser le port recommandé 33061 pour la réplication de groupe:

/etc/mysql/my.cnf

. . .
# Shared replication group configuration
loose-group_replication_group_name = "959cf631-538c-415d-8164-ca00181be227"
loose-group_replication_ip_whitelist = "203.0.113.1,203.0.113.2,203.0.113.3"
loose-group_replication_group_seeds = ""203.0.113.1:33061,203.0.113.2:33061,203.0.113.3:33061"
. . .

Cette section devrait être identique sur chacun de vos serveurs MySQL, assurez-vous donc de la copier avec soin.

Choisir un seul primaire ou plusieurs primaires

Ensuite, vous devez décider de configurer un groupe primaire unique ou multiple. Dans certaines parties de la documentation officielle de MySQL, cette distinction est également appelée réplication «simple» ou réplication «multi-maître». Dans une configuration primaire unique, MySQL désigne un seul serveur principal (presque toujours le premier membre du groupe) pour gérer les opérations d'écriture. Un groupe multi-primaire autorise les écritures sur l'un des membres du groupe.

Si vous souhaitez configurer un groupe multi-primaire, décommentez les directivesloose-group_replication_single_primary_mode etloose-group_replication_enforce_update_everywhere_checks. Cela mettra en place un groupe multi-primaire. Pour un seul groupe principal, laissez simplement ces deux lignes commentées:

/etc/mysql/my.cnf

. . .
# Single or Multi-primary mode? Uncomment these two lines
# for multi-primary mode, where any host can accept writes
#loose-group_replication_single_primary_mode = OFF
#loose-group_replication_enforce_update_everywhere_checks = ON
. . .

Ces paramètres doivent être les mêmes sur chacun de vos serveurs MySQL.

Vous pouvez modifier ce paramètre ultérieurement, mais pas sans redémarrer votre groupe MySQL. Pour passer à la nouvelle configuration, vous devez arrêter chacune des instances MySQL du groupe, démarrer chaque membre avec les nouveaux paramètres, puis réamorcer la réplication du groupe. Cela n'affectera aucune de vos données, mais nécessite une petite fenêtre d'indisponibilité.

Paramètres de configuration spécifiques à l'hôte

La quatrième section contient les paramètres qui seront différents sur chacun des serveurs, notamment:

  • L'identifiant du serveur

  • L'adresse à laquelle se lier

  • L'adresse à signaler aux autres membres

  • L'adresse de réplication locale et le port d'écoute

La directiveserver_id doit être définie sur un nombre unique. Pour le premier membre, définissez simplement la valeur sur «1» et incrémentez le nombre sur chaque hôte supplémentaire. Définissezbind-address etreport_host sur l'adresse IP du serveur actuel afin que l'instance MySQL écoute les connexions externes et signale correctement son adresse aux autres hôtes. Lesloose-group_replication_local_address doivent également être définis sur l’adresse IP du serveur actuel avec le port de réplication de groupe (33061), ajouté à l’adresse IP:

/etc/mysql/my.cnf

. . .
# Host specific replication configuration
server_id = 1
bind-address = "203.0.113.1"
report_host = "203.0.113.1"
loose-group_replication_local_address = "203.0.113.1:33061"

Terminez ce processus sur chacun de vos serveurs MySQL.

Lorsque vous avez terminé, vérifiez que les paramètres de réplication partagée sont les mêmes sur chaque hôte et que les paramètres spécifiques à l'hôte sont personnalisés pour chaque hôte. Enregistrez et fermez le fichier sur chaque hôte lorsque vous avez terminé.

Redémarrez MySQL et activez l'accès à distance

Notre fichier de configuration MySQL contient maintenant les directives requises pour amorcer la réplication de groupe MySQL. Pour appliquer les nouveaux paramètres à l'instance MySQL, redémarrez le service sureach of your servers avec la commande suivante:

sudo systemctl restart mysql

Dans le fichier de configuration MySQL, nous avons configuré le service pour qu'il écoute les connexions externes sur le port par défaut 3306. Nous avons également défini 33061 comme le port que les membres doivent utiliser pour la coordination de la réplication.

Nous devons ouvrir l'accès à ces deux ports dans notre pare-feu, ce que nous pouvons faire en tapant:

sudo ufw allow 33061
sudo ufw allow 3306

Avec l'accès aux ports MySQL ouverts, nous pouvons créer un utilisateur de réplication et activer le plug-in de réplication de groupe.

Configurer l'utilisateur de réplication et activer le plug-in de réplication de groupe

Sureach of your MySQL servers, connectez-vous à votre instance MySQL avec l'utilisateur administratif pour démarrer une session interactive:

mysql -u root -p

Vous serez invité à entrer le mot de passe administratif MySQL. Ensuite, vous serez plongé dans une session MySQL. La première chose à faire est de créer un utilisateur de réplication.

Un utilisateur de réplication est requis sur chaque serveur pour établir la réplication de groupe. Étant donné que chaque serveur aura son propre utilisateur de réplication, nous devons désactiver la journalisation binaire lors du processus de création. Sinon, une fois que la réplication aura commencé, le groupe tentera de propager l'utilisateur de réplication du serveur principal vers les autres serveurs, créant ainsi un conflit avec l'utilisateur de réplication déjà en place.

Nous aurons besoin de SSL pour l'utilisateur de réplication, lui attribuerons des privilèges de réplication sur le serveur, puis nous viderons ces privilèges pour implémenter les modifications. Ensuite, nous réactiverons la journalisation binaire pour reprendre des opérations normales. Veillez à utiliser un mot de passe sécurisé lors de la création de l'utilisateur de réplication:

SET SQL_LOG_BIN=0;
CREATE USER 'repl'@'%' IDENTIFIED BY 'password' REQUIRE SSL;
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
SET SQL_LOG_BIN=1;

Ensuite, nous devons définir le canalgroup_replication_recovery pour utiliser notre nouvel utilisateur de réplication et le mot de passe associé. Chaque serveur utilisera ensuite ces informations d'identification pour s'authentifier auprès du groupe.

CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';

Avec l'utilisateur de réplication en place, nous pouvons permettre au plug-in de réplication de groupe de se préparer à initialiser le groupe. Puisque nous utilisons la dernière version de MySQL, nous pouvons activer le plugin en tapant:

INSTALL PLUGIN group_replication SONAME 'group_replication.so';

Vérifiez que le plugin est actif en tapant:

SHOW PLUGINS;
Output+----------------------------+----------+--------------------+----------------------+---------+
| Name                       | Status   | Type               | Library              | License |
+----------------------------+----------+--------------------+----------------------+---------+
|                            |          |                    |                      |         |
| . . .                      | . . .    | . . .              | . . .                | . . .   |
|                            |          |                    |                      |         |
| group_replication          | ACTIVE   | GROUP REPLICATION  | group_replication.so | GPL     |
+----------------------------+----------+--------------------+----------------------+---------+
45 rows in set (0.00 sec)

La lignegroup_replication confirme que le plugin a été chargé et est actuellement actif.

Démarrer la réplication de groupe

Maintenant que chaque serveur MySQL a un utilisateur de réplication configuré et que le plug-in de réplication de groupe est activé, nous pouvons commencer à afficher notre groupe.

Bootstrap Premier Nœud

Pour démarrer le groupe, procédez comme suit sura single member of the group.

Les membres du groupe comptent sur les membres existants pour envoyer des données de réplication, des listes de membres à jour et d'autres informations lors de leur intégration initiale au groupe. Pour cette raison, nous devons utiliser une procédure légèrement différente pour démarrer le membre du groupe initial afin qu'il sache qu'il ne doit pas s'attendre à recevoir ces informations des autres membres de sa liste d'origine.

Si elle est définie, la variablegroup_replication_bootstrap_group indique à un membre qu’il ne doit pas s’attendre à recevoir des informations de ses pairs et doit plutôt établir un nouveau groupe et s’élire lui-même le membre principal. Étant donné que la seule situation appropriée est celle où il n'y a aucun membre de groupe existant, nous désactiverons cette fonctionnalité immédiatement après le démarrage du groupe:

SET GLOBAL group_replication_bootstrap_group=ON;
START GROUP_REPLICATION;
SET GLOBAL group_replication_bootstrap_group=OFF;

Le groupe doit être démarré avec ce serveur en tant que membre unique. Nous pouvons le vérifier en vérifiant les entrées de la tablereplication_group_members dans la base de donnéesperformance_schema:

SELECT * FROM performance_schema.replication_group_members;

Vous devriez voir une seule ligne représentant l'hôte actuel:

Output+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
1 row in set (0.00 sec)

La valeurONLINE pourMEMBER_STATE indique que ce nœud est pleinement opérationnel au sein du groupe.

Ensuite, créez une base de données de test et une table pour tester notre réplication:

CREATE DATABASE playground;
CREATE TABLE playground.equipment ( id INT NOT NULL AUTO_INCREMENT, type VARCHAR(50), quant INT, color VARCHAR(25), PRIMARY KEY(id));
INSERT INTO playground.equipment (type, quant, color) VALUES ("slide", 2, "blue");

Vérifiez le contenu pour vous assurer qu'il a été saisi correctement:

SELECT * FROM playground.equipment;
Output+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+
1 row in set (0.00 sec)

Nous avons maintenant vérifié que ce serveur est un membre du groupe et qu’il dispose de fonctionnalités d’écriture. Maintenant, les autres serveurs peuvent rejoindre le groupe.

Démarrer les nœuds restants

Ensuite, sur lessecond server, démarrez la réplication de groupe. Comme nous avons déjà un membre actif, nous n’avons pas besoin de booter le groupe et nous pouvons simplement le rejoindre:

START GROUP_REPLICATION;

Sur lesthird server, démarrez la réplication de groupe de la même manière:

START GROUP_REPLICATION;

Vérifiez à nouveau la liste des membres. Vous devriez voir trois serveurs maintenant:

SELECT * FROM performance_schema.replication_group_members;
Output+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)

Tous les membres doivent avoir une valeurMEMBER_STATE deONLINE. Pour un nouveau groupe, si l'un des nœuds est répertorié commeRECOVERING pendant plus d'une seconde ou deux, c'est généralement une indication qu'une erreur s'est produite ou que quelque chose a été mal configuré. Consultez les journaux à/var/log/mysql/error.log pour obtenir des informations supplémentaires sur ce qui n'a pas fonctionné.

Vérifiez si les informations de la base de données de test ont été répliquées sur les nouveaux membres:

SELECT * FROM playground.equipment;
Output+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+
1 row in set (0.01 sec)

Si les données sont disponibles sur les nouveaux membres, cela signifie que la réplication de groupe fonctionne correctement.

Test des capacités d'écriture des nouveaux membres du groupe

Ensuite, nous pouvons essayer d’écrire dans la base de données à partir de nos nouveaux membres. Le succès de cette opération dépend du choix de configurer un seul groupe principal ou plusieurs groupes principaux.

Test des écritures dans un seul environnement primaire

Dans un seul groupe principal, vous devez vous attendre à ce que les opérations d'écriture du serveur non principal soient rejetées pour des raisons de cohérence. Vous pouvez découvrir le principal actuel à tout moment avec la requête suivante:

SHOW STATUS LIKE '%primary%';
Output+----------------------------------+--------------------------------------+
| Variable_name                    | Value                                |
+----------------------------------+--------------------------------------+
| group_replication_primary_member | 13324ab7-1b01-11e7-9dd1-22b78adaa992 |
+----------------------------------+--------------------------------------+
1 row in set (0.01 sec)

La valeur de la requête sera unMEMBER_ID que vous pouvez associer à un hôte en interrogeant la liste des membres du groupe comme nous l'avons fait auparavant:

SELECT * FROM performance_schema.replication_group_members;
Output+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)

Dans cet exemple, nous pouvons voir que l'hôte à203.0.113.1 est actuellement le serveur principal. Si nous essayons d'écrire dans la base de données à partir d'un autre membre, nous devrions nous attendre à ce que l'opération échoue:

INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");
OutputERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement

Cela est prévu car le groupe est actuellement configuré avec un seul primaire capable d'écrire. Si le serveur principal a des problèmes et quitte le groupe, le groupe élira automatiquement un nouveau membre comme principal et acceptera les écritures.

Test des écritures dans un environnement multi-primaire

Pour les groupes configurés dans une orientation multi-primaire, tout membre doit pouvoir commettre des écritures dans la base de données.

Vous pouvez revérifier que votre groupe fonctionne en mode multi-primaire en vérifiant à nouveau la valeur de la variablegroup_replication_primary_member:

SHOW STATUS LIKE '%primary%';
Output+----------------------------------+-------+
| Variable_name                    | Value |
+----------------------------------+-------+
| group_replication_primary_member |       |
+----------------------------------+-------+
1 row in set (0.02 sec)

Si la variable est vide, cela signifie qu'il n'y a pas d'hôte principal désigné et que tout membre doit pouvoir accepter les écritures.

Testez ceci sur vossecond server en tapant:

INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");
OutputQuery OK, 1 row affected (0.00 sec)

Le deuxième serveur a validé l'opération d'écriture sans erreur.

Sur lesthird server, interrogez pour voir que le nouvel élément a été ajouté:

SELECT * FROM playground.equipment;
Output+----+-------+-------+--------+
| id | type  | quant | color  |
+----+-------+-------+--------+
|  1 | slide |     2 | blue   |
|  2 | swing |    10 | yellow |
+----+-------+-------+--------+
2 rows in set (0.00 sec)

Cela confirme que l’écriture du deuxième serveur a été répliquée avec succès.

Maintenant, testez les capacités d’écriture sur le troisième serveur en tapant:

INSERT INTO playground.equipment (type, quant, color) VALUES ("seesaw", 3, "green");
OutputQuery OK, 1 row affected (0.02 sec)

De retour sur lesfirst server, testez pour vous assurer que les opérations d'écriture des deux nouveaux membres ont été répliquées:

SELECT * FROM playground.equipment;
Output+----+--------+-------+--------+
| id | type   | quant | color  |
+----+--------+-------+--------+
|  1 | slide  |     2 | blue   |
|  2 | swing  |    10 | yellow |
|  3 | seesaw |     3 | green  |
+----+--------+-------+--------+
3 rows in set (0.01 sec)

Cela confirme que la réplication fonctionne dans chaque sens et que chaque membre est capable d'effectuer des opérations d'écriture.

Faire remonter le groupe

Une fois le groupe démarré, les membres individuels peuvent rejoindre et quitter sans affecter la disponibilité, tant qu'il y a suffisamment de membres pour élire les serveurs principaux. Toutefois, si certaines modifications de configuration sont apportées (par exemple, la commutation entre des environnements simples ou multi-primaires) ou si tous les membres du groupe partent, vous devrez peut-être réamorcer le groupe. Vous faites cela de la même manière que vous l'avez fait initialement.

Sur vosfirst server, définissez la variablegroup_replciation_bootstrap_group puis commencez à initialiser le groupe:

SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=ON;
START GROUP_REPLICATION;
SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=OFF;

Une fois que le premier membre a démarré le groupe, les autres membres peuvent rejoindre:

START GROUP_REPLICATION;

Suivez ce processus pour les membres supplémentaires:

START GROUP_REPLICATION;

Le groupe devrait maintenant être en ligne avec tous les membres disponibles:

SELECT * FROM performance_schema.replication_group_members;
Output+---------------------------+--------------------------------------+--------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       |
+---------------------------+--------------------------------------+--------------+-------------+--------------+
3 rows in set (0.01 sec)

Ce processus peut être utilisé pour redémarrer le groupe chaque fois que nécessaire.

Rejoindre un groupe automatiquement au démarrage de MySQL

Avec les paramètres actuels, si un serveur membre redémarre, il ne rejoindra pas automatiquement le groupe au démarrage. Si vous souhaitez que les membres rejoignent automatiquement le groupe, vous pouvez légèrement modifier le fichier de configuration.

Le paramètre que nous allons décrire est utile lorsque vous souhaitez que les membres se joignent automatiquement au démarrage. Cependant, il y a certaines choses dont vous devez être conscient:

Tout d’abord, ce paramètre n’affecte que le démarrage de l’instance MySQL. Si le membre est supprimé du groupe en raison de problèmes de délai d'expiration, mais que l'instance MySQL est restée en ligne, le membre ne le rejoindra pas automatiquement.

Deuxièmement, l'activation de ce paramètre lors de la première initialisation d'un groupe peut être préjudiciable. Lorsqu'il n'y a pas de groupe existant à rejoindre, le processus MySQL mettra du temps à démarrer car il tentera de contacter d'autres membres non existants pour l'initialiser. Ce n'est qu'après un long délai qu'il abandonne et démarre normalement. Ensuite, vous devrez utiliser la procédure décrite ci-dessus pour amorcer le groupe.

Compte tenu des mises en garde ci-dessus, si vous souhaitez configurer les noeuds pour qu'ils rejoignent automatiquement le groupe au démarrage de MySQL, ouvrez le fichier de configuration principal de MySQL:

sudo nano /etc/mysql/my.cnf

À l'intérieur, recherchez la variableloose-group_replication_start_on_boot et définissez-la sur «ON»:

/etc/mysql/my.cnf

[mysqld]
. . .
loose-group_replication_start_on_boot = ON
. . .

Enregistrez et fermez le fichier lorsque vous avez terminé. Le membre doit automatiquement essayer de rejoindre le groupe au prochain démarrage de son instance MySQL.

Conclusion

Dans ce tutoriel, nous avons expliqué comment configurer la réplication de groupe MySQL entre trois serveurs Ubuntu 16.04. Pour les configurations à un seul primaire, les membres éliront automatiquement un principal capable d'écrire si nécessaire. Pour les groupes multi-primaires, tout membre peut effectuer des écritures et des mises à jour.

La réplication de groupe fournit une topologie de réplication flexible qui permet aux membres de rejoindre ou de quitter à volonté, tout en offrant des garanties sur la cohérence des données et le classement des messages. La réplication de groupe MySQL peut être un peu plus complexe à configurer, mais elle offre des fonctionnalités impossibles avec la réplication traditionnelle.