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