MySQL GR配置实验(单主模式实验)

请叫我水哥 2020-09-07

483

前言：组复制GR(Group Replication)

一、在单主模式下部署组复制

1.1 背景知识说明

1.1.1 组复制安装部署要求

1.1.2 单主模式

1.1.3 多主模式

1.2 基础环境准备

1.3 数据库的安装

1.4 mysql组复制配置修改

1.5 创建组复制恢复通道的用户凭证

1.6 检查组复制插件是否已经安装

1.7 引导组配置和组复制测试

1.8 将s2和s3添加到当前复制组

二、监视组复制

2.1 组复制的状态

2.2 Replication_Group_members表

2.3 plication_group_member_stats表

2.4 如何查询当前哪个是主数据库

三、故障切换测试

3.1 模拟s1故障

3.2 如果过个组成员故障(网络分区的问题)

前言：组复制GR(Group Replication)

实验及说明全部来源与官网文档：

https://dev.mysql.com/doc/refman/5.7/en/group-replication.html

MySQL组复制是一个MySQL Server插件，可以创建弹性的，高可用性的，容错的复制拓扑，保证数据库服务是连续可用的。在MySQL组复制需要管理和维护多台服务器，要让组内多个服务器就系统状态机系统所经历的每一次更改的数据打成一致，以便它们作为一个数据库运行(或者最终收敛到相同状态)。在组复制中每个服务器都有自己的完整数据副本(无共享复制方案)。

组复制解决了数据库的高可用问题，但是服务器的意外停止，则必须将与其连接的客户端重定向或故障转移到其他父亲，这不是组复制解决的问题。可以使用其他中间件解决。

组复制只提供组复制协议如图：

一、在单主模式下部署组复制

1.1 背景知识说明

1.1.1 组复制安装部署要求

安装数据库，组复制是MySQL Server 5.7.17和更高版本提供的内置MySQL插件
三个实例用于组复制，是创建组复制的最小实例数，容忍度为1
数据必须存储在InnoDB事务存储引擎中，通过下面配置关闭其他存储引擎

disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"

主键：组要复制的每个表都必须具有定义的主键，或等效的主键，其中等效项是非null的唯一键。
IPV4网络，组复制使用的组通信引擎仅支持IPV4
网络性能：组复制性能和稳定性可能会受到网络延迟和网络带宽的影响，所有成员之间必须保持双向通信。建议对组复制使用单独的网络(复制网络和业务网络分离)
组复制配置文件要求(见后面实验)
一个组中最多允许9个实例(最大上限)

1.1.2 单主模式

在这种模式下，组具有设置为读写模式的单主服务器。组中的所有其他成员都设置为只读模式（带有 super-read-only=ON ）这会自动发生。主服务器通常是引导该组的第一台服务器，所有其他加入的服务器会自动了解主服务器，并设置为只读。

单主模式如何进行选举的：

在单主模式下，只有一台服务器近些读写操作，因此禁用了在多主要模式下部署的某些检查。例如允许更改具有级联外键的表，而在多主键模式下则不允许更改。当主要成员失败时，自动的主要选举机制将选择新的主要成员。通过查看新视图并根据的权重值对潜在的新原色进行排序来执行选举过程 group_replication_member_weight。假设该组的所有成员都运行相同的MySQL版本，则该成员的值最高 group_replication_member_weight 当选为新的主要。如果多个服务器具有相同 group_replication_member_weight的服务器，则将根据服务器的server_uuid字典顺序对其进行优先级排序，并选择第一个服务器。选出新的主数据库后，它将自动设置为可读写，而其他辅助数据库将保留为辅助数据库，因此保持只读状态。

当选择一个新的主数据库时，它只有在处理完来自旧主数据库的所有事务后才可写。这样可以避免旧的主事务中的旧事务与在该成员上执行的新事务之间可能发生的并发问题。在新的主数据库重新路由客户端应用程序之前，最好等待新的主数据库应用其复制相关的中继日志。

