Comment configurer la réplication de groupe MySQL sur Ubuntu 20.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 vers une autre. La réplication conventionnelle implique un serveur principal configuré pour accepter les opérations d’écriture de la base de données avec des serveurs secondaires qui copient et appliquent les actions du journal du serveur principal à leurs propres ensembles de données. Ces serveurs secondaires peuvent être utilisés pour les lectures, mais sont généralement incapables d’exécuter des écritures de données.

La réplication de groupe est une façon de mettre en œuvre un mécanisme de réplication plus flexible et tolérant aux pannes. Ce processus implique d’établir un pool de serveurs, chacun étant impliqué dans l’assurance que les données sont copiées correctement. Si le serveur principal rencontre des problèmes, des élections de membres peuvent sélectionner un nouveau serveur principal dans le groupe. Cela permet aux nœuds restants de continuer à fonctionner, même en cas de problèmes. La négociation de l’adhésion, la détection des pannes et la livraison des messages sont assurées par une implémentation de l’algorithme de consensus Paxos.

Dans ce tutoriel, vous configurerez la réplication de groupe MySQL en utilisant un ensemble de trois serveurs Ubuntu 20.04. Notez que trois est le nombre minimum d’instances MySQL que vous devez déployer pour la réplication de groupe dans MySQL, tandis que neuf est le maximum. Pendant que vous travaillez sur ce tutoriel, vous aurez la possibilité de configurer le groupe en tant que groupe de réplication à serveur principal unique ou à plusieurs serveurs principaux.

Prérequis

Pour suivre ce guide, vous aurez besoin de :

• Trois serveurs exécutant Ubuntu 20.04. Chacun devrait avoir un utilisateur administratif non root avec des privilèges sudo et un pare-feu configuré avec UFW. Suivez notre guide de configuration initiale du serveur pour Ubuntu 20.04 pour configurer chaque serveur.
• MySQL installé sur chaque serveur. Ce guide suppose que vous utilisez la dernière version de MySQL disponible dans les dépôts par défaut d’Ubuntu, qui, au moment de la rédaction, est la version 8.0.28. Pour installer cela sur tous vos serveurs, suivez notre guide sur Comment installer MySQL sur Ubuntu 20.04 pour chaque machine.

Pour aider à maintenir la clarté, ce guide fera référence aux trois serveurs comme membre1, membre2 et membre3. Dans les exemples tout au long de ce guide, ces membres auront les adresses IP suivantes :

Toutes les commandes qui doivent être exécutées sur membre1 auront un arrière-plan bleu, comme ceci :

De même, toutes les commandes qui doivent être exécutées sur membre2 auront un arrière-plan rouge :

Et toutes les commandes qui doivent être exécutées sur membre3 auront un arrière-plan vert :

Enfin, toutes les commandes qui doivent être exécutées sur chacun des trois serveurs auront un arrière-plan standard :

Étape 1 — Génération d’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, vous devez générer un UUID que vous pourrez utiliser pour identifier le groupe MySQL que vous allez créer.

Sur member1, utilisez la commande uuidgen pour générer un UUID valide pour le groupe :

uuidgen

Output
168dcb64-7cce-473a-b338-6501f305e561

Copiez la valeur que vous recevez, car vous devrez la référencer dans un instant lors de la configuration d’un nom de groupe pour votre pool de serveurs.

Étape 2 — Configuration de la réplication de groupe dans le fichier de configuration MySQL

Maintenant, vous êtes prêt à modifier le fichier de configuration de MySQL. Ouvrez le fichier de configuration MySQL principal sur chaque serveur MySQL en utilisant votre éditeur de texte préféré. Ici, nous utiliserons nano:

sudo nano /etc/mysql/my.cnf

Sur Ubuntu, MySQL est installé avec plusieurs fichiers différents que vous pouvez utiliser pour définir divers changements de configuration. Par défaut, le fichier my.cnf est uniquement utilisé pour inclure des fichiers supplémentaires à partir de sous-répertoires. Vous devrez ajouter votre propre configuration sous les lignes !includedir. Cela vous permettra de remplacer les paramètres des fichiers inclus.

Pour commencer, créez une nouvelle section en incluant un en-tête [mysqld] puis ajoutez les paramètres dont vous avez besoin pour activer la réplication de groupe, comme illustré dans l’exemple suivant. Notez que ces paramètres sont modifiés à partir des paramètres minimums requis pour la réplication de groupe décrite dans la documentation officielle de MySQL. Le préfixe loose- permet à MySQL de gérer les options qu’il ne reconnaît pas avec grâce et sans échec. Vous devrez bientôt remplir et personnaliser certains de ces paramètres:

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

