故障开始时间：2023-06-30 09:18 故障实例：BI大数据业务
环境
- 系统：CentOS Linux release 7.8.2003 (Core)
- MySQL: 5.7.28-log MySQL Community Server (GPL)
- 部署：多实例部署，当前实例bufferPool:8G
- 集群：3台主机
- 主：51
- 备：52 (和51做双主)
- 从：53 （同步自52）
故障现象
- 收到报警，该实例频繁报连接异常和恢复
- 检查发现该MySQL实例频繁重启
- 1.该实例访问量很小，不是资源不足引起
- 2.和研发确认该实例相关的业务最近未发生变更
- 3.DBA内部确认最近该实例没有做配置变更
- 4.报错时系统日志无异常报错
- 5.MySQL正常运行时可以提供服务，但1分钟左右就会自动shutdown
- 6.慢日志里没有异常SQL
- 7.MySQL错误日志里只有实例启动后自检的warinning 以及
2023-06-30T10:15:35.534553+08:00 0 [Warning] CA certificate ca.pem is self signed.
2023-06-30T10:15:35.546909+08:00 0 [Warning] Recovery from master pos 59075485 and file mysql-bin.***** for channel ''. Previous relay log pos and relay log file had been set to 416, /data/mysql******/relaylognew/relay-bin.***** respectively.
处理过程
- 检查日志和监控，找不到异常点
- 开全日志，刷屏全量SQL,观察是否有异常SQL （无）
- 因为错误日志反复刷relayLog和主从连接异常
- 尝试断主从复制
断主从复制
- 断开 51到52的同步，观察问题依旧
- 断开 52到51的同步，观察问题依旧
- 清理主从信息 ，问题依旧
- 此时还是会刷relaylog的异常。
- 确认跟主从同步没关系
- 检查52备实例的状态，确认备库是正常的。
- 联系业务，准备把主库切到51上
切主库
- 和业务沟通后，大群里发临时切换通知
- 恢复51到52的数据同步，在检查到已经追上gtid后
- 开52写，关51写，确认一致后
- 数据库流量切到51上，观察连接
- 确认没有问题，研发回去检查日志后，说报readonly错
- 以为是应用有连接缓存
- 让研发重启应用试试。
- 同时排查51库上的连接。发现没有连接
- 检查52状态，发现readonly
- 关掉52的readonly .研发反馈好了
- 1分钟后，又报readonly
- 再看52又readonly了。
- 这时我发现问题复发了
- 肯定是my.cnf里漏掉了修改
- 也就是说切换到52以后，还是会不停的重启
- 修改52的my.cnf.
- 确认切库到新的机器后，还是会无限重启
- 继续排查52实例的反复重启问题
- 此时将注意力放在排查异常SQL上
排查异常SQL
- 跟研发沟通停掉部分业务观察
- 停掉以后，观察5分钟，未再发生重启
- 研发共有3个相关应用
- 启动应用1，数据库很快进入无限重启状态
- 停应用1，启应用2，数据库还是会重启
- 停应用1，3，启应用3，数据库还是会重启
- 判断无论启哪个应用都会导致数据库重启
- genlog里还是没有明显异常（太多了，也不好定位）
- 停应用1，2，3后，数据库会偶尔重启
- 此时数据库有连接过来
- 判断停应用不彻底
- 计划停高频访问的4个MySQL账号
禁账号
- 因为上面的停应用找异常没找到问题点
- 沟通后，我们停账号来筛选问题
- 找到4个可以停的，访问较多的账号
- 直接锁了
- 问题依旧（只是重启频繁变低，4-5分钟会重启一次）
- 怀疑是触发了MySQL的bug
- 因为该实例有版本升级计划
- 和研发沟通直接升MySQL版本到8.0
升MySQL8.0
- 跟研发沟通升级事宜
- 确认可以1个小时内完成版本升级
- 把已下线的51节点（原主实例）升级到MySQL8.0.22
- 把51和52做双向同步
- 在做同步时因为是不同版本的MySQL
- 出现
Slave failed to initialize relay log info structure from the repository报错 - 清空51和52的relaylog
- 手动重启了52的MySQL
- 等双向同步做好以后
- 却发现故障恢复了
- 52不再频繁重启了
- 和研发确认业务是否都已恢复
- 确认都恢复了
- 最终定位于两步：
- 1.清空了relayLog 2.手动重启了实例
- 这两步操作中的一步恢复了故障
- 倾向于清空relaylog这一步起了关键作用
后续
- 故障在计划外恢复了
- 正在觉得蹊跷时
- 发现53从库也跟着出现无限重启问题
- 备份relaylog文件夹
- 清空重启
- 故障也恢复了
- 留下来一个故障时的relaylog
- 解析relaylog
- 却没发现有任何异常点
- 一次意外的无限重启故障
- 一次意外的恢复
- 目前还没找到明确的可信服的点
附：