如果该组与运行不同版本MySQL的成员一起运行，则选举过程可能会受到影响。例如，如果任何成员不支持 group_replication_member_weight，那么将根据server_uuid较低主要版本成员的顺序选择主要对象。或者，如果运行不同MySQL版本的所有成员都支持 group_replication_member_weight则从较低主要版本的成员中选择主要成员。

1.1.3 多主模式

在多主要模式下，没有单个主要概念。无需参与选举程序，因为没有服务器扮演任何特殊角色。加入组时，所有服务器均设置为读写模式。

1.2 基础环境准备

1.防火墙和selinux关闭
[root@s1 opt]# systemctl stop firewalld && systemctl disable firewalld
[root@s1 opt]# getenforce 
Disabled
2.hosts文件配置
[root@s1 opt]# cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.10.180 s1
192.168.10.181 s2
192.168.10.182 s3

1.3 数据库的安装

1）创建数据库用户mysql
[root@s1 opt]# useradd -M -r -s /sbin/nologin mysql
2）解压并安装mysql5.7.30
[root@s1 opt]# tar zxf mysql-5.7.30-linux-glibc2.12-x86_64.tar.gz 
[root@s1 opt]# ln -s mysql-5.7.30-linux-glibc2.12-x86_64 mysq
[root@s1 opt]# chown -R mysql.mysql mysql
[root@s1 opt]# chown -R mysql.mysql /data/
[root@s1 opt]# mkdir /data
//卸载掉mariadb相关软件包
[root@s1 opt]# rpm -qa |grep mariadb
mariadb-libs-5.5.56-2.el7.x86_64
[root@s1 opt]# rpm -e mariadb-libs-5.5.56-2.el7.x86_64 --nodeps
//编辑配置文件
[root@s1 mysql]# cat /etc/my.cnf
[mysqld]
datadir=/data
basedir=/opt/mysql
socket=/data/mysql.sock
[mysqld_safe]
log-error=/opt/mysql/mysql.log
pid-file=/run/mysql.pid
[root@s1 mysql]# bin/mysqld --initialize --datadir=/data --user=mysql
2020-09-05T04:55:36.526476Z 1 [Note] A temporary password is generated for root@localhost: vBvEu(sUT3E?
[root@s1 mysql]# cat /etc/profile |grep mysql
export PATH=$PATH:/opt/mysql/bin
[root@s1 mysql]# source /etc/profile
[root@s1 mysql]# cp support-files/mysql.server /etc/init.d/mysqld
[root@s1 mysql]# chmod +x /etc/init.d/mysqld 
[root@s1 mysql]# /etc/init.d/mysqld start
Starting MySQL.. SUCCESS! 
[root@s1 mysql]# chkconfig mysqld on
[root@s1 mysql]# mysql -uroot -p'vBvEu(sUT3E?' -S /data/mysql.sock
mysql> set password=password('123456');
mysql> flush privileges;
[root@s1 mysql]# mysql -uroot -p123456 -S /data/mysql.sock -e 'select version()'
+-----------+
| version() |
+-----------+
| 5.7.30    |
+-----------+
2）s2和s3一样配置

1.4 mysql组复制配置修改

组复制成员之间通过打开对等TCP连接进行通信和消息传递的，官方推荐使用33061，也可以自定义。

1)生成UUID备用
[root@s1 ~]# mysql -uroot -p123456 -S /data/mysql.sock -e 'select uuid()';
+--------------------------------------+
| uuid()                               |
+--------------------------------------+
| 4be4a2c0-ef39-11ea-9ef1-000c2930b5bd |
+--------------------------------------+
2）查看是否存在组复制插件
[root@s1 plugin]# ll /opt/mysql/lib/plugin/group_replication.so 
-rwxr-xr-x 1 mysql mysql 16914210 Mar 23 14:22 /opt/mysql/lib/plugin/group_replication.so
3）s1配置文件修改如下
[root@s1 opt]# cat /etc/my.cnf
[mysqld]
datadir=/data
basedir=/opt/mysql
socket=/data/mysql.sock
#服务唯一id
server_id=1
#开启全局事务GTID
gtid_mode=ON
enforce_gtid_consistency=ON
#二进制日志相关配置
log_bin=s1
binlog_format=ROW
binlog_checksum=NONE
log_slave_updates=ON
relay_log_info_repository=TABLE
master_info_repository=TABLE
#不区分大小写
lower-case-table-names=1
#组复制相关配置
plugin_load_add='group_replication.so' //组复制插件添加到插件列表
transaction_write_set_extraction=XXHASH64 //传输加密算法
group_replication_group_name="4be4a2c0-ef39-11ea-9ef1-000c2930b5bd" //组名，必须使用UUID生成
group_replication_start_on_boot=off //配置插件在服务器启动时不自动启动，首次配置很重要，在其他组成员加入后在自动启动
group_replication_local_address= "s1:33061" //可以使用ip:PORT形式，如果使用域名必须在DNS中能够解析
group_replication_group_seeds= "s1:33061,s2:33061,s3:33061" //组成员列表
group_replication_bootstrap_group=off  //关闭服务器是否作为引导组启动.这个选项应该人为控制。
#mysql中ip地址解析
report_host=192.168.10.180
#只能使用innodb存储引擎
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
[mysqld_safe]
log-error=/opt/mysql/mysql.log
pid-file=/run/mysql.pid 
4）重启服务器使配置生效
[root@s1 plugin]# /etc/init.d/mysqld restart
Shutting down MySQL.. SUCCESS! 
Starting MySQL.. SUCCESS!

