文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

从节点崩了,还怎么「主从读写分离」?

2024-11-30 17:31

关注

本篇主要内容如下:

目录

背景

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

读写分离的方案

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

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

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

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

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

一、排查记录

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

1.1 查看 MySQL 的容器日志

docker logs 043 --tail 200

2023-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>,会显示容器什么时候启动和停止的。)

二、怎么理解读写分离

读写分离有个限制条件就是主库可以用来做读写,从库实时同步主库数据,而且从库是只读的。

我们的项目中有统计功能就是连接从库查询数据,从库不会进行数据更新的操作。

读写分离我认为可以分为两种:

我们项目采用的是第二种方案,涉及到 I/O 密集型的查询工作就交给 MySQL 从库去处理。

部分读写分离

三、从节点的高可用如何保证?

3.1 保证从节点的可用性

采用 keepalived 自动检测 MySQL 服务是否正常,如果不正常,自动重启 MySQL 容器。

提高从节点的可用性

3.2 从节点数据库无法重启了怎么办?

目前从节点只有一个节点,如果从节点崩了,从哪执行查询?

有两种方案:

目前我们采用的是第一种方案,如果从节点崩了,读操作会切换到主库上去执行。所以保证从节点不崩就很重要了。

四、实践:保证从节点的可用性

这次我们要做的就是在在从节点开启 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.conf

4.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 服务

同时重启脚本中,有一行命令是强制退出 keepalived(killall keepalived),这行命令可以让 Keepalived 就有将流量切换到其他机器的能力。如果让 keepalived 强制退出,则会将流量切换到另外一台 keepalived 还存活的机器上。

这里不需要切换,就可以注释掉这行命令。

五、总结

我们项目采用了数据库读写分离的模式,但是没有对从节点做高可用,所以也遇到从节点不能提供服务的问题。

本篇通过一次 MySQL 从节点崩了的事件,引出了如何对从节点做高可用,然后从实践的角度详细讲解了如何去配置 keepalived 来保证从节点的高可用。

后续:如何让项目实现读写分离?

关于我

8 年互联网开发经验,擅长微服务、分布式、架构设计。目前在一家大型上市公司从事基础架构和性能优化工作。

InfoQ 签约作者、蓝桥签约作者、阿里云专家博主、51CTO 红人。

本文转载自微信公众号「  悟空聊架构」,可以通过以下二维码关注。转载本文请联系悟空聊架构公众号。 

来源:悟空聊架构内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