一次 MySQL 误操作导致的事故，「高可用」都顶不住了！

你好，我是悟空。

上次我们项目不是把 MySQL 高可用部署好了么，MySQL 双主模式 + Keepalived，来保证高可用。简单来说就是有两个 MySQL 主节点，分别有两个 Keepalived 安装在宿主机上监控 MySQL 的状态，一旦发现有问题，就重启 MySQL，而客户端也会自动连接到另外一台 MySQL。

详情可以看悟空写的这篇：实战 MySQL 高可用架构

这次是我们在项目中遇到的一次事故，来一起复盘下吧。

本文目录如下：

事故现场

• 环境：测试环境
• 时间：上午10:30
• 反馈人员：测试群，炸锅了，研发同事初步排查后，发现可能是数据库问题。

然后就开始找原因吧。因为这套集群环境是我部署的，所以我来排查的话轻车熟路。

系统部署图

先说下系统的部署图，方便大家理解。

两个数据库部署在 node55 和 node56 节点上，他们互为主从关系，所以叫做双主。

还有两个 Keepalived 部署在 node55 和 node56 上面，分别监控 MySQL 容器的状态。

报错原因和解决方案

• ① 我个想法就是，不是有 Keepalived 来保证高可用么，即使 MySQL 挂了，也可以通过 Keepalived 来自动重启才对。即使一台重启不起来，还有另外一台可以用的吧？

• ② 那就到服务器上看下 MySQL 容器的状态吧。到 MySQL 的两台服务器上，先看下 MySQL 容器的状态，docker ps  命令，发现两台 MySQL 容器都不在列表中，这代表容器没正常运行。

• ③ 这不可能，我可是安装了 Keepalived 高可用组件的，难道 Keepalived 也挂了？

• ④ 赶紧检查一波 Keepalived，发现两台 Keepalived 是正常运行的。通过执行命令查看：systemctl status keepalived

• ⑤ 纳尼，Keepalived 也是正常的， Keepalived 每隔几秒会重启 MySQL，可能我在那一小段空闲时间没看到 MySQL 容器启动？换个命令执行下，docker ps -a，列出所有容器的状态。可以看到 MySQL 启动后又退出了，说明 MySQL 确实是在重启。

• ⑥ 那说明 Keepalived 虽然重启了 MySQL 容器，但是 MySQL 自身有问题，那 Keepalived 的高可用也没办法了。

• ⑦ 那怎么整？只能看下 MySQL 报什么错了。执行查看容器日志的命令。docker logs 。找到近发生的日志：

• ⑧ 提示 mysql-bin.index 文件不存在，这个文件是配置在主从同步那里的，在 my.cnf 配置里面。

这个配置好后，然后执行主从同步的时候，就会在 var/lib/mysql/log 目录下生成多个 mysql-bin.xxx 的文件。还有一个 mysql-bin.index 索引文件，它会标记现在 binlog 日志文件记录到哪里了。

mysql-bin.index 文件里面的内容如下：

/var/lib/mysql/log/mysql-bin.000001