1.5 创建组复制恢复通道的用户凭证

1)根据官方文档说明，为了安全性应该禁止把用户凭证写入二进制日志文件
mysql> sets ql_log_bin=0；//关闭
mysql> create user repl@'%' identified by '123456';
mysql> grant replication slave on *.* to repl@'%';
mysql> flush privileges;
mysql> set sql_log_bin=1; //开启
2）配置组复制专用数据恢复和同步通道
mysql> change master to master_user='repl',master_password='123456' for channel 'group_replication_recovery';

1.6 检查组复制插件是否已经安装

mysql> show plugins;
+----------------------------+----------+--------------------+----------------------+---------+
| Name                       | Status   | Type               | Library              | License |
+----------------------------+----------+--------------------+----------------------+---------+
| group_replication          | ACTIVE   | GROUP REPLICATION  | group_replication.so | GPL     |
+----------------------------+----------+--------------------+----------------------+---------+

1.7 引导组配置和组复制测试

首次启动组复制的过程称为引导，使用group_replication_bootstrap_group系统变量来设置引导组，引导程序只能由一台服务器启动完成一次，并且只能执行一次。所以在配置文件中应该禁用(服务器在重新启动后会自动引导另一个具有相同名称的组。这将导致两个不同的组具有相同的名称，避免人为导致的分裂)

