CTO问我：MySQL从节点上的服务崩了，还怎么「主从读写分离」？

背景

我们的项目采用了读写分离的方案：查询和更新的业务走主库，统计相关的功能走从库，从而减少主库的压力。原理如下图所示：

​

编辑切换为居中

添加图片注释，不超过 140 字（可选）

读写分离的方案

如果从库崩了，实在无法访问了，就会把所有请求打到主库上。原理如下图所示：

​

编辑切换为居中

添加图片注释，不超过 140 字（可选）

从节点崩了，部分流量打到主节点

但是最近遇到一个问题，MySQL 从节点上的服务无缘无故的崩了，查看日志也找不到什么端倪。

为了保证从节点的可用性，我们使用了 Keepalived 软件来监测从节点存活状态，如果从节点崩了，则自动重启 MySQL 容器。

本篇将会讲解没什么卵用的排查记录，以及如何保证从节点可用性，注意，还不是完全的高可用。

一、排查记录

虽说没有找到 MySQL 从节点容器真正崩了的原因，但是这排查记录还是得记录下。

1.1 查看 MySQL 的容器日志

docker logs 043 --tail 200

2023-02-08 6:27:30 开始 Shutdown 了，没有提示为什么 shutdown。

​

编辑切换为居中

添加图片注释，不超过 140 字（可选）

2023-02-08 6:27:34 Shutdown 完成。

​

编辑切换为居中

添加图片注释，不超过 140 字（可选）

1.2 查看 MySQ