MySQL Group Replication (abrégé MGR) est une solution entièrement nouvelle pour haute disponibilité et haute extensibilité lancée par MySQL en décembre 2016. MGR est une solution de haute disponibilité et d'extensibilité pour les bases de données introduite dans la version 5.7.17 de MySQL, fournie sous forme de plugin. Elle réalise une cohérence finale des données dans un environnement distribué et offre un service de cluster MySQL hautement disponible, extensible et fiable.
La réplication de groupe MySQL existe en mode primaire unique et multi-primaire. Si l'on n'utilise que le maître-esclave de MySQL, la technologie de réplication maître-esclave ne résout que le problème de synchronisation des données. Si le maître tombe en panne, cela signifie que l'administrateur de base de données doit intervenir, et le système d'application pourrait avoir besoin de modifier l'adresse de connexion à la base de données ou de redémarrer pour fonctionner. La réplication de groupe, au niveau de la base de données, garantit que tant que la majorité des hôtes du cluster sont disponibles, le service est disponible. Autrement dit, dans un cluster de 3 serveurs, 1 seul serveur est autorisé à tomber en panne.
Comme indiqué sur le schéma : S1 à S5 sont respectivement des serveurs de base de données, les 5 bases de données forment un cluster, S1 est le nœud principal (maître), qui est un nœud en lecture/écriture, les 4 autres services de base de données sont des nœuds secondaires, qui sont des nœuds en lecture seule. Lorsque le nœud maître S1 tombe en panne, l'un des nœuds secondaires sera élu comme nouveau nœud maître (peut-être S2), puis S2 devient le nœud principal en lecture/écriture, et S3 à S5 deviennent des nœuds secondaires en lecture seule.
- Caractéristiques de la réplication de groupe MGR
- Cohérence élevée : implémentée basée sur le protocole Paxos distribué pour garantir la cohérence des données ;
- Tolérance aux pannes élevée : mécanisme de détection automatique, peut continuer à fonctionner tant que la majorité des nœuds ne sont pas en panne, avec un mécanisme intégré de protection contre la partition du réseau ;
- Extensibilité élevée : l'ajout et la suppression de nœuds mettent automatiquement à jour les informations de membres du groupe, lorsqu'un nouveau nœud rejoint, il synchronise automatiquement les données incrémentielles à partir d'autres nœuds jusqu'à ce que ses données soient cohérentes avec celles des autres nœuds ;
- Flexibilité élevée : propose un mode primaire unique et un mode multi-primaire, le mode primaire unique peut élire automatiquement un nouveau maître en cas de panne du maître principal, toutes les écritures sont effectuées sur le nœud principal, le mode multi-primaire prend en charge les écritures sur plusieurs nœuds.
- Principe de la réplication de groupe MGR La réplication de groupe est une technologie qui peut être utilisée pour réaliser des systèmes tolérants aux pannes. Un groupe de réplication est un cluster de serveurs qui interagissent mutuellement par passage de messages. La couche de communication fournit des mécanismes de garantie tels que les messages atomiques et l'interaction d'informations totalement ordonnées, réalisant des mises à jour multi-maîtres basées sur le protocole de réplication.
Un groupe de réplication est composé de plusieurs serveurs membres, et chaque serveur membre peut exécuter indépendamment des transactions. Cependant, toutes les transactions en lecture/écriture (RW) ne sont soumises qu'après une détection de réussite des conflits. Les transactions en lecture seule (RO) n'ont pas besoin de détection de conflits et peuvent être soumises immédiatement. En d'autres termes, pour toute transaction RW, l'opération de soumission n'est pas décidée par le serveur principal, mais par le groupe qui décide si la transaction est soumise. Plus précisément, sur le serveur principle, lorsque la transaction est prête à être soumise, le serveur diffuse les valeurs écrites (lignes modifiées) et l'ensemble d'écriture correspondant (identifiants uniques des lignes mises à jour). Ensuite, un ordre global est établi pour cette transaction. Finalement, cela signifie que tous les serveurs membres reçoivent les mêmes transactions dans le même ordre. Par conséquent, tous les serveurs membres appliquent les mêmes modifications dans le même ordre, garantissant la cohérence au sein du groupe.
Workflow du protocole de réplication de groupe MySQL :
À noter : La réplication de groupe MGR est une solution de réplication sans partage (share-nothing), où chaque serveur membre possède sa propre copie complète des données.
Limites de MGR
- Le moteur de stockage doit être InnoDB, c'est-à-dire qu'il ne prend en charge que les tables InnoDB, et chaque table doit avoir une clé primaire, utilisée pour la détection de conflits de l'ensemble d'écriture ;
- Chaque table doit fournir une clé primaire ;
- Prend uniquement en charge IPv4, avec des exigences réseau élevées ;
- La fonctionnalité GTID doit être activée, et le format du journal binaire doit être défini sur ROW, pour l'élection du maître et l'ensemble d'écriture ;
- COMMIT peut échouer, similaire aux scénarios d'échec du niveau d'isolation des transactions snapshot ;
- Actuellement, un groupe de cluster MGR prend en charge jusqu'à 9 nœuds maximum ;
- Ne prend pas en charge les clés étrangères et les fonctionnalités de point de sauvegarde, ne peut pas effectuer de détection de contraintes globales ou de rollback partiel ;
- Le journal binaire binlog ne prend pas en charge les sommes de contrôle des événements de réplication ;
- En mode multi-primaire (c'est-à-dire multi-écriture), le niveau d'isolation des transactions SERIALIZABLE n'est pas pris en charge ;
- En mode multi-primaire, les contraintes de clés étrangères en cascade ne sont pas entièrement prises en charge ;
- En mode multi-primaire, l'exécution concurrente de DDL sur le même objet de base de données sur différents nœuds n'est pas prise en charge (si des transactions RW concurrantes sur la même ligne sont exécutées sur différents nœuds, la transaction lancée en dernier échouera).
- Deux modes de fonctionnement de la réplication de groupe -> En mode primaire unique, la réplication de groupe a une fonction d'élection automatique du maître, un seul serveur membre accepte les mises à jour de données à la fois. Dans le mode mono-écriture, seul un nœud du groupe peut être en lecture/écriture, les autres nœuds ne peuvent que lire. Pour le déploiement du groupe, il faut d'abord démarrer le nœud primaire (le nœud qui peut lire et écrire, read_only = 0 indique que ce nœud peut lire et écrire), puis démarrer les autres nœuds et les ajouter successivement au groupe. Les autres nœuds synchroniseront automatiquement les changements du nœud primaire, puis se mettront eux-mêmes en mode lecture seule (read_only = 1 indique un nœud en lecture seule). Lorsque le nœud primaire tombe en panne ou est hors ligne, à condition que la majorité des nœuds soient en ligne, une élection est initiée au sein du groupe pour sélectionner le prochain nœud disponible et le promouvoir en nœud primaire. L'élection du primaire se fait en fonction de l'UUID des nœuds restants en vie, triés par ordre alphabétique, c'est-à-dire que les nœuds restants sont triés par ordre alphabétique d'UUID, et le nœud classé en premier est sélectionné comme nouveau nœud primaire. -> En mode multi-primaire, tous les serveurs membres peuvent accepter simultanément les mises à jour. Tous les ordinateurs du groupe sont des nœuds primaires, peuvent effectuer des opérations de lecture et d'écriture simultanément, et les données sont finalement cohérentes.
Selon ma compréhension : Mode primaire unique : comporte un processus d'élection supplémentaire par rapport au mode multi-primaire, le premier nœud démarrant le cluster est le maître, les nœuds rejoignants sont des suiveurs (également appelés esclaves), seul le maître a des permissions de lecture/écriture, les autres suiveurs désactivent automatiquement leurs permissions lors de leur ajout au groupe. Si le maître tombe en panne, les autres serveurs éliront un nouveau maître en fonction de l'UUID et d'une valeur (similaire à un poids). Chaque élection rétablit les permissions.
Mode multi-primaire : lorsque tous les serveurs rejoignent le groupe, toutes les permissions de lecture/écriture sont libérées, tout le monde peut lire et écrire, mais ne peut modifier que des lignes de données différentes. Si un serveur rejoignant le cluster modifie une ligne de données, les serveurs précédents ne peuvent plus modifier cette ligne de données ; s'ils tentent de le faire, la transaction est annulée. Les serveurs rejoignants plus tard peuvent modifier les données déjà modifiées par les serveurs ayant rejoint le cluster plus tôt.
4. Voici le processus de déploiement d'un environnement de cluster MGR en mode primaire unique (le mode multi-primaire est omis et sera mis à jour ultérieurement...)
4.1 Préparation de l'environnement
Trois serveurs
172.16.60.211 NOEUD-MGR1 server_id=1
172.16.60.212 NOEUD-MGR2 server_id=2
172.16.60.213 NOEUD-MGR3 server_id=3
[root@NOEUD-MGR1 ~]# cat /etc/redhat-release
CentOS Linux release 7.5.1804 (Core)
Pour faciliter l'expérience, désactivez le pare-feu sur tous les nœuds
[root@NOEUD-MGR1 ~]# systemctl stop firewalld
[root@NOEUD-MGR1 ~]# firewall-cmd --state
not running
[root@NOEUD-MGR1 ~]# cat /etc/sysconfig/selinux |grep "SELINUX=disabled"
SELINUX=disabled
[root@NOEUD-MGR1 ~]# setenforce 0
setenforce: SELinux is disabled
[root@NOEUD-MGR1 ~]# getenforce
Disabled
Un point crucial à noter : il faut s'assurer que les noms d'hôte des différents nœuds MySQL sont différents et que chaque membre peut être trouvé via le nom d'hôte !
Il est donc nécessaire d'effectuer une liaison de nom d'hôte dans /etc/hosts de chaque nœud, sinon l'ajout de nœuds au groupe échouera ! L'erreur RECOVERING sera signalée !
[root@NOEUD-MGR1 ~]# cat /etc/hosts
........
172.16.60.211 NOEUD-MGR1
172.16.60.212 NOEUD-MGR2
172.16.60.213 NOEUD-MGR3
4.2 Installation de MySQL 5.7 sur les trois nœuds (l'installation peut se faire via binaire, ce tutoriel utilise yum)
<em>Installation du référentiel yum MySQL
[root@NOEUD-MGR1 ~]# yum localinstall https://dev.mysql.com/get/mysql57-community-release-el7-8.noarch.rpm
Installation de MySQL 5.7
[root@NOEUD-MGR1 ~]# yum install -y mysql-community-server
Démarrage du serveur MySQL et du démarrage automatique de MySQL
[root@NOEUD-MGR1 ~]# systemctl start mysqld.service
[root@NOEUD-MGR1 ~]# systemctl enable mysqld.service
Configuration du mot de passe de connexion
Depuis MySQL 5.7, l'utilisation d'un mot de passe vide n'est pas autorisée pour la première connexion ! Pour renforcer la sécurité, le système génère un mot de passe aléatoire pour que l'administrateur puisse se connecter pour la première fois,
ce mot de passe est enregistré dans le fichier /var/log/mysqld.log, la commande suivante permet de consulter ce mot de passe :
[root@NOEUD-MGR1 ~]# cat /var/log/mysqld.log|grep 'A temporary password'
2022-11-17T11:21:34.381573Z 1 [Note] A temporary password is generated for root@localhost: TaN.k:*Qw2xs
Utilisez le mot de passe TaN.k:*Qw2xs vu ci-dessus pour vous connecter à mysql et réinitialiser le mot de passe en 123456
[root@NOEUD-MGR1 ~]# mysql -p #saisissez le mot de passe par défaut : TaN.k:*Qw2xs
.............
mysql> set global validate_password_policy=0;
Query OK, 0 rows affected (0.00 sec)
mysql> set global validate_password_length=1;
Query OK, 0 rows affected (0.00 sec)
mysql> set password=password("123456");
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)
Vérification de la version de mysql
[root@NOEUD-MGR1 ~]# mysql -p123456
........
mysql> select version();
+-----------+
| version() |
+-----------+
| 5.7.24 |
+-----------+
1 row in set (0.00 sec)
=====================================================================
Conseil
Après l'installation par défaut de mysql5.7, l'exécution d'instructions peut générer une erreur :
ERROR 1819 (HY000): Your password does not satisfy the current policy requirements
Cette erreur est liée à la stratégie de sécurité des mots de passe de mysql validate_password_policy, validate_password_policy peut prendre les valeurs 0, 1, 2 :
Solution :
set global validate_password_policy=0; //complexité de mot de passe minimale
set global validate_password_length=1; //définition de la longueur minimale du mot de passe</em>
4.3 Installation et configuration des informations MGR (chaque nœud doit être configuré)
1) Configuration des informations de réplication de groupe sur tous les nœuds
Nœud NOEUD-MGR01
[root@NOEUD-MGR1 ~]# cp /etc/my.cnf /etc/my.cnf.bak
[root@NOEUD-MGR1 ~]# >/etc/my.cnf
[root@NOEUD-MGR1 ~]# vim /etc/my.cnf
[mysqld]
datadir = /var/lib/mysql
socket = /var/lib/mysql/mysql.sock
symbolic-links = 0
log-error = /var/log/mysqld.log
pid-file = /var/run/mysqld/mysqld.pid
#Cadre de réplication
server_id=1
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_checksum=NONE
log_bin=binlog
log_slave_updates=ON
binlog_format=ROW
master_info_repository=TABLE
relay_log_info_repository=TABLE
#Paramètres de réplication de groupe
#Le serveur doit collecter l'ensemble d'écriture pour chaque transaction et le coder en haché en utilisant l'algorithme XXHASH64
transaction_write_set_extraction=XXHASH64
#Informez le plugin de rejoindre ou de créer un groupe nommé, UUID
loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
#Le plugin ne démarre pas automatiquement la réplication de groupe au démarrage du serveur, pour éviter de démarrer automatiquement un deuxième groupe avec le même nom, il est donc défini sur OFF.
loose-group_replication_start_on_boot=off
#Informez le plugin d'utiliser l'adresse IP et le port 24901 pour recevoir les connexions entrantes d'autres membres du groupe
loose-group_replication_local_address="172.16.60.211:24901" //écrivez ici votre propre adresse IP et le port utilisé par MGR
#Lors du démarrage d'un serveur de groupe, les serveurs de départ, les serveurs rejoignant le groupe doivent se connecter à ces adresses IP et ports ; d'autres serveurs rejoignant le groupe doivent être approuvés par les membres du groupe
loose-group_replication_group_seeds="172.16.60.211:24901,172.16.60.212:24901,172.16.60.213:24901" //ce sont les adresses IP + ports de tous les membres du groupe
loose-group_replication_bootstrap_group=off
report_host=172.16.60.211 //votre adresse IP
report_port=3306 //le port de la base de données
Après la configuration ci-dessus, copiez le fichier /etc/my.cnf du nœud NOEUD-MGR1 vers les deux autres nœuds
[root@NOEUD-MGR1 ~]# rsync -e "ssh -p22" -avpgolr /etc/my.cnf root@172.16.60.212:/etc/
[root@NOEUD-MGR1 ~]# rsync -e "ssh -p22" -avpgolr /etc/my.cnf root@172.16.60.213:/etc/
Sur les 3 nœuds MGR, seuls les paramètres server_id, loose-group_replication_local_address et report_host sont différents, les autres restent identiques.
Une fois la copie terminée, modifiez respectivement les fichiers /etc/my.cnf des nœuds NOEUD-MGR2 et NOEUD-MGR3 pour les trois paramètres server_id, loose-group_replication_local_address et report_host
2) Après configuration, redémarrez successivement les trois bases de données, installez le plugin MGR et configurez le compte de réplication (tous les nœuds MGR doivent exécuter)
[root@NOEUD-MGR1 ~]# systemctl restart mysqld
[root@NOEUD-MGR1 ~]# mysql -p123456
.............
mysql> INSTALL PLUGIN group_replication SONAME 'group_replication.so';
Query OK, 0 rows affected (0.13 sec)
mysql> SET SQL_LOG_BIN=0;
Query OK, 0 rows affected (0.00 sec)
mysql> CREATE USER repl@'%' IDENTIFIED BY 'repl';
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT REPLICATION SLAVE ON *.* TO repl@'%';
Query OK, 0 rows affected (0.00 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
mysql> SET SQL_LOG_BIN=1;
Query OK, 0 rows affected (0.00 sec)
mysql> CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='repl' FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.21 sec)
4.4 Démarrage du mode MGR primaire unique
1) Démarrage de MGR, exécutez sur le nœud principal (172.16.60.11)
[root@NOEUD-MGR1 ~]# mysql -p123456
...............
mysql> SET GLOBAL group_replication_bootstrap_group=ON;
Query OK, 0 rows affected (0.00 sec)
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (2.31 sec)
mysql> SET GLOBAL group_replication_bootstrap_group=OFF;
Query OK, 0 rows affected (0.00 sec)
Vérification des informations du groupe MGR
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| group_replication_applier | 8769f936-3e51-11e9-acaa-005056ac6820 | 172.16.60.211 | 3306 | ONLINE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
1 row in set (0.01 sec)
2) Ajout d'autres nœuds au cluster MGR, exécutez sur les nœuds secondaires (172.16.60.212, 172.16.60.213)
[root@NOEUD-MGR2 ~]# mysql -p123456
................
mysql> START GROUP_REPLICATION;
ERROR 3092 (HY000): The server is not configured properly to be an active member of the group. Please see more details on error log.
Consultation du journal:
[root@NOEUD-MGR2 ~]# tail -2000 /var/log/mysqld.log
.....................
.....................
2019-03-04T09:11:30.683714Z 0 [ERROR] Plugin group_replication reported: 'This member has more executed transactions than those present in the group. Local transactions: 87135ebb-3e51-11e9-8931-005056880888:1-2 > Group transactions: 851d03bb-3e51-11e9-8f8d-00505688047c:1-2,
8769f936-3e51-11e9-acaa-005056ac6820:1-2,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-4'
2019-03-04T09:11:30.683817Z 0 [Warning] Plugin group_replication reported: 'The member contains transactions not present in the group. It is only allowed to join due to group_replication_allow_local_disjoint_gtids_join option'
Solution:
mysql> set global group_replication_allow_local_disjoint_gtids_join=ON;
Query OK, 0 rows affected, 1 warning (0.00 sec)
Puis continuez à rejoindre le cluster MGR
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected, 1 warning (5.14 sec)
3) Consultation à nouveau des informations du groupe MGR (peut être consulté sur les trois nœuds MGR)
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| group_replication_applier | 851d03bb-3e51-11e9-8f8d-00505688047c | 172.16.60.212 | 3306 | RECOVERING |
| group_replication_applier | 87135ebb-3e51-11e9-8931-005056880888 | 172.16.60.213 | 3306 | RECOVERING |
| group_replication_applier | 8769f936-3e51-11e9-acaa-005056ac6820 | 172.16.60.211 | 3306 | ONLINE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
3 rows in set (0.00 sec)
On constate que les deux nouveaux nœuds NOEUD-MGR2 et NOEUD-MGR3 ont un état RECOVERING dans le cluster !
Consultation du journal
[root@NOEUD-MGR3 ~]# tail -2000 /var/log/mysqld.log
.....................
.....................
2019-03-04T09:15:35.146740Z 734 [ERROR] Slave I/O for channel 'group_replication_recovery': Got fatal error 1236 from master when
reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has
purged binary logs containing GTIDs that the slave requires.', Error_code: 1236
Solution:
Connectez-vous au maître 172.16.60.211, consultez le GTID purgé :
[root@NOEUD-MGR1 ~]# mysql -p123456
....................
mysql> show global variables like 'gtid_purged';
+---------------+------------------------------------------+
| Variable_name | Value |
+---------------+------------------------------------------+
| gtid_purged | 8769f936-3e51-11e9-acaa-005056ac6820:1-2 |
+---------------+------------------------------------------+
1 row in set (0.00 sec)
Ensuite, exécutez la commande suivante sur les deux bases de données esclaves 172.16.60.212 et 172.16.60.213, c'est-à-dire sauter ce GTID :
mysql> STOP GROUP_REPLICATION;
Query OK, 0 rows affected (10.14 sec)
mysql> reset master;
Query OK, 0 rows affected (0.06 sec)
mysql> set global gtid_purged = '8769f936-3e51-11e9-acaa-005056ac6820:1-2';
Query OK, 0 rows affected (0.24 sec)
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected, 1 warning (3.49 sec)
Consultez à nouveau les informations du groupe MGR (peut être consulté sur les trois nœuds MGR),
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| group_replication_applier | 851d03bb-3e51-11e9-8f8d-00505688047c | 172.16.60.212 | 3306 | ONLINE |
| group_replication_applier | 87135ebb-3e51-11e9-8931-005056880888 | 172.16.60.213 | 3306 | ONLINE |
| group_replication_applier | 8769f936-3e51-11e9-acaa-005056ac6820 | 172.16.60.211 | 3306 | ONLINE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
3 rows in set (0.00 sec)
Comme on peut le voir ci-dessus : les trois nœuds MGR ont un état en ligne, et le nœud principal est 172.16.60.211, seul le nœud principal peut écrire, les deux autres nœuds MGR sont en lecture seule, le déploiement du mode primaire unique MGR a réussi.
==============================================================================
Vérification de la synchronisation des données et des opérations de lecture/écriture en mode primaire unique MGR :
Créez d'abord une base de données de test sur le nœud maître 172.16.60.211
[root@NOEUD-MGR1 ~]# mysql -p123456
..............
mysql> CREATE DATABASE test_db CHARACTER SET utf8 COLLATE utf8_general_ci;
Query OK, 1 row affected (0.06 sec)
mysql> use test_db;
Database changed
mysql> create table if not exists test_table (id int(10) PRIMARY KEY AUTO_INCREMENT,name varchar(50) NOT NULL);
Query OK, 0 rows affected (0.24 sec)
mysql> insert into test_db.test_table values(1,"user1"),(2,"user2"),(3,"user3"),(4,"user4");
Query OK, 4 rows affected (0.13 sec)
Records: 4 Duplicates: 0 Warnings: 0
mysql> select * from test_db.test_table;
+----+-------+
| id | name |
+----+-------+
| 1 | user1 |
| 2 | user2 |
| 3 | user3 |
| 4 | user4 |
+----+-------+
4 rows in set (0.00 sec)
Ensuite, consultez les données sur les deux autres nœuds esclaves 172.16.60.212 et 172.16.60.213, les données du maître ont déjà été synchronisées sur les deux esclaves
[root@NOEUD-MGR2 ~]# mysql -p123456
..................
mysql> select * from test_db.test_table;
+----+-------+
| id | name |
+----+-------+
| 1 | user1 |
| 2 | user2 |
| 3 | user3 |
| 4 | user4 |
+----+-------+
4 rows in set (0.00 sec)
Ensuite, essayez de mettre à jour les données sur les deux bases esclaves, la mise à jour échoue ! Car c'est le mode primaire unique MGR, les esclaves ne peuvent effectuer que des opérations de lecture, pas d'écriture !
[root@NOEUD-MGR3 ~]# mysql -p123456
.................
mysql> select * from test_db.test_table;
+----+-------+
| id | name |
+----+-------+
| 1 | user1 |
| 2 | user2 |
| 3 | user3 |
| 4 | user4 |
+----+-------+
4 rows in set (0.00 sec)
mysql> delete from test_db.test_table where id>3;
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement
mysql> insert into test_db.test_table values(11,"paris"),(12,"london"),(13,"berlin");
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement
Seul le maître peut effectuer des opérations d'écriture
[root@NOEUD-MGR1 ~]# mysql -p123456
..............
mysql> insert into test_db.test_table values(11,"paris"),(12,"london"),(13,"berlin");
Query OK, 3 rows affected (0.15 sec)
Records: 3 Duplicates: 0 Warnings: 0
mysql> select * from test_db.test_table;
+----+--------+
| id | name |
+----+--------+
| 1 | user1 |
| 2 | user2 |
| 3 | user3 |
| 4 | user4 |
| 11 | paris |
| 12 | london |
| 13 | berlin |
+----+--------+
7 rows in set (0.00 sec)
4.5 Basculement de défaillance
1) Mode primaire unique
Si le nœud principal tombe en panne, un nouveau nœud maître sera sélectionné parmi les nœuds esclaves par le processus d'élection. Simulons une défaillance comme suit :
Arrêtez le service mysqld du maître NOEUD-MGR1
[root@NOEUD-MGR1 ~]# systemctl stop mysqld
Ensuite, consultez les informations du groupe MGR sur d'autres nœuds. Par exemple, consultez sur le nœud NOEUD-MGR2
[root@NOEUD-MGR2 ~]# mysql -p123456
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| group_replication_applier | 851d03bb-3e51-11e9-8f8d-00505688047c | 172.16.60.212 | 3306 | ONLINE |
| group_replication_applier | 87135ebb-3e51-11e9-8931-005056880888 | 172.16.60.213 | 3306 | ONLINE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
2 rows in set (0.00 sec)
Essayez de mettre à jour les données sur le nœud NOEUD-MGR2
mysql> select * from test_db.test_table;
+----+--------+
| id | name |
+----+--------+
| 1 | user1 |
| 2 | user2 |
| 3 | user3 |
| 4 | user4 |
| 11 | paris |
| 12 | london |
| 13 | berlin |
+----+--------+
7 rows in set (0.00 sec)
mysql> delete from test_db.test_table where id>10;
Query OK, 3 rows affected (0.06 sec)
Comme indiqué ci-dessus, après que le maître précédent NOEUD-MGR1 soit tombé en panne, le nœud NOEUD-MGR2 peut effectuer des opérations d'écriture, ce qui indique que le nœud NOEUD-MGR2 a été élu comme nouveau nœud principal.
Alors, le nœud NOEUD-MGR3 est toujours un nœud esclave, ne peut que lire, pas écrire
[root@NOEUD-MGR3 ~]# mysql -p123456
..............
mysql> select * from test_db.test_table;
+----+-------+
| id | name |
+----+-------+
| 1 | user1 |
| 2 | user2 |
| 3 | user3 |
| 4 | user4 |
+----+-------+
4 rows in set (0.00 sec)
mysql> insert into test_db.test_table values(11,"paris"),(12,"london"),(13,"berlin");
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement
Puis restaurez le nœud NOEUD-MGR1, après restauration, il est nécessaire d'activer manuellement la fonction de réplication de groupe de ce nœud
[root@NOEUD-MGR1 ~]# systemctl start mysqld
[root@NOEUD-MGR1 ~]# mysql -p123456
...............
mysql> START GROUP_REPLICATION;
Query OK, 0 rows affected (3.15 sec)
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
| group_replication_applier | 851d03bb-3e51-11e9-8f8d-00505688047c | 172.16.60.212 | 3306 | ONLINE |
| group_replication_applier | 87135ebb-3e51-11e9-8931-005056880888 | 172.16.60.213 | 3306 | ONLINE |
| group_replication_applier | 8769f936-3e51-11e9-acaa-005056ac6820 | 172.16.60.211 | 3306 | ONLINE |
+---------------------------+--------------------------------------+---------------+-------------+--------------+
3 rows in set (0.00 sec)
mysql> select * from test_db.test_table;
+----+-------+
| id | name |
+----+-------+
| 1 | user1 |
| 2 | user2 |
| 3 | user3 |
| 4 | user4 |
+----+-------+
4 rows in set (0.00 sec)
mysql> insert into test_db.test_table values(11,"paris"),(12,"london"),(13,"berlin");
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement
On constate que le nœud NOEUD-MGR1, après restauration, est devenu un nœud esclave, ne peut que lire, pas écrire.
Si un nœud esclave tombe en panne, après restauration, il suffit d'activer manuellement la fonction de réplication de groupe de ce nœud ("START GROUP_REPLICATION;"),
pour qu'il rejoigne normalement le cluster de réplication de groupe MGR et synchronise automatiquement les données des autres nœuds.