一次 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