记一次 MySQL 高可用的事故

朴灿烈づ我的快乐病毒、 2023-10-14 15:02 1阅读 0赞

本篇主要内容如下：

![图片][format_png]

## 背景 ##

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

![图片][format_png 1]

读写分离的方案

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

![图片][format_png 2]

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

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

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

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

## 一、排查记录 ##

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

# 1.1 查看 MySQL 的容器日志 #

bash复制代码docker logs 043 --tail 200

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

![图片][format_png 3]

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

![图片][format_png 4]

# 1.2 查看 MySQL 的错误日志 #

lua复制代码cat /var/log/mysql/error.log
    这个路径在 my.cnf 配置。

![图片][format_png 5]

可以看到 6:27:30 没有异常日志。

这不就尴尬了，完全不知道为啥崩了。

（备注：另外也可以看下容器的信息，docker inspect <容器 id>，会显示容器什么时候启动和停止的。）

## 二、怎么理解读写分离 ##

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

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

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

*  1、完全的读写分离：主库只用来更新数据，从库只用来查询数据。
 *  2、部分读写分离：主库既可以用来读数据，又可以进行查数据；从库作为只读的备库，分担耗性能的查询工作。

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

![图片][format_png 6]

部分读写分离

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

### 3.1 保证从节点的可用性 ###

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

![图片][format_png 7]

提高从节点的可用性

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

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

有两种方案：

*  方案一：读操作切换到主库去查询。带来的问题：主库的压力会很大。
 *  方案二：部署两个从节点，从节点之间相互同步数据，只有一个从节点提供服务，另外一个节点作为备用从库，前者崩了的话，流量自动切换到后者。（需要两个节点开启 Keepalived 来提供流量切换的能力）带来的问题：部署的复杂性，主从同步延迟。

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

![图片][format_png 8]

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

这次我们要做的就是在在从节点开启 Keepalived，以及修改重启 MySQL 的脚本。从节点的 Keepalived 的 VIP 地址和主节点的 Keepalived 的 VIP 不一样。

原理如下所示：

![图片][format_png 9]

从节点首先得安装和配置 keepalived 在之前的文章中已经详细讲解过了。

我在讲解主主切换的文章中提到过 keepalived 承担的职责是就是监测 MySQL 服务是否正常，如果不正常，则重启 MySQL，如果重启失败，则退出 keepalived，自动将流量切换到另外一个节点。

这次的从节点只作为备库，没有切换到主库的要求，所以在主库宕机后，不需要接管读写的流量。

# 4.1 启动 keeaplived 服务以及开机自启动 #

安装好 keepalived 之后，执行以下命令启动。

sql复制代码systemctl start keepalived

![图片][format_png 10]

启动 keeaplived 服务

还需要设置 keepalived 开机自启动。

bash复制代码sudo vim /etc/rc.local
    添加以下命令
    systemctl start keepalived

具体内容可以看这篇

[实战 MySQL 高可用架构][MySQL]

![图片][format_png 11]

实战 MySQL 高可用架构目录

### 4.2 如何监测 MySQL 服务的健康状况 ###

keepalived 配置文件中定时监测 MySQL 服务的健康状况。

修改配置文件：

bash

复制代码

`sudo vim /etc/keepalived/keepalived.conf`

![图片][format_png 12]

### 4.3 如何自动重启 MySQL 服务 ###

自动重启 MySQL 的脚本之前也讲解过，这里再贴一下。当 keepalived 检测到 MySQL 无法连接时，就自动重启 MySQL 容器。

![图片][format_png 13]

如何自动重启 MySQL 服务

### 4.3 如何不让 Keepalived 切换流量到其他机器 ###

因为主节点也是开启了 Keepalived，如果主从的 Keepalived 的 VIP 都是同一个（之前配置的是 192.168.56.88），那么如果主节点崩了，就会将流量自动切换到从节点，因为我们这个从节点只作为备库，不需要它升级为主库，所以可以将主从节点的 Keepalived 的 VIP 设置为不一样，这样的话，从节点就不会升级为主节点。

这里我们就把之前的 VIP `192.168.56.88` 改为 `192.168.56.89`。

修改配置文件：

bash

复制代码

`sudo vim /etc/keepalived/keepalived.conf`

![图片][format_png 14]

如何自动重启 MySQL 服务

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

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

![图片][format_png 15]

## 五、总结 ##

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

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

[format_png]: https://img-blog.csdnimg.cn/img_convert/3e3b682d2ba00e81d058d62598131f3f.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/62750850d6e395e80bba29e9ce4b30c1.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/88c6652b66b1d8c71f8aeca8fa1e26f5.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/8ef8fa29196f3a760d2cb118d91072c9.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/43ab408d1a92cf6e50359e73500df8c6.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/32a28ad180d78984a6642a5783c0beeb.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/79bef337825cdbf40ace65d86153ac86.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/688078fbd01202776da4a07f80ba04dc.webp?x-oss-process=image/format,png
[format_png 8]: https://img-blog.csdnimg.cn/img_convert/28dc6779b34f7dc6da6dd1d66fd88e47.webp?x-oss-process=image/format,png
[format_png 9]: https://img-blog.csdnimg.cn/img_convert/3c3ab5e9bdc0fecb23e2c727ffddaa24.webp?x-oss-process=image/format,png
[format_png 10]: https://img-blog.csdnimg.cn/img_convert/90a828844146f4b1d2bd4d5b3e3ed4c3.webp?x-oss-process=image/format,png
[MySQL]: https://link.juejin.cn?target=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzAwMjI0ODk0NA%3D%3D%26mid%3D2451963004%26idx%3D1%26sn%3D2667d0e6e9142939e3645de680a4533f%26chksm%3D8d1c05e3ba6b8cf5a6a0ab2ecb66af10496838e25814cbefcd45907dd652a5ec6ef3917b6ada%26token%3D94995646%26lang%3Dzh_CN%26scene%3D21%23wechat_redirect
[format_png 11]: https://img-blog.csdnimg.cn/img_convert/3deaeaa10b903fbbf3548b8e31935a9a.webp?x-oss-process=image/format,png
[format_png 12]: https://img-blog.csdnimg.cn/img_convert/8714667d0d816109487094d5015e2d45.webp?x-oss-process=image/format,png
[format_png 13]: https://img-blog.csdnimg.cn/img_convert/25009c9421ec0ac670c3550022767a1a.webp?x-oss-process=image/format,png
[format_png 14]: https://img-blog.csdnimg.cn/img_convert/e8638603635bdfb599e6bfcfb12f1465.webp?x-oss-process=image/format,png
[format_png 15]: https://img-blog.csdnimg.cn/img_convert/eef37f6a7b77d1ddf0ded3ad6ac9ad83.webp?x-oss-process=image/format,png