1)开启组复制的引导组
mysql> set global group_replication_bootstrap_group=ON;
2)启动组复制
mysql> start group_replication;
3)关闭组复制的引导组
mysql> set global group_replication_bootstrap_group=OFF;
4）查看复制组状态
//注意如果没有设置report_host则这里的member_host为NULL
mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+----------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST    | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+----------------+-------------+--------------+
| group_replication_applier | 0821a39d-ef34-11ea-aac0-000c2930b5bd | 192.168.10.180 |        3306 | ONLINE       |
+---------------------------+--------------------------------------+----------------+-------------+--------------+
1 row in set (0.01 sec)
5）添加测试数据
mysql> create database test;
mysql> use test;
mysql> create table t1(c1 int primary key,c2 text not null);
mysql> insert into t1 values (1,'Luis');
mysql> select * from t1;
+----+------+
| c1 | c2   |
+----+------+
|  1 | Luis |
+----+------+
1 row in set (0.00 sec)
6）查看二进制日志事件
mysql> show binlog events;
+-----------+-----+----------------+-----------+-------------+-------------------------------------------------------------------+
| Log_name  | Pos | Event_type     | Server_id | End_log_pos | Info                                                              |
+-----------+-----+----------------+-----------+-------------+-------------------------------------------------------------------+
| s1.000001 |   4 | Format_desc    |         1 |         123 | Server ver: 5.7.30-log, Binlog ver: 4                             |
| s1.000001 | 123 | Previous_gtids |         1 |         150 |                                                                   |
| s1.000001 | 150 | Gtid           |         1 |         211 | SET @@SESSION.GTID_NEXT= '4be4a2c0-ef39-11ea-9ef1-000c2930b5bd:1' |
| s1.000001 | 211 | Query          |         1 |         270 | BEGIN                                                             |
| s1.000001 | 270 | View_change    |         1 |         369 | view_id=15992858080677783:1                                       |
| s1.000001 | 369 | Query          |         1 |         434 | COMMIT                                                            |
| s1.000001 | 434 | Gtid           |         1 |         495 | SET @@SESSION.GTID_NEXT= '4be4a2c0-ef39-11ea-9ef1-000c2930b5bd:2' |
| s1.000001 | 495 | Query          |         1 |         585 | create database test                                              |
| s1.000001 | 585 | Gtid           |         1 |         646 | SET @@SESSION.GTID_NEXT= '4be4a2c0-ef39-11ea-9ef1-000c2930b5bd:3' |
| s1.000001 | 646 | Query          |         1 |         768 | use `test`; create table t1(c1 int primary key,c2 text not null)  |
| s1.000001 | 768 | Gtid           |         1 |         829 | SET @@SESSION.GTID_NEXT= '4be4a2c0-ef39-11ea-9ef1-000c2930b5bd:4' |
| s1.000001 | 829 | Query          |         1 |         897 | BEGIN                                                             |
| s1.000001 | 897 | Table_map      |         1 |         940 | table_id: 112 (test.t1)                                           |
| s1.000001 | 940 | Write_rows     |         1 |         982 | table_id: 112 flags: STMT_END_F                                   |
| s1.000001 | 982 | Xid            |         1 |        1009 | COMMIT /* xid=34 */                                               |
+-----------+-----+----------------+-----------+-------------+-------------------------------------------------------------------+
15 rows in set (0.00 sec)

1.8 将s2和s3添加到当前复制组

配置完成后，三个服务器上面都应该有完整的数据

1）s2配置如下
[root@s2 mysql]# cat /etc/my.cnf 
[mysqld]
datadir=/data
basedir=/opt/mysql
socket=/data/mysql.sock
#服务唯一id
server_id=2   //修改服务器唯一id
#开启全局事务GTID
gtid_mode=ON
enforce_gtid_consistency=ON
#二进制日志相关配置
log_bin=s2   //binlog日志名修改
binlog_format=ROW
binlog_checksum=NONE
log_slave_updates=ON
relay_log_info_repository=TABLE
master_info_repository=TABLE
#不区分大小写
lower-case-table-names=1
plugin_load_add='group_replication.so'
transaction_write_set_extraction=XXHASH64
group_replication_group_name="4be4a2c0-ef39-11ea-9ef1-000c2930b5bd"  //注意这里是复制组名
group_replication_start_on_boot=off
group_replication_local_address= "s2:33061"  //修改本地组复制成员的地址
group_replication_group_seeds= "s1:33061,s2:33061,s3:33061"  //其他成员的信息
group_replication_bootstrap_group=off
report_host=192.168.10.181  //报告本地的ip
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
[mysqld_safe]
log-error=/opt/mysql/mysql.log
pid-file=/run/mysql.pid
2）创建用户的恢复凭证
mysql> set sql_log_bin=0;
mysql> grant replication slave on *.* to repl@'%' identified by '123456';
mysql> flush privileges;
mysql> set sql_log_bin=1;
mysql> CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='123456' FOR CHANNEL 'group_replication_recovery';
Query OK, 0 rows affected, 2 warnings (0.06 sec)
3）启动组复制
mysql> START GROUP_REPLICATION;
4）查看组复制状态
mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+----------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST    | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+----------------+-------------+--------------+
| group_replication_applier | 0821a39d-ef34-11ea-aac0-000c2930b5bd | 192.168.10.180 |        3306 | ONLINE       |
| group_replication_applier | ca0a4eab-ef36-11ea-bfbb-000c2992efe2 | 192.168.10.181 |        3306 | ONLINE       |
+---------------------------+--------------------------------------+----------------+-------------+--------------+
2 rows in set (0.00 sec)
5）检查同步状态，启动组复制的时候会自动同步，如果数据量大的时候会自动追赶源数据库的数据。
mysql> show databases like 'test';
+-----------------+
| Database (test) |
+-----------------+
| test            |
+-----------------+
1 row in set (0.00 sec)
mysql> select * from test.t1;
+----+------+
| c1 | c2   |
+----+------+
|  1 | Luis |
+----+------+
1 row in set (0.00 sec)
//可以看到s1的测试数据已经自动同步
mysql> show binlog events;
+-----------+-----+----------------+-----------+-------------+---------------------------------------+
| Log_name  | Pos | Event_type     | Server_id | End_log_pos | Info                                  |
+-----------+-----+----------------+-----------+-------------+---------------------------------------+
| s2.000001 |   4 | Format_desc    |         2 |         123 | Server ver: 5.7.30-log, Binlog ver: 4 |
| s2.000001 | 123 | Previous_gtids |         2 |         150 |                                       |
| s2.000001 | 150 | Stop           |         2 |         169 |                                       |
+-----------+-----+----------------+-----------+-------------+---------------------------------------+
3 rows in set (0.00 sec)


