MGR架构测试

1.测试节点

节点一、10.2.83.133 (primary)

节点二、10.2.83.140(second)

节点三、10.2.83.141(second)

2.测试情形--单主

2.1 关闭防火墙

10.2.83.140节点开启防火墙

可以测试到该节点变为unreachable，当关闭防火墙，无法立刻加入集群，等了不知道多久自己恢复了，还需要再测试

 

日志报错

 在开启防火墙的状态进行start GROUP_REPLICATION; 日志报错如下

2.2 关掉节点二、三确认只有单节点一是否可以使用

节点一写存储过程，不停向节点一insert数据

如下insert存储过程

BEGIN
DECLARE num int ;
set num=1;
while num <10000000 DO
insert into t1 (name) values ('test1_t1_malong56');
set num=num+1;
end while;
END

调用存储过程

call proc_t1

节点二、三执行： systemctl stop mysqld

1>> 确认只有节点一可以正常读写。符合MGR允许最大故障数：f=(n-1)/2  三台只要一台存活就可以继续访问

2>> 节点二三重新启动， systemctl start mysqld  ，执行start group_replication;

可以发现状态为：recovering

group_replication_applier | a1cfaf71-5e1a-11ec-9d8a-005056a6b4be | node2       |        3306 | RECOVERING   | SECONDARY   | 8.0.20

查看有多少事务等待恢复，即确认主从延迟，说明有28692个事物等待同步，待变为online就为正常了

mysql> select COUNT_TRANSACTIONS_IN_QUEUE,LAST_CONFLICT_FREE_TRANSACTION from performance_schema.replication_group_member_stats where MEMBER_ID=@@server_uuid;
+-----------------------------+--------------------------------+
| COUNT_TRANSACTIONS_IN_QUEUE | LAST_CONFLICT_FREE_TRANSACTION |
+-----------------------------+--------------------------------+
| 28692 | |
+-----------------------------+--------------------------------+

 

2.3 测试关掉节点一，primary节点是否可以正常切换

1>> 节点一执行： systemctl stop mysqld

确认:primary节点切换到了节点三

 

 

 

 

 

2>> 原来的节点一重新启动，

systemctl start mysqld  ，执行start group_replication;

可以发现状态为：recovering，且角色为：SECONDARY

 

标签：systemctl,10.2,架构,replication,start,MGR,num,测试,节点
来源： https://www.cnblogs.com/liuxiuxiu/p/15842441.html