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

小灰灰 2024-03-26 19:19 59阅读 0赞

本文目录如下：

![f98322b777707468a332402a2b4d5952.png][]

###  ###

事故现场

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

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

###  ###

系统部署图

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

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

![6f9559b3d2b3ad8d93cfb0c33f4ac527.png][]

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

![a9b1499b962c453e52b3c075bc579378.png][]

###  ###

报错原因和解决方案

*  ① 我第一个想法就是，不是有 Keepalived 来保证高可用么，即使 MySQL 挂了，也可以通过 Keepalived 来自动重启才对。即使一台重启不起来，还有另外一台可以用的吧？
 *  ② 那就到服务器上看下 MySQL 容器的状态吧。到 MySQL 的两台服务器上，先看下 MySQL 容器的状态，docker ps 命令，发现两台 MySQL 容器都不在列表中，这代表容器没正常运行。

![31cb8f19b2b9d36c73c045ef3038d5ff.png][]

[f98322b777707468a332402a2b4d5952.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/0ad9891b880d44548380876eda0a19cd.png
[6f9559b3d2b3ad8d93cfb0c33f4ac527.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/2dd688c71d114d95968238b19a775363.png
[a9b1499b962c453e52b3c075bc579378.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/10d8c465983c4c578a13b005d482e495.png
[31cb8f19b2b9d36c73c045ef3038d5ff.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/26/575ef1a878114be7a958436ae2500e7e.png