注意：
当组复制成功启动并且服务器加入S1组时，它将检查该super_read_only变量。
通过super_read_only在成员的配置文件中将其设置为ON，可以确保由于任何原因启动组复制而失败的服务器不接受事务。
如果服务器应以读写实例的形式加入该组，例如单主或多组的成员身份加入该组，则当super_read_only变量设置为ON时，则在加入时将其设置为OFF。


6）S3的配置和S2一样，检查加入s3后的状态。配置步骤省略
mysql> start group_replication;
ERROR 3096 (HY000): The START GROUP_REPLICATION command failed as there was an error when initializing the group communication layer.
//s3在启动的时候遇到的错误，是hosts文件忘了拷贝，修改后启动成功
mysql> start group_replication;
Query OK, 0 rows affected (3.31 sec)
mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+----------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST    | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+----------------+-------------+--------------+
| group_replication_applier | 0821a39d-ef34-11ea-aac0-000c2930b5bd | 192.168.10.180 |        3306 | ONLINE       |
| group_replication_applier | 7ead5b5c-ef37-11ea-9f61-000c29b74b76 | 192.168.10.182 |        3306 | ONLINE       |
| group_replication_applier | ca0a4eab-ef36-11ea-bfbb-000c2992efe2 | 192.168.10.181 |        3306 | ONLINE       |
+---------------------------+--------------------------------------+----------------+-------------+--------------+
3 rows in set (0.00 sec)
//已经可以看到有三个组了
mysql> select * from test.t1;
+----+------+
| c1 | c2   |
+----+------+
|  1 | Luis |
+----+------+
1 row in set (0.00 sec)


mysql> show binlog events;
+-----------+-----+----------------+-----------+-------------+---------------------------------------+
| Log_name  | Pos | Event_type     | Server_id | End_log_pos | Info                                  |
+-----------+-----+----------------+-----------+-------------+---------------------------------------+
| s3.000001 |   4 | Format_desc    |         3 |         123 | Server ver: 5.7.30-log, Binlog ver: 4 |
| s3.000001 | 123 | Previous_gtids |         3 |         150 |                                       |
| s3.000001 | 150 | Stop           |         3 |         169 |                                       |
+-----------+-----+----------------+-----------+-------------+---------------------------------------+
3 rows in set (0.00 sec)
//数据已经同步

二、监视组复制

2.1 组复制的状态

请注意，组复制不是同步的，但最终是同步的。更确切地说，事务以相同的顺序交付给所有组成员，但是它们的执行不同步，这意味着在接受了要提交的事务之后，每个成员都按照自己的进度进行事务(这就是追赶的过程)。

