MGR 部署

集群拓扑
ip1:3308
ip2:3308
ip3:3308

MGR重要参数及说明
gtid_mode=ON
enforce_gtid_consistency=ON
binlog_gtid_simple_recovery = 1
binlog_checksum=NONE
slave_parallel_workers=16
transaction_write_set_extraction=XXHASH64
loose-group_replication_enforce_update_everywhere_checks = OFF
loose-group_replication_single_primary_mode = ON
loose-group_replication_group_name="aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
loose-group_replication_start_on_boot=off
loose-group_replication_local_address= "ip1:33081"
loose-group_replication_group_seeds= "ip1:33081,ip2:33081,ip3:33081"
loose-group_replication_bootstrap_group= off
report_host=ipx
report_port=3308
loose-group_replication_ip_whitelist="10.xx.0.0/16,127.0.0.1/8"

在主节点进行操作
/usr/local/mysql/bin/mysql_upgrade    -S /data/mysql3308/run/mysql.sock -udbadmin -p
登录mysql安装MGR插件，并进行初始化和启动MGR
master386>INSTALL PLUGIN group_replication SONAME 'group_replication.so';
master386>set global group_replication_bootstrap_group=on;
master386>start group_replication;
master386>set global group_replication_bootstrap_group=off;
master>SELECT * FROM performance_schema.replication_group_members;
master>show global variables like  '%seed%';
 
在从节点进行如下操作
切换到mysql用户下进行操作数据初始化操作
 /usr/local/mysql/bin/mysql_upgrade    -S /data/mysql3308/run/mysql.sock -udbadmin -p
登录mysql，安装MGR查询并加入MGR
slave>INSTALL PLUGIN group_replication SONAME 'group_replication.so';
slave>CHANGE MASTER TO MASTER_USER='xxx', MASTER_PASSWORD='xxx' FOR CHANNEL 'group_replication_recovery';
slave>start group_replication;
slave1>SELECT * FROM performance_schema.replication_group_members;     

查看主节点
查看单主masterMySQL5.7 不象MySQL8，不可以用replication_group_members直接显示要用
SHOW STATUS LIKE  'group_replication_primary_member';

MGR要求及限制

MGR要求及限制_mgr限制_jnrjian的博客-CSDN博客

MGR 掉节点怎么恢复？

启动 mysql 实例后执行 start group_replication 

这个命令会进行本地恢复：应用自己本地 relay log 中的日志

全局恢复：从集群中活跃的节点中任选一个作为 donor，用 recovery 线程 dump 它的binlog来恢复自己的数据

MGR 如何判断拉取哪些binlog？

恢复线程 建立与 donor 的复制关系，该函数携带了待恢复节点的 gtid_executed 信息。

donor 端逆序遍历 binlog 文件，通过判断 binlog 文件的 Previous-GTIDs 来找到第一个不属于 gtid_executed 的事务，从该事务开始进行数据复制。

命令执行过后，观察 replication_group_members 表的数据，如果目标节点的状态是 ONLINE，则视为集群恢复成功。
如果操作并未成功，日志会有报错：the master has purged binary logs containing GTIDs that the slave requires  意思是：节点脱离集群时间过长，已无法通过现存节点的 binlog 直接恢复了

这个时候需要重做全量数据，先清除这个下线节点的信息，然后创建一个新的实例，选择任一正常节点进行数据全量备份，并将其应用至新实例上。
全量数据恢复完成后，执行 start group_replication 命令，开启 MGR 同步，追平数据后，MGR 会将节点状态置为 ONLINE，然后开始正常接收流量请求。

MGR 如何判断从哪个GTID开始拉取增量数据？

在传统的主从复制中，DBA 需要在 change master 时手动设置增量同步开始的 GTID或pos

MGR 同步时只需要指定用户名密码即可。那它是怎么找点的呢？

不同的备份方式，对应着不同的找点方式，下面以 mysqldump 为例

mysqldump 全量数据，使用 gtid_purged 记录备份时已经执行过的事务：

mysqldump --set-gtid-purged=ON --single-transaction --all-databases -uroot -p -h 127.0.0.1 > mgr.sql

查看生成的 sql 文件，可以看到开始处有相关标识：

set @@GLOBAL.GTID_PURGED='XXXXXX'

在新节点上使用如下命令：
STOP GROUP_REPLICATION;
reset master;
接下来 source mgr.sql  (包含了set @@GLOBAL.GTID_PURGED='XXXXXX')
source完成后，START GROUP_REPLICATION，就会自动跳过这些标识为 purged 的事务了

 

MGR 常用命令

#gtid
show global variables like '%gtid%'\G;
select @@server_uuid;
select * from  performance_schema.replication_connection_status\G
show global variables like '%seed%';
SELECT * FROM mysql.gtid_executed;
show master status\G;

#mgr master
SHOW STATUS LIKE 'group_replication_primary_member';
select @@server_id;
select @@server_uuid;
SELECT ta.* ,tb.MEMBER_HOST,tb.MEMBER_PORT,tb.MEMBER_STATE FROM performance_schema.global_status ta,performance_schema.replication_group_members tb  WHERE ta.VARIABLE_NAME='group_replication_primary_member' and ta.VARIABLE_VALUE=tb.MEMBER_ID;

select * from performance_schema.replication_group_members;