问题和预案

这是学习笔记的第 1962 篇文章

  今天可以说是忙得深沉，我就挑几件事情说一下吧。

早上刚到公司，就碰到一个MGR的多活环境脑裂，现象是原来的异地多主节点状态为只读，写入不了数据了。按照分布式的路子来进行修复，重新停止组复制，然后重新开启，可以看到节点2尝试加入集群的时候是开始恢复流程了。

但是恢复了一会，就退出了集群。错误日志如下：

2019-04-28T01:47:01.284700Z 0 [Note] Plugin group_replication reported: 'Group membership changed to test_db:4306, test_db2:4306 on view 15562750832975492:4.'

2019-04-28T01:47:58.925923Z 103395 [ERROR] Slave SQL for channel 'group_replication_applier': Worker 5 failed executing transaction '1bb1b861-f776-11e6-be42-782bcb377193:9574063'; Could not execute Update_rows event on table devopsdb.redis_backup_result; Can't find record in 'redis_backup_result', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND, Error_code: 1032

2019-04-28T01:47:58.926928Z 103390 [Warning] Slave SQL for channel 'group_replication_applier': ... The slave coordinator and worker threads are stopped, possibly leaving data in inconsistent state. A restart should restore consistency automatically, although using non-transactional storage for data or info tables or DDL queries could lead to problems. In such cases you have to examine your data (see documentation for details). Error_code: 1756

2019-04-28T01:47:58.926947Z 103390 [Note] Error reading relay log event for channel 'group_replication_applier': slave SQL thread was killed

看这个错误是一个备份记录表的数据产生了不一致，在多主模式下进行数据修复还是有一些复杂度的，好在这两个业务是不相关的，出现问题的数据库所在的业务目前的使用率不高，所以影响不大，而原本的运维系统的使用率较高，如果中间断了几分钟，不一会都会收到服务影响的反馈。

所以在这种情况下还是带着一些压力的，多主的环境出现这种问题其实是比较纠结的，因为这个问题就算修复好，还不能确定是否其他表也有类似的问题，第二是这种多主的环境使用pt-slave-restart是没法做修复的。 

所以摆在我面前的可行方案有几种，一种就是重新做异机环境，数据量不大，但是实在是降低了技术难度，可以作为备选方案，另外就是一鼓作气来修复问题。 

这个问题是找不到相关表的记录，手工修复本身是存在一些重复性和复杂性的，为了圈定问题的范围，就把参数slave_exec_mode改为了indepent,很快就收到了重新恢复中的错误提示，但是因为这个设置了这个模式，错误很快就忽略了。而对于这个问题的持续补救是通过pt工具来进行比对，做数据修复，整体恢复之后，发现报错存在问题的确实只有这一个表，所以问题的解决也就比较清晰了。

  然后做了下未雨绸缪的事情，马上到五一假期了，我是非常反感在节假日期间处理一些常规的问题，比如磁盘空间报警。所以这个工作完全可以前置，结果一梳理，自己也吓一跳，有几套环境的报警竟然被自动忽略了，根据阈值的80%，目前还是存在较大的问题的。所以对于这个问题的处理，本来设想了蛮高大上的回归模型来解决，来做下预测，最后先做了一个通用一刀切的方案，即做阈值前置，比如阈值80%有问题，那么我们把阈值前置为75%，这样在短时间内就不会出现这类问题了。

刚忙活完，然后又开始处理一个数据流转的问题，这个问题说起来其实挺纠结的。

是碰到了GTID模式下的一个bug，从库复制自动停止了。结果数据表在主库存在，但是从库不存在，问题是数据流转是通过从库来做的，所以业务方那边是迟迟没有收到数据更新，处理这个问题着实让我费神，先定位到这个问题，结果发现从库的配置不够规范。寄希望于pt-slave-restart来修复，结果修复的时候发现不可行。对于这个问题我做了两手准备，一边开始重新备份数据，同时在从库继续尝试恢复。同时业务同学也时不时让我手工做下数据流转，一来而去，整个场景就变得有些复杂了。最后为了快速恢复业务，重新做了从库。总体来说虽然做了一些尝试，也重做了从库，但是总体上进度是相对可控的。

查问题，做预案，两者都不耽搁。