状态	描述	组同步
ONLINE	该成员随时可以充当功能齐全的组成员，这意味着客户端可以连接并开始执行事务。	是
RECOVERING	该成员正在成为该组的活跃成员，并且正在接受恢复过程，正在从其他成员那里接收状态信息。	没有
OFFLINE	插件已加载，但成员不属于任何组。	没有
ERROR	成员的状态。每当恢复阶段发生错误或应用更改时，服务器就会进入此状态。	没有
UNREACHABLE	每当本地故障检测器怀疑给定服务器无法访问时（例如由于非自愿断开连接），它将显示该服务器的状态为UNREACHABLE。	没有

2.2 Replication_Group_members表

该表用于监视属于该组成员的不同服务器实例的状态。只要有视图更改，表中的信息就会更新。该信息在属于复制组的所有服务器实例之间共享，因此可以从任何成员查询有关所有组成员的信息。上面实验中有截图，这里就不提供了

2.3 plication_group_member_stats表

表提供了与认证过程相关的组级别信息，还提供了复制组的每个单独成员接收和发起的事务的统计信息。该信息在属于复制组的所有服务器实例之间共享。

s1的状态
mysql> SELECT * FROM performance_schema.replication_group_member_stats\G
*************************** 1. row ***************************
                      CHANNEL_NAME: group_replication_applier
                           VIEW_ID: 15992858080677783:3
                         MEMBER_ID: 0821a39d-ef34-11ea-aac0-000c2930b5bd
       COUNT_TRANSACTIONS_IN_QUEUE: 0
        COUNT_TRANSACTIONS_CHECKED: 3
          COUNT_CONFLICTS_DETECTED: 0
COUNT_TRANSACTIONS_ROWS_VALIDATING: 0
TRANSACTIONS_COMMITTED_ALL_MEMBERS: 4be4a2c0-ef39-11ea-9ef1-000c2930b5bd:1-6
    LAST_CONFLICT_FREE_TRANSACTION: 4be4a2c0-ef39-11ea-9ef1-000c2930b5bd:4
1 row in set (0.01 sec)

2.4 如何查询当前哪个是主数据库

mysql> show status like 'group_replication_primary_member';
+----------------------------------+--------------------------------------+
| Variable_name                    | Value                                |
+----------------------------------+--------------------------------------+
| group_replication_primary_member | 0821a39d-ef34-11ea-aac0-000c2930b5bd |
+----------------------------------+--------------------------------------+
1 row in set (0.01 sec)

三、故障切换测试

3.1 模拟s1故障