[mysqld]

# General replication settings
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
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 = ""

Pour expliquer toutes ces options de configuration de manière plus claire, elles ont été divisées en sous-sections suivantes. Veuillez les lire attentivement, car certaines sections vous présentent des choix sur la manière dont vous souhaitez déployer votre groupe de réplication ou nécessitent que vous saisissiez des détails spécifiques à votre propre configuration.

Paramètres de base de la réplication de groupe

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

. . .
# Paramètres généraux de réplication
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
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
. . .

Une exigence particulière pour la réplication de groupe dans MySQL est que les données doivent être stockées dans le moteur de stockage InnoDB. La documentation de MySQL recommande de désactiver explicitement l’utilisation d’autres moteurs de stockage qui pourraient provoquer des erreurs, de manière similaire à la première ligne non commentée de cette section.

Les paramètres restants activent les identifiants de transaction globaux, configurent le journal binaire requis pour la réplication de groupe et configurant SSL pour le groupe. Cette configuration met également en place quelques autres éléments qui facilitent la récupération et le démarrage. Vous n’avez pas besoin de modifier quoi que ce soit dans cette section et elle devrait être identique sur chacun de vos trois serveurs, vous pouvez donc passer à autre chose après l’avoir ajoutée.

Paramètres de réplication de groupe partagés

La deuxième section configure les paramètres partagés pour le groupe. Vous devrez personnaliser cela une fois, puis utiliser les mêmes paramètres sur chacun de vos nœuds. Spécifiquement, vous devez ajouter l’UUID du groupe (que vous avez créé à l’étape précédente), une liste des membres autorisés du groupe et les membres initiaux à contacter pour obtenir les données initiales lors de la rejoindre au groupe.

Définissez le loose-group_replication_group_name sur la valeur UUID que vous avez précédemment générée avec la commande uuidgen. Assurez-vous de placer l’UUID entre une paire de guillemets vides.

Ensuite, définissez loose-group_replication_ip_whitelist sur une liste de toutes les adresses IP de vos serveurs MySQL, séparées par des virgules. Le paramètre loose-group_replication_group_seeds devrait être presque identique à la liste blanche, mais vous devriez ajouter un port de réplication de groupe désigné à la fin de chaque membre. À des fins de ce guide, utilisez le port de réplication de groupe recommandé, 33061:

. . .
# Configuration de groupe de réplication partagé
loose-group_replication_group_name = "168dcb64-7cce-473a-b338-6501f305e561"
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 doit être identique sur chacun de vos serveurs MySQL, alors assurez-vous de la copier soigneusement sur chacun.

Choisir un Primary Unique ou Multi-Primary

Ensuite, vous devez décider de configurer un groupe unique primary ou multi-primary. Dans une configuration unique primary, 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-primary permet à n’importe lequel des membres du groupe d’effectuer des écritures.

Si vous souhaitez configurer un groupe multi-primaire, décommentez les directives loose-group_replication_single_primary_mode et loose-group_replication_enforce_update_everywhere_checks. Cela mettra en place un groupe multi-primaire. Pour un groupe mono-primaire, laissez simplement ces deux lignes commentées :

. . .
# Mode mono-primaire ou multi-primaire ? Décommentez ces deux lignes
# pour le mode multi-primaire, où n'importe quel hôte peut accepter des écritures
#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 après l’avoir fait, vous devrez redémarrer chaque membre de votre groupe MySQL. Pour passer à la nouvelle configuration, vous devrez arrêter chacune des instances MySQL du groupe, démarrer chaque membre avec les nouveaux paramètres, puis réinitialiser la réplication du groupe. Cela n’affectera pas vos données, mais nécessitera une courte période d’arrêt.

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

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

• L’identifiant du serveur
• L’adresse à laquelle se lier
• L’adresse à rapporter aux autres membres
• L’adresse locale de réplication et le port d’écoute

La directive server_id doit être définie sur un numéro unique. Pour le premier membre, définissez-le sur 1 et incrémentez le numéro pour chaque hôte supplémentaire. Définissez bind-address et report_host sur l’adresse IP respective du serveur afin que l’instance MySQL écoute les connexions externes et signale correctement son adresse aux autres hôtes. loose-group_replication_local_address doit également être défini sur l’adresse IP actuelle du serveur avec le port de réplication de groupe (33061), ajouté à l’adresse IP.

