mysql怎么排查故障,mysql故障恢复

MySQL之MGR成员故障导致整个集群不可用的问题排查分析

2020-08-14

右玉网站制作公司哪家好，找成都创新互联公司！从网页设计、网站建设、微信开发、APP开发、成都响应式网站建设等网站项目制作，到程序开发，运营维护。成都创新互联公司从2013年创立到现在10年的时间，我们拥有了丰富的建站经验和运维经验，来保证我们的工作的顺利进行。专注于网站建设就选成都创新互联公司。

集群有三个成员memberA、B、C成，其中memberB意外故障停掉了，然后memberA 执行stop group_replication退去集群.此时整个集群不可用了（不能更新数据）。

集群中唯一剩余的成员memberC上看到的成员状态为：

但是memberA看到的状态为：

查看最后的存活的memberC的错误日志发现：

"Plugin group_replication reported: 'This server is not able to reach a majority of members in the group. This server will now block all updates. The server will remain blocked until contact with the majority is restored. It is possible to use group_replication_force_members to force a new group membership.' "

大概意思是当前的服务没法获取到成员的投票数，当前服务将会阻塞所有的更新，直到能够获取到投票数。可以使用group_replication_force_members 来强制组成一个新的组。

开始认为这是MGR功能的一个bug，不过后来想想这样的设定也是合理的，因为如果是当前的服务成员自身网络或其他问题导致的无法与其他成员的通信成功，那么这样的情况下这种设定也是合理的，因为不能让它自动重新组成一个组，否则就会可能出现多个重复的组。对于为什么组成员A执行stop group_replication后，剩余的memberC的视图中memberA还是online状态，可能是因为memberB已经unreachable,所以memberC去请求是否同意memberA退去时没有得到结果，一直阻塞等待造成的。此时，memberA的退出结果应该是无法多数投票通过的，因此memberA的退出结果应该是失败的。查看memberA的error日志，结果确实如此：

解决的方法是memberC也执行stop group_replication停掉这个组，再重新组成一个新的组。

此时memberA再重新加入就成功了：

结果：

以此类推，当有多个server组成的group而有多数成员已经意外故障时，导致整个组的停止更新，目前想到的解决的方法就是停掉现在的组，重新组成新的组。

ps:

增加Group Replication System Variables中group_replication_member_expel_timeout的大小，可以避免网络问题或执行事务慢造成的错误驱逐。

MySQL 问题排查都有哪些手段？

可以使用 show processlist 命令查看当前所有连接信息。

使用 explain 命令查询 SQL 语句执行计划。

开启慢查询日志，查看慢查询的 SQL。

记一次Mysql故障排查(lock wait timeout exceeded;try restarting transaction)

最近接了一个锅,进入新公司接手了一个进入交付阶段的项目.在code review的时候发现很多问题,然后开始修复bug.

在测试阶段突然发现几乎所有涉及到更新的操作都失败,下面贴出异常信息.

第一次 出现的时候百度了一下,猜想可能是多服务部署资源冲突,重启服务故障消失.所以没有特别重视

第二次 出现的时候只有测试环境部署,不存在多机资源冲突的问题,猜想是多线程资源交叉导致的,于是给可能导致资源竞争的地方加上了分布式锁.

由于无法重现故障,所以并没有确认问题得到解决.

第三次 故障依旧,当发现问题依然存在的时候,开始认真反思,发现自己解决问题的思路明显有问题,过于片面,一直都只在应用层面寻求解决问题的办法,而且解决问题的方式也只是在尝试百度出来的方法.并没有去思考更深层的问题.

在Mysql5.5中，information_schema 库中增加了三个关于锁的表（MEMORY引擎）；

INNODB_TRX ## 当前运行的所有事务

INNODB _LOCKS ## 当前出现的锁

INNODB_LOCK_WAITS ## 锁等待的对应关系

通过查询 INNODB_TRX 发现

当前事务中又两个RUNNING状态开始时间在一个小时之前

开始一直以为是锁表了

查看了 INNODB _LOCKS  事务信息之后发现有4行数据被锁住了一直没有释放

从这里开始发现问题了,应用已经抛了异常,事务理所当然的应该回滚才对,为什么资源依然没有释放,导致持续的阻塞呢?

其实最开始的异常信息就已经给出了答案,回到开始的地方,再看异常信息就很清楚了,应用里面的异常类是 MySQLTransactionRollBackException

是一个回滚异常, 这就说明在事务回滚的时候出了问题资源没有得到释放

然后开始查询 MySQLTransactionRollBackException  相关的信息

这个时候 innodb_rollback_on_timeout =0(默认配置)这个MySQL的配置开始进入我的视线,

举个栗子

事务在锁等待超时后是回滚事务内所有的statement还是最后一条语句；

0表示rollback最后一条语句，默认值； 有点坑爹啊( 细思极恐 )

1表示回滚事务内所有的statements；(此参数是只读参数，需在my.cnf中配置，并且重启生效；)

吃过一次亏,这次并没有盲目的相信百度到的信息

于是开始测试

一、验证innodb_rollback_on_timeout=off的情况

1.session A

开启事务,事务未提交,锁住id=1的数据

2.session B 

开启事务,执行更新id=2的数据成功(事务未提交,锁住id=2),然后请求id=1等待锁超时,id=2的数据更改为222.

3.session C

请求id=2的数据50秒后显示等待锁超时

执行 SELECT * FROM information_schema.INNODB_TRX;

可发现有资源一直未释放,具体到测试数据中就是id=2的资源一直被锁定,线程一直被挂起.

总结:通过实验基本可以确定是业务资源交叉导致死锁之后资源没释放造成的持续阻塞，

二.验证innodb_rollback_on_timeout=on

修改配置后将验证innodb_rollback_on_timeout=off的步骤再走一遍

发现锁等待只能在业务层面尽量避免

on/off的区别在于session C进入时不会持续阻塞,session B异常后全部回滚