1)停止s1的数据库
[root@s1 plugin]# /etc/init.d/mysqld stop
Shutting down MySQL............. SUCCESS! 
2)查看此时组状态
mysql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+----------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST    | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+----------------+-------------+--------------+
| group_replication_applier | 7ead5b5c-ef37-11ea-9f61-000c29b74b76 | 192.168.10.182 |        3306 | ONLINE       |
| group_replication_applier | ca0a4eab-ef36-11ea-bfbb-000c2992efe2 | 192.168.10.181 |        3306 | ONLINE       |
+---------------------------+--------------------------------------+----------------+-------------+--------------+
2 rows in set (0.00 sec)
3）查看当前主数据库
mysql> show status like 'group_replication_primary_member';
+----------------------------------+--------------------------------------+
| Variable_name                    | Value                                |
+----------------------------------+--------------------------------------+
| group_replication_primary_member | 7ead5b5c-ef37-11ea-9f61-000c29b74b76 |
+----------------------------------+--------------------------------------+
1 row in set (0.03 sec)
//s3是主数据库
4）证明下前面的单主模式的说明，只有一个服务器处于读写状态，其他服务器都会自动添加--super-read-only=on，变成只读数据库
在s2上面插入数据
mysql> insert into test.t1 values (2,'Cs');
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement
//根据报错很容易证明前面所说
在S3主数据库插入数据
mysql> insert into test.t1 values (2,'Cs');
mysql> insert into test.t1 values (3,'yunjia');
mysql> insert into test.t1 values (4,'Lisi');
mysql> select * from test.t1;
+----+--------+
| c1 | c2     |
+----+--------+
|  1 | Luis   |
|  2 | Cs     |
|  3 | yunjia |
|  4 | Lisi   |
+----+--------+
4 rows in set (0.00 sec)
在S2上面查看数据已经同步
mysql> select * from test.t1;
+----+--------+
| c1 | c2     |
+----+--------+
|  1 | Luis   |
|  2 | Cs     |
|  3 | yunjia |
|  4 | Lisi   |
+----+--------+
4 rows in set (0.00 sec)
5）恢复故障的S1
[root@s1 plugin]# /etc/init.d/mysqld start
mysql> select * from performance_schema.replication_group_members; //s1查看
+---------------------------+-----------+-------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+-----------+-------------+-------------+--------------+
| group_replication_applier |           |             |        NULL | OFFLINE      |
+---------------------------+-----------+-------------+-------------+--------------+
1 row in set (0.01 sec)
//OFFLINE是插件已经加载，但是不属于任何组。这里就说明了配置文件中设置OFF的意义。如果为ON到时候会创建两个同名的组，导致产生分裂。
mysql> start group_replication; //启动组复制
mysql>  select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+----------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST    | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+----------------+-------------+--------------+
| group_replication_applier | 0821a39d-ef34-11ea-aac0-000c2930b5bd | 192.168.10.180 |        3306 | ONLINE       |
| group_replication_applier | 7ead5b5c-ef37-11ea-9f61-000c29b74b76 | 192.168.10.182 |        3306 | ONLINE       |
| group_replication_applier | ca0a4eab-ef36-11ea-bfbb-000c2992efe2 | 192.168.10.181 |        3306 | ONLINE       |
+---------------------------+--------------------------------------+----------------+-------------+--------------+
3 rows in set (0.00 sec)
mysql> select * from test.t1;
+----+--------+
| c1 | c2     |
+----+--------+
|  1 | Luis   |
|  2 | Cs     |
|  3 | yunjia |
|  4 | Lisi   |
+----+--------+
4 rows in set (0.00 sec)

3.2 如果过个组成员故障(网络分区的问题)

当发生多个非自愿故障时，仲裁可能会丢失，从而导致大多数服务器突然从组中删除。例如，在一组5台服务器中，如果其中3台立即变为静默状态，则大多数服务器将受到损害，因此无法实现仲裁。实际上，其余两个服务器无法判断其他3台服务器是否崩溃，或者网络分区是否单独隔离了这2台服务器，因此无法自动重新配置该组。

另一方面，如果服务器自愿退出该组，则它们会指示该组重新配置自身。实际上，这意味着要离开的服务器会告诉其他人它要离开。这意味着其他成员可以正确地重新配置组，维护成员身份的一致性，并重新计算大多数成员。例如，在上面的场景中有5个服务器同时离开3个服务器的情况下，如果3个离开服务器向组警告他们即将离开的组，则成员资格能够将自己从5个调整为2个时间，确保达到法定人数。

在大多数情况下，系统没有运行到分区，因此该表显示的信息在组中的所有服务器之间都是一致的。(都是一个组内)，但是，如果存在网络分区，并且仲裁丢失，那么该表将显示UNREACHABLE 其无法联系的那些服务器的状态。该信息由组复制中内置的本地故障检测器导出。