À titre d’exemple, voici cette partie de la configuration pour member1 en utilisant son adresse IP d’exemple:

. . .
# Configuration de réplication spécifique à l'hôte
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"

Complétez ce processus sur chacun de vos serveurs MySQL. Voici la configuration pour member2:

. . .
# Configuration de réplication spécifique à l'hôte
server_id = 2
bind-address = "203.0.113.2"
report_host = "203.0.113.2"
loose-group_replication_local_address = "203.0.113.2:33061"

Et voici la configuration pour member3:

. . .
# Configuration de réplication spécifique à l'hôte
server_id = 3
bind-address = "203.0.113.3"
report_host = "203.0.113.3"
loose-group_replication_local_address = "203.0.113.3:33061"

Assurez-vous de mettre à jour chaque adresse IP en surbrillance pour celle du serveur dont vous éditez la configuration.

Lorsque vous avez terminé, vérifiez que les paramètres de réplication partagés 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é. Si vous avez utilisé nano pour éditer le fichier, vous pouvez le faire en appuyant sur CTRL + X, Y, puis ENTRÉE.

Chacun des fichiers de configuration MySQL de vos serveurs contient désormais les directives nécessaires pour amorcer la réplication de groupe MySQL. Pour appliquer les nouveaux paramètres à l’instance MySQL, redémarrez le service sur chaque serveur avec la commande suivante :

sudo systemctl restart mysql

Avec cela, vous pouvez passer à l’activation de l’accès distant en mettant à jour les règles de pare-feu de chaque serveur.

Étape 3 — Mise à jour des règles UFW de chaque serveur

En supposant que vous avez suivi le guide de configuration initiale du serveur comme prérequis, vous aurez configuré un pare-feu sur chacun des serveurs sur lesquels vous avez installé MySQL et activé l’accès pour le profil UFW OpenSSH. Il s’agit d’une mesure de sécurité importante, car ces pare-feu bloquent actuellement les connexions à tous les ports de vos serveurs, sauf pour les connexions ssh présentant des clés qui correspondent à celles figurant dans le fichier authorized_keys de chaque serveur respectif.

Dans le fichier de configuration MySQL, vous avez configuré le service pour écouter les connexions externes sur le port par défaut 3306. Vous avez également défini le port 33061 comme port que les membres doivent utiliser pour la coordination de la réplication.

Sur chacun de vos serveurs membres, vous devez ouvrir l’accès à ces deux ports pour les autres membres de ce groupe afin qu’ils puissent tous communiquer entre eux. Pour ouvrir l’accès à ces ports sur membre1 pour membre2, exécutez les commandes ufw suivantes sur membre1:

sudo ufw allow from member2_server_ip to any port 3306
sudo ufw allow from member2_server_ip to any port 33061

Assurez-vous de modifier member2_server_ip pour refléter l’adresse IP réelle de votre serveur membre2. Ensuite, pour ouvrir les mêmes ports pour membre3, exécutez ces commandes:

sudo ufw allow from member3_server_ip to any port 3306
sudo ufw allow from member3_server_ip to any port 33061

Ensuite, mettez à jour les règles de pare-feu pour vos deux autres serveurs. Exécutez les commandes suivantes sur membre2, en vous assurant de changer les adresses IP pour refléter celles de membre1 et membre3, respectivement:

sudo ufw allow from member1_server_ip to any port 3306
sudo ufw allow from member1_server_ip to any port 33061
sudo ufw allow from member3_server_ip to any port 3306
sudo ufw allow from member3_server_ip to any port 33061

Enfin, exécutez ces deux commandes sur membre3. Encore une fois, assurez-vous d’entrer les bonnes adresses IP pour chaque serveur:

sudo ufw allow from member1_server_ip to any port 3306
sudo ufw allow from member1_server_ip to any port 33061
sudo ufw allow from member2_server_ip to any port 3306
sudo ufw allow from member2_server_ip to any port 33061

Après avoir ajouté ces règles UFW, chacune de vos trois instances MySQL sera autorisée à accéder aux ports utilisés par MySQL sur les deux autres serveurs.

Avec l’accès aux ports MySQL ouverts, vous pouvez maintenant créer un utilisateur de réplication et activer le plugin de réplication de groupe.

Étape 4 — Configuration des utilisateurs de réplication et activation du plugin de réplication de groupe

