MySQL-MGR(四)错误恢复

 

MGR 对网络要求很高,有的时候会因网络波动,自动退出集群的情况,此时需要先在出问题的节点停止组复制,然后再重新加入到集群中。

如下,该节点被踢出集群,直接执行Stop group_replication;报错:

 

 

需要先执行 stop group_replication 然后再 start group_replication:

Stop group_replication;

Start group_replication;

 

 2.节点启动长时间处于RECOVERING

 

 

 

 

  • 在主节点将密码的加密方式修改:

SET SQL_LOG_BIN=0;alter USER repl@'%' IDENTIFIED WITH mysql_native_password BY 'repl';GRANT REPLICATION SLAVE ON *.* TO repl@'%';GRANT BACKUP_ADMIN ON *.* TO repl@'%';FLUSH PRIVILEGES;SET SQL_LOG_BIN=1;
  • 再重启两个从节点:

STOP GROUP_REPLICATION;START GROUP_REPLICATION;
  • 2节点状态恢复正常:

 

 

  • 3节点状态恢复正常:

 

 3.数据异常修复

3.1暂时性恢复

MGR 对数据具有一定的容错性和最终一致性,原则上并不会出现数据不一致的情况,并且每次执行事务都会检测冲突,如果某个节点的数据因为异常导致不一致,切主节点的 binlog 丢失的情况,势必会导致集群数据不一致,此时可以通过以下的方法暂时让集群起来。

停止异常节点的组复制Stop group_replication;

清空当前的 GTID EXECUTEDReset master;

在异常节点将 GTID 事务号设置和主节点一致SET @@GLOBAL.GTID_PURGED='主节点的 GTID 号';

启动异常节点的组复制Start group_replication;

这里需要注意,这样的方式即使恢复了集群,因为 binlog 的缺失,实际上数据是不一致的,极有可能发生后续因为数据不一致导致集群出现问题,这里强烈不建议这么做。



4.分布式恢复

前面提到了暂时性的集群恢复,这样的恢复会有很大的问题,这里将阐述 MGR 正常的恢复方式。当 MGR 中新的成员加入节点时,通常有两种方法,当 binlog 全,或者 binlog 在删除前接入的节点能够成功继续往下同步的,则新加入的节点会继续同步下去,在 MySQL 8.0.21 版本中,可以通过设置参数:

group_replication_advertise_recovery_endpoints 

来进行指定点进行同步。

如果在 binlog 不可用或者差的数据实在太多的情况下,MySQL 在 8.0.17 后退出了克隆的方式进行恢复,即在集群中的所有 MySQL 节点上添加克隆插件,新加入的节点数据将会被全部删除,然后会被自动重新同步数据。

4.1节点分布式恢复

读节点重新加入环境。

模拟读节点重新加入,首先观察主节点的数据以及事务的情况:

此时将节点 3,清除所有数据,清除同步信息,重新初始化 MySQL,模拟成新节点。

  • 已有数据:

 

 

  • 删数据文件:

 

 此时3节点已经被集群踢出去了:

 

 

  • 重新初始化,启动,并登录:

初始化

mysqld --defaults-file=/etc/my.cnf --basedir=/usr/local/mysql --initialize-insecure --datadir=/data/3306/data --user=mysql &

 

启动

mysqld_safe --defaults-file=/etc/my.cnf --user=mysql & 

 

登录

mysql -u root

 

 

 

 

这里注意,因为 2 节点的的 IP 已经添加到了所有节点的 group_replication_group_seeds 中,所以不再添加,如果是新的 IP 加入节点,必须在所有其他节点上 group_replication_group_seeds 中添加新节点的IP。

  • 按照搭建 MGR 节点的步骤,将节点 2 添加到集群中:

Reset master;INSTALL PLUGIN group_replication SONAME 'group_replication.so';

CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='repl' FOR CHANNEL 'group_replication_recovery';

START GROUP_REPLICATION;

 

 

  • 已经重新加入到集群中,数据也同步回来:

  •  

     

     

     

    • 可以看到同步事务已经一致:

 

 

4.2克隆恢复

MySQL 8.0.17 后可以使用克隆恢复。

这里我们依然采用节点 3 作为需要接收克隆的节点。

  • 首先在源节点和接收克隆的节点添加克隆插件:

INSTALL PLUGIN clone SONAME 'mysql_clone.so';
  • 同样因为是组复制,所以节点 3 必须装组复制插件:

INSTALL PLUGIN group_replication SONAME 'group_replication.so';

 

 

  • 其次在提供克隆的节点上,也就是节点 1 上赋权:

CREATE USER clone_user@'%' IDENTIFIED by '123456';GRANT BACKUP_ADMIN ON *.* TO 'clone_user'@'%';
  • 在接收克隆的目标节点,也就是节点 2 上赋权:

CREATE USER clone_user@'%' IDENTIFIED by '123456';GRANT CLONE_ADMIN ON *.* TO 'clone_user'@'%';
  • 在接收克隆的目标节点上设置源端的白名单:

SET GLOBAL clone_valid_donor_list = '192.168.168.101:3360';
  • 为了验证克隆是否会清除接收端上的数据,这里我们多建几个 schema 在节点3执行:

CLONE INSTANCE FROM clone_user@'192.168.168.101':3360 IDENTIFIED BY '123456';
  • 完成之后,把节点3重新加入到集群:

CHANGE MASTER TO MASTER_USER='repl', MASTER_PASSWORD='repl' FOR CHANNEL 'group_replication_recovery';start GROUP_REPLICATION;
 
引用自数据和云公众号
posted @ 2022-01-29 17:13  Cetus-Y  阅读(477)  评论(0编辑  收藏  举报