当前服务器状态如下：
mysql> SELECT MEMBER_ID,MEMBER_STATE, MEMBER_ROLE FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+
| MEMBER_ID                            | MEMBER_STATE |
+--------------------------------------+--------------+
| 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | ONLINE       |
| 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | ONLINE       |
| 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE       |
| 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | ONLINE       |
| 19b33846-4aaf-11e6-ba81-28b2bd168d07 | ONLINE       |
+--------------------------------------+--------------+
片刻之后发生灾难性故障，服务器s3，s4和s5意外停止。
此后几秒钟，再次replication_group_members查看s1 上的表表明该表仍处于联机状态，但其他几个成员不在。实际上，如下所示，它们标记为 UNREACHABLE。而且，系统无法重新配置自身以更改成员资格，因为大多数已经丢失。
mysql> SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+
| MEMBER_ID                            | MEMBER_STATE |
+--------------------------------------+--------------+
| 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | UNREACHABLE  |
| 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | ONLINE       |
| 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE       |
| 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | UNREACHABLE  |
| 19b33846-4aaf-11e6-ba81-28b2bd168d07 | UNREACHABLE  |
+--------------------------------------+--------------+
由于大多数服务器无法访问，因此s1和s2现在位于没有外部干预就无法进行正常运行(无法访问)的组中。在这种特殊情况下，需要重置组成员资格列表以使系统继续运行。

组复制使您可以通过强制进行特定配置来重置组成员资格列表。例如，在上面的示例中，其中s1和s2是唯一的联机服务器，您可以选择强制仅由s1和s2组成的成员身份配置。这需要检查有关s1和s2的一些信息，然后使用该 group_replication_force_members 变量。

警告：

此过程使用 group_replication_force_members 并且应被视为最后的补救措施。必须格外小心地使用它，并且仅用于使仲裁无效。如果使用不当，它可能会创建人为裂脑方案或完全阻塞整个系统。

1）上面的说明中。数据库已经无法访问。下面是S1上面查询的状态
mysql> SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+
| MEMBER_ID                            | MEMBER_STATE |
+--------------------------------------+--------------+
| 1999b9fb-4aaf-11e6-bb54-28b2bd168d07 | UNREACHABLE  |
| 199b2df7-4aaf-11e6-bb16-28b2bd168d07 | ONLINE       |S1
| 199bb88e-4aaf-11e6-babe-28b2bd168d07 | ONLINE       | S2
| 19ab72fc-4aaf-11e6-bb51-28b2bd168d07 | UNREACHABLE  |
| 19b33846-4aaf-11e6-ba81-28b2bd168d07 | UNREACHABLE  |
+--------------------------------------+--------------+
3 rows in set (0.00 sec)
2）获取S1和S2通信地址
mysql> SELECT @@group_replication_local_address;
+-----------------------------------+
| @@group_replication_local_address |
+-----------------------------------+
| s1:33061                          |
+-----------------------------------+
1 row in set (0.00 sec)
mysql> SELECT @@group_replication_local_address;
+-----------------------------------+
| @@group_replication_local_address |
+-----------------------------------+
| s2:33061                          |
+-----------------------------------+
1 row in set (0.00 sec)
3）在两个服务器之一上注入新的成员资格配置，从而覆盖丢失了仲裁的现有成员资格配置。要在s1上执行此操作：
mysql> SET GLOBAL group_replication_force_members="s1:33061,s2:33061";
5）这时已经单独创建了一个新的分区，形成一个单独的分区组
mysql> SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members;
+--------------------------------------+--------------+
| MEMBER_ID                            | MEMBER_STATE |
+--------------------------------------+--------------+
| b5ffe505-4ab6-11e6-b04b-28b2bd168d07 | ONLINE       |
| b60907e7-4ab6-11e6-afb7-28b2bd168d07 | ONLINE       |
+--------------------------------------+--------------+
此时数据库可以进行访问

强制执行新的成员资格配置时，请确保确实要停止将要从组中强制退出的所有服务器。在上述情况下，如果s3，s4和s5并不是真正不可访问而是在线的，则它们可能已经形成了自己的功能分区（5分之3，因此占多数）。在这种情况下，将组成员列表强制为s1和s2可能会造成人为的裂脑情况。因此，在强制执行新的成员资格配置之前，确保要排除的服务器确实已关闭是很重要的；如果没有关闭，请在继续操作之前将其关闭。

使用 group_replication_force_members 系统变量成功强制新的组成员身份并取消阻止该组后，请确保清除系统变量。 group_replication_force_members 必须为空才能发出START GROUP_REPLICATION声明。

mysql

文章转载自请叫我水哥，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

MySQL GR配置实验(单主模式实验)

评论