Pour établir des connexions avec les autres serveurs du groupe de réplication, chaque instance MySQL doit disposer d’un utilisateur de réplication dédié.

Sur chacun de vos serveurs MySQL, connectez-vous à votre instance MySQL avec l’utilisateur administrateur pour démarrer une session interactive :

sudo mysql

Étant donné que chaque serveur aura son propre utilisateur de réplication, vous devez désactiver l’enregistrement binaire pendant le processus de création. Sinon, une fois que la réplication commence, le groupe tenterait de propager l’utilisateur de réplication du serveur principal aux autres serveurs, créant ainsi un conflit avec l’utilisateur de réplication déjà en place. Exécutez la commande suivante à partir de l’invite MySQL sur chacun de vos serveurs :

SET SQL_LOG_BIN=0;

Vous pouvez maintenant exécuter une instruction CREATE USER pour créer votre utilisateur de réplication. Exécutez la commande suivante, qui crée un utilisateur nommé repl. Cette commande spécifie que l’utilisateur de réplication doit se connecter en utilisant SSL. Assurez-vous également d’utiliser un mot de passe sécurisé à la place de password lors de la création de cet utilisateur de réplication :

CREATE USER 'repl'@'%' IDENTIFIED BY 'password' REQUIRE SSL;

Ensuite, accordez les privilèges de réplication au nouvel utilisateur sur le serveur :

GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';

Puis actualisez les privilèges pour implémenter les modifications :

FLUSH PRIVILEGES;

Ensuite, réactivez l’enregistrement binaire pour reprendre les opérations normales :

SET SQL_LOG_BIN=1;

Ensuite, définissez le canal group_replication_recovery pour utiliser votre nouvel utilisateur de réplication et son mot de passe associé. Chaque serveur utilisera ensuite ces informations d’identification pour s’authentifier auprès du groupe :

CHANGE REPLICATION SOURCE TO SOURCE_USER='repl', SOURCE_PASSWORD='password' FOR CHANNEL 'group_replication_recovery';

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

Avec l’utilisateur de réplication en place, vous pouvez activer le plugin group_replication pour préparer l’initialisation du groupe :

INSTALL PLUGIN group_replication SONAME 'group_replication.so';

Vérifiez que le plugin est actif en exécutant la commande suivante :

SHOW PLUGINS;

Le plugin group_replication apparaîtra en bas de la liste car c’est le plugin le plus récemment ajouté :

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

Cette sortie confirme que le plugin a été chargé et est actuellement actif. Avant de passer à l’étape suivante, assurez-vous d’avoir exécuté chaque commande de cette section sur chacune de vos instances MySQL.

Étape 5 — Démarrage de la réplication de groupe

Maintenant que chaque serveur MySQL a un utilisateur de réplication configuré et que le plugin de réplication de groupe est activé, vous pouvez commencer à monter votre groupe.

Amorçage du premier nœud

Pour démarrer le groupe, suivez les étapes suivantes sur un seul membre du groupe. À des fins de démonstration, ce guide effectuera ces étapes sur membre1.

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 lorsqu’ils rejoignent initialement le groupe. En raison de cela, vous devez utiliser une procédure légèrement différente pour démarrer le membre initial du groupe afin qu’il sache de ne pas attendre ces informations des autres membres de sa liste d’amorçage.

Si défini, la variable group_replication_bootstrap_group indique à un membre qu’il ne doit pas s’attendre à recevoir des informations de ses pairs et qu’il doit plutôt établir un nouveau groupe et s’élire lui-même membre principal. Vous pouvez activer cette variable avec la commande suivante :

SET GLOBAL group_replication_bootstrap_group=ON;

Ensuite, vous pouvez démarrer la réplication pour le membre initial du groupe :

START GROUP_REPLICATION;

Ensuite, vous pouvez réinitialiser la variable group_replication_bootstrap_group à OFF, car la seule situation où cela est approprié est lorsqu’il n’y a pas de membres de groupe existants :

SET GLOBAL group_replication_bootstrap_group=OFF;

Le groupe sera démarré avec ce serveur comme seul membre. Vérifiez cela en vérifiant les entrées dans la table replication_group_members dans la base de données performance_schema :

SELECT * FROM performance_schema.replication_group_members;

Cette requête renverra une seule ligne représentant l’hôte actuel :

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

La valeur ONLINE pour MEMBER_STATE indique que ce nœud est entièrement opérationnel au sein du groupe.

