MySQL从节点上的服务崩了后如何做主从读写分离？

背景我们的项目采用了读写分离的方案查询和更新的业务走主库统计相关的功能走从库从而减少主库的压力。原理如下图所示读写分离的方案如果从库崩了实在无法访问了就会把所有请求打到主库上。原理如下图所示从节点崩了部分流量打到主节点但是最近遇到一个问题MySQL 从节点上的服务无缘无故的崩了查看日志也找不到什么端倪。为了保证从节点的可用性我们使用了 Keepalived 软件来监测从节点存活状态如果从节点崩了则自动重启 MySQL 容器。本篇将会讲解没什么卵用的排查记录以及如何保证从节点可用性注意还不是完全的高可用。一、排查记录虽说没有找到 MySQL 从节点容器真正崩了的原因但是这排查记录还是得记录下。1.1 查看 MySQL 的容器日志docker logs 043 --tail 2002023-02-08 6:27:30 开始 Shutdown 了没有提示为什么 shutdown。2023-02-08 6:27:34 Shutdown 完成。1.2 查看 MySQL 的错误日志cat /var/log/mysql/error.log 这个路径在 my.cnf 配置。可以看到 6:27:30 没有异常日志。这不就尴尬了完全不知道为啥崩了。备注另外也可以看下容器的信息docker inspect 容器 id会显示容器什么时候启动和停止的。二、怎么理解读写分离读写分离有个限制条件就是主库可以用来做读写从库实时同步主库数据而且从库是只读的。我们的项目中有统计功能就是连接从库查询数据从库不会进行数据更新的操作。读写分离我认为可以分为两种1、完全的读写分离主库只用来更新数据从库只用来查询数据。2、部分读写分离主库既可以用来读数据又可以进行查数据从库作为只读的备库分担耗性能的查询工作。我们项目采用的是第二种方案涉及到 I/O 密集型的查询工作就交给 MySQL 从库去处理。部分读写分离三、从节点的高可用如何保证3.1 保证从节点的可用性采用 keepalived 自动检测 MySQL 服务是否正常如果不正常自动重启 MySQL 容器。提高从节点的可用性3.2 从节点数据库无法重启了怎么办目前从节点只有一个节点如果从节点崩了从哪执行查询有两种方案方案一读操作切换到主库去查询。带来的问题主库的压力会很大。方案二部署两个从节点从节点之间相互同步数据只有一个从节点提供服务另外一个节点作为备用从库前者崩了的话流量自动切换到后者。需要两个节点开启 Keepalived 来提供流量切换的能力带来的问题部署的复杂性主从同步延迟。目前我们采用的是第一种方案如果从节点崩了读操作会切换到主库上去执行。所以保证从节点不崩就很重要了。四、实践保证从节点的可用性这次我们要做的就是在在从节点开启 Keepalived以及修改重启 MySQL 的脚本。从节点的 Keepalived 的 VIP 地址和主节点的 Keepalived 的 VIP 不一样。原理如下所示从节点首先得安装和配置 keepalived 在之前的文章中已经详细讲解过了。我在讲解主主切换的文章中提到过 keepalived 承担的职责是就是监测 MySQL 服务是否正常如果不正常则重启 MySQL如果重启失败则退出 keepalived自动将流量切换到另外一个节点。这次的从节点只作为备库没有切换到主库的要求所以在主库宕机后不需要接管读写的流量。4.1 启动 keeaplived 服务以及开机自启动安装好 keepalived 之后执行以下命令启动。systemctl start keepalived启动 keeaplived 服务还需要设置 keepalived 开机自启动。sudo vim /etc/rc.local 添加以下命令 systemctl start keepalived具体内容可以看这篇实战 MySQL 高可用架构实战 MySQL 高可用架构目录4.2 如何监测 MySQL 服务的健康状况keepalived 配置文件中定时监测 MySQL 服务的健康状况。修改配置文件sudo vim /etc/keepalived/keepalived.conf4.3 如何自动重启 MySQL 服务自动重启 MySQL 的脚本之前也讲解过这里再贴一下。当 keepalived 检测到 MySQL 无法连接时就自动重启 MySQL 容器。如何自动重启 MySQL 服务4.3 如何不让 Keepalived 切换流量到其他机器因为主节点也是开启了 Keepalived如果主从的 Keepalived 的 VIP 都是同一个之前配置的是 192.168.56.88那么如果主节点崩了就会将流量自动切换到从节点因为我们这个从节点只作为备库不需要它升级为主库所以可以将主从节点的 Keepalived 的 VIP 设置为不一样这样的话从节点就不会升级为主节点。这里我们就把之前的 VIP 192.168.56.88 改为 192.168.56.89。修改配置文件sudo vim /etc/keepalived/keepalived.conf如何自动重启 MySQL 服务同时重启脚本中有一行命令是强制退出 keepalivedkillall keepalived这行命令可以让 Keepalived 就有将流量切换到其他机器的能力。如果让 keepalived 强制退出则会将流量切换到另外一台 keepalived 还存活的机器上。这里不需要切换就可以注释掉这行命令。五、总结我们项目采用了数据库读写分离的模式但是没有对从节点做高可用所以也遇到从节点不能提供服务的问题。本篇通过一次 MySQL 从节点崩了的事件引出了如何对从节点做高可用然后从实践的角度详细讲解了如何去配置 keepalived 来保证从节点的高可用。