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

一次 MySQL 误操作导致的事故,「高可用」都顶不住了!插图亿华云

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

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

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

本文目录如下:

一次 MySQL 误操作导致的事故,「高可用」都顶不住了!插图1亿华云

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

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

系统部署图

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

两个数据库部署在 node55 和 node56 节点上,他们互为主从关系,所以叫做双主。一次 MySQL 误操作导致的事故,「高可用」都顶不住了!插图2亿华云

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

一次 MySQL 误操作导致的事故,「高可用」都顶不住了!插图3亿华云

​报错原因和解决方案

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

② 那就到服务器上看下 MySQL 容器的状态吧。到 MySQL 的两台服务器上,先看下 MySQL 容器的状态,docker ps

THE END
Copyright © 2024 亿华云