Ensuite, créez une base de données de test et une table avec des données d’exemple. Une fois que d’autres membres seront ajoutés à ce groupe, ces données seront automatiquement répliquées vers eux.

Commencez par créer une base de données d’exemple nommée playground :

CREATE DATABASE playground;

Ensuite, créez un exemple de table nommée equipment dans la base de données playground avec la commande suivante :

CREATE TABLE playground.equipment ( 
id INT NOT NULL AUTO_INCREMENT,
type VARCHAR(50),
quant INT,
color VARCHAR(25),
PRIMARY KEY(id)
);

Cette table contient les quatre colonnes suivantes :

• id : Cette colonne contiendra des valeurs entières qui s’incrémentent automatiquement, ce qui signifie que vous n’aurez pas à spécifier les valeurs pour cette colonne lorsque vous chargez la table avec des données d’exemple
• type : Cette colonne contiendra des valeurs de chaîne de caractères décrivant le type d’équipement de terrain de jeu représenté par la ligne
• quant : Cette colonne contiendra des valeurs entières pour représenter la quantité du type donné d’équipement de terrain de jeu
• color : Cette colonne contiendra des valeurs de chaîne de caractères spécifiant la couleur de l’équipement donné

Aussi, notez que la colonne id est spécifiée comme la clé primaire de cette table. Dans MySQL, chaque table répliquée à un groupe doit avoir une colonne désignée comme la clé primaire de la table.

Enfin, exécutez la commande suivante pour insérer une ligne de données dans la table :

INSERT INTO playground.equipment (type, quant, color) VALUES ("slide", 2, "blue");

Interrogez la table pour vous assurer que les données ont été saisies correctement :

SELECT * FROM playground.equipment;

Output
+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+
1 row in set (0.00 sec)

Après avoir vérifié que ce serveur est membre du groupe et qu’il a des capacités d’écriture, les autres serveurs peuvent rejoindre le groupe.

Démarrage des nœuds restants

Ensuite, lancez la réplication de groupe sur member2. Comme vous avez déjà un membre actif, vous n’avez pas besoin de démarrer le groupe, et ce membre peut rejoindre directement:

START GROUP_REPLICATION;

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

START GROUP_REPLICATION;

Vérifiez à nouveau la liste des membres sur l’un des trois serveurs. Cette fois, il y aura trois serveurs répertoriés dans la sortie:

SELECT * FROM performance_schema.replication_group_members;

Output
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 13324ab7-1b01-11e7-9dd1-22b78adaa992 | 203.0.113.1  |        3306 | ONLINE       | PRIMARY     | 8.0.28         | XCom                       |
| group_replication_applier | 1ae4b211-1b01-11e7-9d89-ceb93e1d5494 | 203.0.113.2  |        3306 | ONLINE       | SECONDARY   | 8.0.28         | XCom                       |
| group_replication_applier | 157b597a-1b01-11e7-9d83-566a6de6dfef | 203.0.113.3  |        3306 | ONLINE       | SECONDARY   | 8.0.28         | XCom                       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
3 rows in set (0.00 sec)

Tous les membres doivent avoir une valeur MEMBER_STATE de ONLINE. Pour un nouveau groupe, si l’un des nœuds est répertorié comme RECOVERING pendant plus de quelques secondes, 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 s’est mal passé.

Ensuite, 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.

Étape 6 — Test des capacités d’écriture des nouveaux membres du groupe

Ensuite, vous pouvez essayer d’écrire dans la base de données à partir de vos nouveaux membres de groupe de réplication. Que cela réussisse ou non dépend de savoir si vous avez choisi de configurer un groupe avec un seul maître ou plusieurs maîtres.

Tests d’écriture dans un environnement à primary unique

Dans un groupe à primary unique, vous devriez vous attendre à ce que toutes les opérations d’écriture provenant d’un serveur non primaire soient rejetées pour des raisons de cohérence. Vous pouvez trouver le primary actuel à tout moment en exécutant la requête suivante sur n’importe quel membre de votre groupe de réplication :

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 un MEMBER_ID que vous pouvez faire correspondre à un hôte en interrogeant la liste des membres du groupe comme vous l’avez fait précédemment :

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)

Comme l’indique cet exemple de sortie, l’hôte à 203.0.113.1 – member1 – est actuellement le serveur principal. Si vous tentez d’écrire dans la base de données à partir d’un autre membre, l’opération échouera :

INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");

Output
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement

