MGR 切换
MGR 切换
采用MYCAT 完成 vi mycat/conf/schema.xml
<?xmlversion=”1.0”>
<mycat:schemaxmlns:mycat=”http://io.mycat/’>
<schema name=’db_test’checkSQLschema=’false’ sqlMaxLimit=’100’ dataNode=”db_node”></schema>
<dataNode name=”db_node”dataHost=”db_host” database=”db_test”/>
<dataHost name=”db_host”MaxCon=”1000” minCon=”10” balance=”2” writeType=”0” dbType=”mysql” dbDrive=”native”
switchType=”1” slaveThreshold=”100”>
<heartbeat>select user()</heartbeat>
<writeHost host=”MGR_10” url=”192.168.2.10:3306” user=”root” password=”123456”> ##主库
<readHosthost=”MGR_11” url=”192.168.2.11:3306” user=”root”password=”123456”/> #只读库
</writeHost>
<writeHost host=”MGR_12” url=”192.168.2.12:3306” user=”root” password=”123456” /> ##这个是备用主库
</dataHost>
</mycat:schema>
##balance=0不读写分离；1 write + standby write 参与读负载；2 所有读随机在WRITE+READ ；3 读分到READ
writeType=0写操作在WRITEHOST；1 写操作随机发到所有的WRITEHOST
swithType=-1不自动切换；1 自动切换；2基于状态showslave status
采用Mysql Router
[routing:basic_failover]
# To bemore transparent, use MySQL Server port 3306
bind_address= 192.168.2.20
bind_port= 3306
routing_strategy= first-available
mode= read-write
destinations= 192.168.2.10:3306,192.168.2.11:3306,192.168.2.12:3306
[routing:load_balance]
bind_address= 192.168.2.20
bind_port= 3308
mode= read-only
destinations= 192.168.2.11:3306,192.168.2.12:3306
两个路由选择
第一个是失败切换 目标数据库都是可以读写模式，按顺序进行切换。比如2.10失败了，就切到2.11，再失败就切到2.12。
第二个负载均衡，ROUTER 靠应用程序使用多数据源来完成读写分离，通过3308接口连接到ROUTER。
这里设置目标MYSQL MGR两个节点
MGR 添加新节点
MGR 添加新节点
在组复制中使用备份数据恢复失败的成员增加新成员
设置组中已经有3个组成员(node1、node2和node3)，通过组中任意成员的performance_schema.replication_group_members表可以查询到组中的成员资格与状态信息，如下：
root@localhost : (none):45: > SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 2d283e92-de7b-11e9-a14d-525400c33752 | node2 | 3306 | ONLINE | SECONDARY | 8.0.17 |
| group_replication_applier | 2e33b2a7-de7b-11e9-9a21-525400bdd1f2 | node3 | 3306 | ONLINE | SECONDARY | 8.0.17 |
| group_replication_applier | 320675e6-de7b-11e9-b3a9-5254002a54f2 | node1 | 3306 | ONLINE | PRIMARY | 8.0.17 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
3 rows in set (0.00 sec)复制
使用percona-xtrabackup工具执行备份,不要在主要节点上执行备份
# 在node3中执行备份命令
[root@node3 ~]# xtrabackup --defaults-file=/etc/my.cnf --user=admin --password='letsg0' --backup --target-dir=/data//backup/
......
191012 17:19:37 Backup created in directory '/data/backup/'
MySQL binlog position: filename 'mysql-bin.000023', position '231', GTID of the last change '320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-2771494'
191012 17:19:37 [00] Writing /data/backup/backup-my.cnf
191012 17:19:37 [00] ...done
191012 17:19:37 [00] Writing /data/backup/xtrabackup_info
191012 17:19:37 [00] ...done
xtrabackup: Transaction log of lsn (11495841139) to (11495843979) was copied.
191012 17:19:37 completed OK!
# 备份完成之后查看备份数据目录中的数据文件
[root@node3 ~]# ll /data//backup/
total 2147376
-rw-r----- 1 root root 515 Oct 12 17:19 backup-my.cnf
-rw-r----- 1 root root 2147483648 Oct 12 17:19 ibdata1
drwxr-x--- 2 root root 143 Oct 12 17:19 mysql
-rw-r----- 1 root root 231 Oct 12 17:19 mysql-bin.000023
-rw-r----- 1 root root 52 Oct 12 17:19 mysql-bin.index
-rw-r----- 1 root root 24117248 Oct 12 17:19 mysql.ibd
drwxr-x--- 2 root root 8192 Oct 12 17:19 performance_schema
drwxr-x--- 2 root root 44 Oct 12 17:19 sbtest
drwxr-x--- 2 root root 28 Oct 12 17:19 sys
drwxr-x--- 2 root root 20 Oct 12 17:19 test
-rw-r----- 1 root root 13631488 Oct 12 17:19 undo_001
-rw-r----- 1 root root 13631488 Oct 12 17:19 undo_002
-rw-r----- 1 root root 109 Oct 12 17:19 xtrabackup_binlog_info
-rw-r----- 1 root root 101 Oct 12 17:19 xtrabackup_checkpoints
-rw-r----- 1 root root 622 Oct 12 17:19 xtrabackup_info
-rw-r----- 1 root root 5632 Oct 12 17:19 xtrabackup_logfile
-rw-r----- 1 root root 262 Oct 12 17:19 xtrabackup_tablespaces复制
将备份数据传输到新的等待加入组的node4的主机中
# 在这个例子中，我们假设主机都是Linux服务器，并使用SCP在它们之间复制文件
## 在node4中创建用于存放备份数据的目录
[root@node4 ~]# mkdir /data/backup/xtrabackup_dir
## 在node3中将备份数据使用SCP传送到node4中
[root@node3 ~]# scp -r /data//backup/ 10.10.30.16:/data/backup/xtrabackup_dir复制
我们需要使用备份数据恢复目标实例先停止目标服务器的数据库进程，如下：
# 首先停止目标服务器的数据库进程
[root@physical-machine ~]# service mysqld stop
Shutting down MySQL..... SUCCESS!
[root@physical-machine ~]# ps aux |grep mysqld |grep -v grep
[root@physical-machine ~]#
# 注意：如果是用备份数据来恢复发生故障的成员，且故障成员的主机未宕机，则建议将故障成员的datadir下的auto.cnf和mysqld-auto.cnf文件先拷贝出来，稍后使用备份数据恢复完成之后，再拷贝回原目录（auto.cnf中记录着源实例的UUID，使用该UUID来对实例进行恢复时，可确保故障实例可以以原来的身份重新加入组，而不是重新生成一个UUID以新的身份加入组；mysqld-auto.cnf记录了Server本地的一些系统变量的临时持久化设置），拷贝命令类似如下
[root@node2 ~]# cp -ar /data//mysqldata1/mydata/{auto.cnf,mysqld-auto.cnf} /data/backup/
[root@node2 ~]# ll /data//backup/*.cnf
-rw-r----- 1 mysql mysql 56 Sep 24 11:27 /data//backup/auto.cnf
-rw-r----- 1 mysql mysql 414 Sep 25 17:12 /data//backup/mysqld-auto.cnf复制
清空目标主机中的数据目录如下：
# 必须清空共享表空间(innodb_data_home_dir)、独立表空间(datadir)、独立undo表空间(innodb_undo_directory)、redo log日志(innodb_log_group_home_dir)数据文件所在的目录，否则后续恢复将无法拷贝文件（如果可以，中继日志、二进制日志所在的目录也一并清空），类似如下
[root@node4 ~]# rm -rf /data/mysqldata1/{binlog,innodb_log,innodb_ts,mydata,relaylog,undo}/*复制
对备份数据执行redo log恢复。
# 执行恢复语句
[root@node4 ~]# xtrabackup --prepare --target-dir=/data/backup/xtrabackup_dir/backup/
......
FTS optimize thread exiting.
Starting shutdown...
Log background threads are being closed...
Shutdown completed; log sequence number 11495844364
191014 15:32:39 completed OK!
# 执行完成恢复之后，查看备份数据文件所在目录，可以发现多了一些文件和目录
[root@physical-machine ~]# ll /data/backup/xtrabackup_dir/backup/
total 6362156
-rw-r----- 1 root root 515 Oct 12 18:01 backup-my.cnf
-rw-r----- 1 root root 2147483648 Oct 14 15:32 ibdata1
-rw-r----- 1 root root 2147483648 Oct 14 15:32 ib_logfile0 # 发现多了ib_logfile0和ib_logfile1文件
-rw-r----- 1 root root 2147483648 Oct 14 15:32 ib_logfile1
-rw-r----- 1 root root 12582912 Oct 14 15:32 ibtmp1 # 多了ibtmp1文件
drwxr-x--- 2 root root 6 Oct 14 15:32 #innodb_temp # 多了一个目录
drwxr-x--- 2 root root 143 Oct 12 18:01 mysql
-rw-r----- 1 root root 231 Oct 12 18:01 mysql-bin.000023
-rw-r----- 1 root root 52 Oct 12 18:01 mysql-bin.index
-rw-r----- 1 root root 24117248 Oct 14 15:32 mysql.ibd
drwxr-x--- 2 root root 8192 Oct 12 18:01 performance_schema
drwxr-x--- 2 root root 44 Oct 12 18:00 sbtest
drwxr-x--- 2 root root 28 Oct 12 18:00 sys
drwxr-x--- 2 root root 20 Oct 12 18:00 test
-rw-r----- 1 root root 13631488 Oct 14 15:32 undo_001
-rw-r----- 1 root root 13631488 Oct 14 15:32 undo_002
-rw-r----- 1 root root 109 Oct 12 18:01 xtrabackup_binlog_info
-rw-r----- 1 root root 101 Oct 14 15:32 xtrabackup_checkpoints
-rw-r----- 1 root root 622 Oct 12 18:01 xtrabackup_info
-rw-r----- 1 root root 8388608 Oct 14 15:32 xtrabackup_logfile
-rw-r--r-- 1 root root 1 Oct 14 15:32 xtrabackup_master_key_id # 多了xtrabackup_master_key_id文件
-rw-r----- 1 root root 262 Oct 14 15:32 xtrabackup_tablespaces复制
将恢复完成的备份数据文件拷贝到目标数据库Server的数据目录下。
[root@physical-machine ~]# xtrabackup --defaults-file=/etc/my.cnf --copy-back --target-dir=/data/backup/xtrabackup_dir/backup/
......
191014 16:26:10 [01] Creating directory ./#innodb_temp
191014 16:26:10 [01] ...done.
191014 16:26:10 completed OK!复制
修改目标数据库的数据目录权限，并配置好my.cnf。
# 修改目录权限
[root@node4 backup]# chown mysql.mysql /data/mysqldata1/ -R
# 在my.cnf中配置好组复制的系统变量（如果是恢复故障Server而不是新增Server，这些配置都在，无需重复配置）
[root@node4 backup]# cat /etc/my.cnf
......
disabled_storage_engines="MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY"
binlog_checksum=NONE
plugin_load_add='group_replication.so'
group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
group_replication_start_on_boot=off
group_replication_local_address= "10.10.30.16:33061"
group_replication_group_seeds= "10.10.30.162:33061,10.10.30.163:33061,10.10.30.164:33061"
group_replication_bootstrap_group=off
report_host=node4
# 配置好hosts解析记录，或者将report_host指定为IP地址也可以不用配置解析记录（将node4的解析记录同时配置到其他组成员的/etc/hosts文件中）（如果是恢复故障Server而不是新增Server，这些配置都在，无需重复配置）
[root@physical-machine ~]# cat /etc/hosts
......
10.10.30.16 node4
10.10.30.162 node1
10.10.30.163 node2
10.10.30.164 node3复制
如果有需要，且允许，请将auto.cnf与mysqld-auto.cnf文件拷贝到目标数据库Server的datadir目录下
# 操作命令类似如下
[root@node2 ~]# cp -ar /data/backup/{auto.cnf,mysqld-auto.cnf} /data/mysqldata1/mydata/复制
启动目标数据库Server进程（node4）。
[root@physical-machine backup]# service mysqld start
Starting MySQL......... SUCCESS!
[root@node4 backup]# ps aux |grep mysqld |grep -v grep
root 27818 0.7 0.0 11760 1640 pts/3 S 17:23 0:00 /bin/sh /usr/local/mysql/bin/mysqld_safe --datadir=/home/mysql/data/mysqldata1/mydata --pid-file=/home/mysql/data/mysqldata1/sock/mysql.pid
mysql 29388 102 3.4 107051036 8436648 pts/3 Sl 17:23 0:16 /usr/local/mysql/bin/mysqld --basedir=/usr/local/mysql --datadir=/home/mysql/data/mysqldata1/mydata --plugin-dir=/usr/local/mysql/lib/plugin --user=mysql --log-error=/home/mysql/data/mysqldata1/log/error.log --open-files-limit=65535 --pid-file=/home/mysql/data/mysqldata1/sock/mysql.pid --socket=/home/mysql/data/mysqldata1/sock/mysql.sock --port=3306复制
查看备份目录下的xtrabackup_binlog_info文件中的GTID信息。
[root@physical-machine ~]# cd /data/backup/xtrabackup_dir/backup/
# 记录下320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-2771494字符串，稍后登录数据库中需要使用
[root@physical-machine backup]# cat xtrabackup_binlog_info
mysql-bin.000023 231 320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-2771494复制
登录到node4的数据库Server中，重设GTID SET信息，如下：
# 先查看一下当前的GTID SET信息，如果与xtrabackup_binlog_info文件中记录的一致，就不需要后续步骤了（在一个在线的组中，这里GTID经常会不一致，这里我们的示例中GTID SET碰巧一致是因为在执行备份期间，组并没有新的请求进入）
admin@localhost : (none):37: > show master status;
+------------------+----------+--------------+------------------+------------------------------------------------------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+------------------------------------------------------------------------------------------+
| mysql-bin.000024 | 231 | | | 320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-2771494 |
+------------------+----------+--------------+------------------+------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
# 如果发现GTID SET信息与xtrabackup_binlog_info文件中记录的不一样，则需要执行后续步骤，重设GTID SET为xtrabackup_binlog_info文件中记录的GTID SET
admin@localhost : (none):37: > reset master;
Query OK, 0 rows affected (0.01 sec)
admin@localhost : (none):38: > set global gtid_purged='320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-2771494';
Query OK, 0 rows affected (0.00 sec)
admin@localhost : (none):38: > show master status;
+------------------+----------+--------------+------------------+------------------------------------------------------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+------------------------------------------------------------------------------------------+
| mysql-bin.000001 | 151 | | | 320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-2771494 |
+------------------+----------+--------------+------------------+------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)复制
登录到node4的数据库Server中，启动组复制。
# 使用如下语句使node4加入组
admin@localhost : (none):38: > START GROUP_REPLICATION;
Query OK, 0 rows affected (3.77 sec)
# 稍后查看成员状态信息，可以看到node4节点已经处于ONLINE状态了（如果在node4操作过程中，组持续不断有新的事务写入，那么，在其申请加入组的过程中，会有一部分事务需要追赶，所以node4可能有一段时间处于RECOVERING状态，等待追赶事务完成之后，才会变更ONLINE状态）
admin@localhost : (none):02: > select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 2d283e92-de7b-11e9-a14d-525400c33752 | node2 | 3306 | ONLINE | SECONDARY | 8.0.17 |
| group_replication_applier | 2e33b2a7-de7b-11e9-9a21-525400bdd1f2 | node3 | 3306 | ONLINE | SECONDARY | 8.0.17 |
| group_replication_applier | 320675e6-de7b-11e9-b3a9-5254002a54f2 | node1 | 3306 | ONLINE | PRIMARY | 8.0.17 |
| group_replication_applier | 54b857f4-ee64-11e9-ada9-0025905b06da | node4 | 3306 | ONLINE | SECONDARY | 8.0.17 |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
4 rows in set (0.01 sec)复制
将系统变量group_replication_start_on_boot=ON加入到my.cnf中，以避免node4重启之后无法自动加入组。
注意：如果组中的主要节点发生故障，在应用程序端如果未做主要节点的切换操作（如果在主要节点发生故障之后，组内新选举出了主要节点，且应用程序已经切换到了新的主要节点，则无此问题。但凡是总有例外，风险意识必须有），那么，在使用备份恢复主要节点时，需要将如下一些参数在数据库Server启动之前配置到my.cnf配置文件中，以防止在恢复主要节点的过程中，应用程序写入新的数据，造成数据与组中的数据不一致而导致加入组失败。
[root@node4 ~]# cat my.cnf
......
# 不自动启动MGR插件
group_replication_start_on_boot=OFF
# 在启动故障主要节点的数据库进程之前，设置只读，防止在执行分布式恢复过程中，应用程序写入新的数据到该节点中，造成与组中的数据不一致而导致加入组失败
super_read_only=ON
# 如果有使用事件调度器做一些数据操作，也需要在启动之前关闭，以防止造成数据不一致而加入组失败
event_scheduler=OFF复制
当发生故障的主要节点重新成功加入组之后，再将my.cnf配置文件中MGR插件和事件调度器的系统变量修改为ON，删除只读操作参数，如下：
# 动态启用事件调度器
mysql> SET global event_scheduler=ON;
# 在my.cnf配置文件中启用MGR插件和事件调度器，删除只读操作参数（注意，这里不是将只读参数设置为OFF，组复制会在组中根据单主和多主模式自动调整只读参数的设置，前面添加该参数到配置文件中的目的是为了避免发生意外写入，一旦加入组之后，就不需要人为干预了）
group_replication_start_on_boot=ON
event_scheduler=ON复制
xtrabackup 8.0版本支持备份时不加全局读锁（不执行FLUSH TABLE WITH READ LOCK语句），这就避免了在组复制中启用多线程回放的组成员上执行备份时造成锁死的现象，但是，为了保证一致性，是通过执行FLUSH NO_WRITE_TO_BINLOG BINARY LOGS语句来切换二进制日志，并拷贝最后一个二进制日志，在执行恢复时使用最后一个二进制日志来恢复一致性位置的方式来变相实现的。如果有大事务，则存在无法切换二进制日志的风险（执行切换二进制日志的语句可能会被长时间阻塞），具体情况请大家自行斟酌，做好充足的测试。
在xtrabackup 8.0版本废弃了innobackupex命令，统一使用xtrabackup命令，这样一来，就可以使用xtrabackup命令的--lock-ddl和--lock-ddl-per-table选项在备份过程中阻塞DDL但并不阻塞DML操作。从而很好地防止了在备份期间发生DDL修改表结构导致备份失败的问题。
在xtrabackup 8.0版本中，当发现有非InnoDB或RocksDB引擎时，Oracle MySQL版本则仍然会加全局读锁（由于Percona Server支持备份锁，因此在这种情况下，Percona Server并不是加全局读锁，而是使用LOCK TABLES FOR BACKUP语句加备份锁），当发现不存在非InnoDB或RocksDB引擎时，则如果无需考虑在备份期间存在DDL操作的情况，无需使用--lock-ddl和--lock-ddl-per-table选项，且备份过程中不会对数据库执行加锁操作。
MGR 监控
MGR 监控
假设已启用performance_schema(performance_schema=ON)，那么我们可以使用performance_schema下的表来监控组复制的运行状态。
监控组成员同步事务的状态以及组成员自身的状态表。
*performance_schema.replication_group_member_stats：记录组成员各自同步数据的状态信息。
*performance_schema.replication_group_members：记录组成员本身的状态信息。
监控由MGR插件创建的两个组复制专用通道group_replication_recovery和group_replication_applier相关的状态表（这些表在主从复制拓扑中也用于记录从库复制线程的状态信息）。
*performance_schema.replication_connection_status：记录从组中接受到的且在applier队列（中继日志）中排队的事务（单主模式下，对于主要节点，该表中只有一行组复制通道group_replication_applier的状态记录。对于辅助节点，即复制远端事务的组成员，此表中会多一行组复制通道group_replication_recovery的状态记录），可以理解为主从复制拓扑中，IO线程的位置信息。
*performance_schema.replication_applier_status：记录组复制的专用复制通道group_replication_recovery和group_replication_applier本身的状态信息（同样，单主模式下，对于主要节点，该表中只有一行组复制通道group_replication_applier的状态记录。对于辅助节点，即复制远端事务的组成员，此表中会多一行复制通道group_replication_recovery的状态记录），可以理解为主从复制拓扑中，IO线程的状态信息。
监控关于两个组复制专用通道group_replication_recovery和group_replication_applier中接受的并正在进行分发与应用的事务状态表。
*performance_schema.replication_applier_status_by_coordinator：记录SQL协调器线程分发事务相关的状态（单主模式下，对于主要节点，该表中只有一行组复制通道group_replication_applier的状态记录。对于辅助节点，即复制远端事务的组成员，此表中会多一行组复制通道group_replication_recovery的状态记录）。
*performance_schema.replication_applier_status_by_worker：记录worker线程应用事务相关的状态（单主模式下，对于主要节点，该表中只有组复制通道group_replication_applier的记录，但具体的行数由系统变量slave_parallel_workers定义值决定。对于辅助节点，即复制远端事务的组成员，此表中会多记录组复制通道group_replication_recovery对应的记录，该通道记录的行数仍然由系统变量slave_parallel_workers定义值决定）。
PS：关于组复制专用通道：
*group_replication_recovery：此通道用于与分布式恢复阶段复制相关的变更数据 。
*group_replication_applier：此通道用于组状态正常的情况下，复制（接收）来自组的变更数据。
3.1. 组复制成员状态
组复制的组成员存在多种有效预设状态值。如果所有组成员之间的通信正常，则所有组成员都能报告相同的状态。但是，如果存在网络分区，或者有成员脱离了组，则可能会报告不同的状态信息。具体来说，如果我们查看一个已经脱离组的Server，则由于它已经脱离了组，所以无法报告关于其他组成员状态的更新信息。如果存在分区，导致冲裁失效（活跃成员数量低于了总成员数量的半数），则组成员相互之间就不能够交换状态信息。此时组状态仍然不正常，不同的组成员上查看到的自身状态可能各不相同，但，如果只有少数成员发生故障，活跃成员占多数，则，除了脱离组的Server之外，其他剩余活跃成员中看到的所有组的成员都能够报告相同的状态。
关于组成员的有效状态列表及其对应的含义如下表。
| 状态值 | 状态描述 | 是否与组保持同步 |
|---|---|---|
表示该成员已经准备好作为一个功能齐全的组成员（活跃成员），这意味着该成员可以正常接受客户端的访问（单主模式下，主要节点可接受读写访问， | 是 | |
RECOVERING | 表示该成员正在成为该组的活跃成员，目前正在恢复过程中，正在接受来自donor节点的状态转移数据。 | 否 |
OFFLINE | 表示该Server已加载了MGR插件，但此时Server不属于任何组。 | 否 |
ERROR | 表示该成员处于错误状态，不能作为任何组的成员正常工作。如果该Server曾经成功加入过组一次，后续发生任何故障， | 否 |
UNREACHABLE | 当本地故障检测器怀疑某个给定的成员不可访问时(例如，由于非自愿与组断开了连接时)，将显示该成员的状态为UNREACHABLE。 | 否 |
3.2. performance_schema.replication_group_members表
performance_schema.replication_group_members表用于监控组中的不同成员实例的状态。每当视图发生更改时，表中的信息就会更新，例如：当有新成员加入组动态更改组的配置时，组成员之间交换它们的一些元数据来同步协作结果并保持持续协作。这些信息在属于组中的所有成员之间共享，因此，可以从组中的任何活跃成员查询到一致性的关于所有组成员的信息。如下：
mysql> SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 041f26d8-f3f3-11e8-adff-080027337932 | example1 | 3306 | ONLINE | SECONDARY | 8.0.13 |
| group_replication_applier | f60a3e10-f3f2-11e8-8258-080027337932 | example2 | 3306 | ONLINE | PRIMARY | 8.0.13 |
| group_replication_applier | fc890014-f3f2-11e8-a9fd-080027337932 | example3 | 3306 | ONLINE | SECONDARY | 8.0.13 |
+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+复制
根据这个结果，我们可以看到这个组由三个成员组成、每个成员的主机和端口号(客户端用来连接到该成员的SQL访问端口，非组成员内部的通讯端口)、以及该成员的server_uuid、MEMBER_STATE列显示组中所有成员都为ONLINE状态、MEMBER_ROLE列显示组中有两个辅助节点和一个主要节点（表示该组运行在单主模式下）、MEMBER_VERSION列显示每个组成员运行的MySQL Server版本（这在对组复制拓扑做升级操作时非常有用）。
PS：有关Member_host列值及其对分布式恢复过程的影响的更多信息，请参见上文中“2.1.3. 用户凭证”部分。
3.3. performance_schema.replication_group_member_stats表
组复制中的每个成员都会各自对从组中接受的事务进行冲突认证检测，然后进行应用。该表中记录了有关从组中接受事务以及应用事务相关的统计信息，这些统计信息对于了解applier队列如何增长、发现了多少冲突事务、验证了多少事务、在什么地方提交了哪些事务等等都很有用。
performance_schema.replication_group_member_stats表提供与认证过程相关的组级别统计信息，还提供组复制中每个成员接收和发起的事务的统计信息。这些信息在组中所有成员之间共享，因此可以从任何组成员查询到关于所有组成员的统计信息。注意，远程成员中的统计信息刷新频率由系统变量group_replication_flow_control_period指定，因此，这些统计信息可能与在发起事务（本地事务）的组成员中查询到的统计信息略有不同。此表中记录的组成员状态信息类似如下：
root@localhost : (none):07: > SELECT * FROM performance_schema.replication_group_member_stats\G
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
VIEW_ID: 15692965051216743:7
MEMBER_ID: 2d283e92-de7b-11e9-a14d-525400c33752
COUNT_TRANSACTIONS_IN_QUEUE: 0
COUNT_TRANSACTIONS_CHECKED: 342710
COUNT_CONFLICTS_DETECTED: 0
COUNT_TRANSACTIONS_ROWS_VALIDATING: 0
TRANSACTIONS_COMMITTED_ALL_MEMBERS: 320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-342718
LAST_CONFLICT_FREE_TRANSACTION: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:342718
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
COUNT_TRANSACTIONS_REMOTE_APPLIED: 342711
COUNT_TRANSACTIONS_LOCAL_PROPOSED: 0
COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0
*************************** 2. row ***************************
CHANNEL_NAME: group_replication_applier
VIEW_ID: 15692965051216743:7
MEMBER_ID: 2e33b2a7-de7b-11e9-9a21-525400bdd1f2
COUNT_TRANSACTIONS_IN_QUEUE: 0
COUNT_TRANSACTIONS_CHECKED: 342710
COUNT_CONFLICTS_DETECTED: 0
COUNT_TRANSACTIONS_ROWS_VALIDATING: 0
TRANSACTIONS_COMMITTED_ALL_MEMBERS: 320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-342718
LAST_CONFLICT_FREE_TRANSACTION: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:342718
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
COUNT_TRANSACTIONS_REMOTE_APPLIED: 342710
COUNT_TRANSACTIONS_LOCAL_PROPOSED: 0
COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0
*************************** 3. row ***************************
CHANNEL_NAME: group_replication_applier
VIEW_ID: 15692965051216743:7
MEMBER_ID: 320675e6-de7b-11e9-b3a9-5254002a54f2
COUNT_TRANSACTIONS_IN_QUEUE: 0
COUNT_TRANSACTIONS_CHECKED: 342713
COUNT_CONFLICTS_DETECTED: 0
COUNT_TRANSACTIONS_ROWS_VALIDATING: 0
TRANSACTIONS_COMMITTED_ALL_MEMBERS: 320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-342718
LAST_CONFLICT_FREE_TRANSACTION: aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:342718
COUNT_TRANSACTIONS_REMOTE_IN_APPLIER_QUEUE: 0
COUNT_TRANSACTIONS_REMOTE_APPLIED: 4
COUNT_TRANSACTIONS_LOCAL_PROPOSED: 342713
COUNT_TRANSACTIONS_LOCAL_ROLLBACK: 0
3 rows in set (0.01 sec)复制
上述查询到的组成员状态信息对于监控组中活跃成员（已建立组通讯连接的成员）的性能非常重要。例如：假设与其他成员相比，组中的某个成员的状态中总是发现队列中存在大量事务。这意味着该成员可能存在大量事务延迟，无法与组中的其他成员保持数据同步。根据这些信息，可以决定是否需要从组中删除该成员，或者延迟处理组中其他成员的事务，以减少队列中的事务数量。这些信息还可以帮助确定如何调整MGR插件的流控阈值
文章转载自IT界数据库架构师的漂泊人生，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
评论
相关阅读
【MySQL 30周年庆】MySQL 8.0 OCP考试限时免费！教你免费领考券
墨天轮小教习
2768次阅读
2025-04-25 18:53:11
MySQL 30 周年庆！MySQL 8.4 认证免费考！这次是认真的。。。
严少安
816次阅读
2025-04-25 15:30:58
【活动】分享你的压箱底干货文档，三篇解锁进阶奖励！
墨天轮编辑部
474次阅读
2025-04-17 17:02:24
MySQL 9.3 正式 GA，我却大失所望，新特性亮点与隐忧并存？
JiekeXu
418次阅读
2025-04-15 23:49:58
3月“墨力原创作者计划”获奖名单公布
墨天轮编辑部
368次阅读
2025-04-15 14:48:05
记录MySQL数据库的一些奇怪的迁移需求！
陈举超
265次阅读
2025-04-15 15:27:53
MySQL 8.0 OCP 1Z0-908 考试解析指南(二)
JiekeXu
254次阅读
2025-04-30 17:37:37
SQL优化 - explain查看SQL执行计划（下）
金同学
241次阅读
2025-05-06 14:40:00
MySQL 8.4 新特性深度解析：功能增强、废弃项与移除项全指南
JiekeXu
221次阅读
2025-04-18 20:21:32
MySQL 8.0 OCP 1Z0-908 考试题解析指南
青年数据库学习互助会
204次阅读
2025-04-30 12:17:54
