MGR MYSQL 集群崩溃恢复，及非正常手段修复

Posted 2021-04-26 AustinDatabases

生产即将部署mysql  MGR 的环境，进行对接银行的项目，在测试系统上进行测试了的两个月的MGR 没有任何问题，出过一次问题，还是开发人员不大熟悉MYSQL 的原理，使用了大事务，将MYSQL MGR 卡死，经过几分钟的处理，一切正常，基本上几百万的数据的查询都在秒级。完全不逊色其他数据库产品的响应。

最近出了事情，所以必须要对任何系统的上线进行严控，这边MYSQL MGR 上线需要进行严格的上线测试，得到目前MYSQL 集群能HOLD 住的数据量，这样才能给运维和开发一个参数和数据承受范围，避免一些不好的事情出现。

将SYSBENCH 搭建在 PROXYSQL 中间件上，开始压测，初始没有任何问题，后面加大压测的数据量，30个表每个表500MB，30个线程，持续5分钟，在PERPARE的时候，发现到第10个表系统已经没有反应了，查询了内存已经开始使用了 SWAP了，应该是内存已经爆了，停止系统的线程，发现无法停止。SHOW PROCESSLIST; 

发现大量 insert into 的语句开卡在线程池里面，手动清理，无效。

无意之间查看了磁盘空间，OMG，UNDO LOG 和 RELAY LOG 的空间已经爆了，100%的使用率。

此时查询集群的状态，集群已经处于失败的状态，（图没有留，下面的图中的 MEMBER_STATE,应该是OFFILINE 的状态了）

此时集群已经散掉了，查看日志，其实日志已经在昨天就已经报警了（因为压力测试是前天做的，但是由于突发情况就没有再管压力测试，几天在测，发现已经出了问题）

没有良好的系统测试，无论是硬件方面的还是软件方面的，都为未来的“重击”买下了伏笔。

所幸，本次做了，所以在系统上线前发现了问题。

下面就是修复，在通知运维的同学后，添加了磁盘空间，然后系统重新集群的搭建和启动。（MYSQL MGR 还是很健壮的，只是重启了集群，将失败的节点添加）

但此时第二个问题出来了，由于RELAY LOG的磁盘空间问题，已经有很多日志挤压了.

最省事的方法就是BACKUP 主库，然后在 RESTORE   到从库，从起MGR 就可以了。如此也就放弃了，更深层次修复的MGR的技巧。首先我们先强制从节点启动，马上一堆挤压的LOG 开始执行，由于在当时为了磁盘空间的问题，已经在主库和从库都删除了测试数据库。（仅仅为了试验，上线的绝对禁止）

洪水一般的日志向STANDBY节点袭来，都是报日志与当前操作的环境不一致之造成的报错，当下还是一直的执行，但后面突然停下来，原来是DROP DATABASE 这样的操作又被卡主了，（这和MYSQL当时的可以容忍的复制ERROR有关，DDL操作是不能容忍的错误）这下数据库从节点彻底锁死。

好吧那就开始修复集群。

 （不熟悉MGR 和 GTID 原理的估计看下面就开始费劲了）

1 我们查看主节点的GTID 号

2620d5df-07e7-11e9-8fa8-005056ad4145:1-2740,

81f38f19-09d2-4144-8925-484ad1cb5c6f:1-1002,

bf79695c-0e78-11e9-9c14-005056ad1469:1

主库的日志已经到了这个GTID 并且 是 MYSQL-BIN.000012

2 我们在看从库的状态

果然是不一样，当然应该不一样，要不集群就不会是失败的状态。

3 开始修复

我们先停止从节点

stop group_replicatiton;

清空当前GTID EXECUTED

reset master；

设置和主节点一样的 EXECUTED_GTID_SET

启动复制

start group_replication;

再次查看修复的那个从节点的状态，已经上线了

查看对应的日志，OK 已经和主同步了，（如果你熟悉GTID的原理你就知道为什么了）

使用此种手段，修复第二个节点

修复成功，集群恢复工作。

再次验证是否还有挤压的 TRANSACTION LOG

没有了，当然没有了。

此种方法使用是有条件的，要根据当前的状态，如果是复杂的状态，还是建议用传统的方法来进行恢复，不过如果你对你的MYSQL MGR 集群和相关系统的运作了解，你可以在紧急的状况或测试环境做一遍，对了解MGR的原理和紧急状态的修复会受益匪浅。

 这也从另一点上验证了，系统上线前不做测试，那纯属找死。