Cela est attendu car le groupe est actuellement configuré avec un seul primary capable d’écriture. Si le serveur principal rencontre des problèmes et quitte le groupe, le groupe élira automatiquement un nouveau membre pour être le primary et accepter des écritures.

Tests d’écriture dans un environnement à primary multiple

Pour les groupes configurés en orientation à primary multiple, tout membre devrait pouvoir valider des écritures dans la base de données.

Vous pouvez vérifier que votre groupe fonctionne en mode multi-primaire en vérifiant à nouveau la valeur de la variable group_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 primaire désigné et que n’importe quel membre devrait être capable d’accepter des écritures.

Testez ceci sur member2 en essayant d’écrire des données dans la table equipment :

INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");

Output
Query OK, 1 row affected (0.00 sec)

member2 a effectué l’opération d’écriture sans erreur.

Sur member3, exécutez la requête suivante pour vérifier si 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 de member2 a été répliquée avec succès.

Maintenant, testez les capacités d’écriture sur member3 en exécutant la déclaration INSERT suivante :

INSERT INTO playground.equipment (type, quant, color) VALUES ("seesaw", 3, "green");

Output
Query OK, 1 row affected (0.02 sec)

De retour sur member1, vérifiez 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 direction et que chaque membre est capable d’effectuer des opérations d’écriture.

Étape 7 — Remise en service du groupe

Une fois le groupe amorcé, les membres individuels peuvent rejoindre et partir sans affecter la disponibilité, tant qu’il y a suffisamment de membres pour élire les serveurs principaux. Cependant, si certaines modifications de configuration sont apportées (comme passer d’environnements à serveur unique à multi-primaire), ou si tous les membres du groupe partent, vous devrez peut-être re-amorcer le groupe de la même manière que vous l’avez fait initialement.

Sur member1, définissez la variable group_replication_bootstrap_group sur ON:

SET GLOBAL GROUP_REPLICATION_BOOTSTRAP_GROUP=ON;

Ensuite, initialisez le groupe:

START GROUP_REPLICATION;

Suite à cela, vous pouvez rétablir la variable group_replication_bootstrap_group sur OFF:

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 tout membre supplémentaire:

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 démarrer le groupe à nouveau lorsque nécessaire.

Étape 8 — Rejoindre automatiquement un groupe lors du 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 modifier légèrement le fichier de configuration.

Le paramètre décrit dans cette étape est utile lorsque vous souhaitez que les membres rejoignent automatiquement au démarrage. Cependant, il y a quelques points dont vous devez être conscient. Premièrement, ce paramètre n’affecte que le démarrage de l’instance MySQL elle-même. Si le membre est retiré du groupe en raison de problèmes de délai d’expiration, mais que l’instance MySQL reste en ligne, le membre ne rejoindra pas automatiquement.

Deuxièmement, avoir ce paramètre activé lors du premier amorçage d’un groupe peut être nuisible. Lorsqu’il n’y a pas de groupe existant à rejoindre, le processus MySQL prendra beaucoup de temps à démarrer car il tentera de contacter d’autres membres inexistants pour s’initialiser. Seulement après un délai prolongé, il abandonnera et démarrera normalement. Ensuite, vous devrez utiliser la procédure décrite ci-dessus pour amorcer le groupe.

Avec les mises en garde ci-dessus à l’esprit, si vous souhaitez configurer les nœuds pour rejoindre automatiquement le groupe lorsque MySQL démarre, ouvrez le fichier de configuration principal de MySQL:

sudo nano /etc/mysql/my.cnf

À l’intérieur, trouvez la variable loose-group_replication_start_on_boot et définissez-la sur ON:

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

Enregistrez et fermez le fichier lorsque vous avez terminé. Le membre devrait automatiquement tenter de rejoindre le groupe la prochaine fois que son instance MySQL sera démarrée.

Conclusion

En complétant ce tutoriel, vous avez appris comment configurer la réplication de groupe MySQL entre trois serveurs Ubuntu 20.04. Pour les configurations à primaire unique, les membres éliront automatiquement un primaire capable d’écrire lorsque nécessaire. Pour les groupes multi-primaires, n’importe quel membre peut effectuer des écritures et des mises à jour.

La réplication de groupe offre une topologie de réplication flexible qui permet aux membres de rejoindre ou de quitter à volonté tout en garantissant simultanément la cohérence des données et l’ordonnancement des messages. La réplication de groupe MySQL peut être un peu plus complexe à configurer, mais elle offre des capacités qui ne sont pas possibles avec une réplication traditionnelle.