MySQL 基础技术（四）—— MySQL 如何保证高可用？

喜欢ヅ旅行 2023-09-29 09:50 2阅读 0赞

## 一、引子 ##

上一篇文章，我们讲述了《MySQL 如何保证数据不丢失？》，介绍了 `binlog` 和 `redo log` 的工作流程。  
那么，`MySQL` 怎么保证高可用呢？  
为了提高 `MySQL` 的读写性能，我们往往采用 `MySQL` 一主多从的方案。  
即一个主库（主要负责写），多个从库（只负责读）。  
因为单实例有性能瓶颈，多从库能优先解决 `MySQL` 的读负载压力。

## 二、主从同步 ##

![15c298bb30e5943058c9c2d4437d1e44.png][]

### 原理： ###

将 `MySQL` 设计成一主多从模式。

简单来说，主要分为三步：

*  第一步：所有增删改的 `DML` 语句都在 `master` 节点的示例上完成。
 *  第二步：将处理完成的 `binlog` 日志传输到各个 `slave` 节点。
 *  第三步：多个 `slave` 节点处理 `binlog`，从而保持主从一致。

详细来说，

![25eef1b692433defbab3720407eac0a8.png][]

`Master` 与 `Slave` 之间会维护一个长连接，专门用来同步`binlog`。

创建从库的过程：

1.  在 `Slave` 机器上，通过 `change master` 命令，设置主库的 IP、端口号、用户名、密码，以及`binlog` 从哪里开始获取等信息（具体`binlog`文件名 + 文件偏移量）。
2.  在 `Slave` 机器上，执行`start slave`命令，启动 `io_thread` 和 `sql_thread` 线程。  
    其中 `io_thread` 用于接收主库的 `binlog`，`sql_thread` 用于处理主库的 `binlog`。
3.  `Slave` 开始尝试连接 `Master`，`Master` 校验完用户名密码后，`dump_thread` 根据 `Slave` 设置的 `binlog` 文件和偏移量，开始读取 `binlog` 发送给 `Slave`。
4.  `Slave` 的 `io_thread` 将接收到的 `binlog` 写到 `relay log` （中转日志）。
5.  `sql_thread` 读取中转日志，执行对应SQL，同步完成。

### 问题： ###

#### 1. 主从延迟 ####

> 即“同步延迟”。  
> 表示同一个事务下，主库执行完成到备库执行完成的时间差值。

![c1630d6dee93e8fbb39141d9e7ff4a18.png][]

时间线：

1.  `Master` 执行一个事务，成功写入`binlog` —— 这个时刻，我们记为 **T1**。
2.  `Slave` 的 `io_thread` 接收到`binlog` —— 这个时刻，我们记为 **T2**。
3.  `Slave`执行完这个事务。—— 这个时刻，我们记为 **T3**。

> 所谓主从延迟，就是 **T3-T1** 的时间。

如果在这段时间里，在从库上查询主库刚插入/修改的数据，会出现主从不一致的现象。  
这时，一些对可靠性要求比较高的业务场景里，就会出现错误。  
我们可以在从库上执行：

show slave status;

其中，`seconds_behind_master` 就是从库延迟的时间（**T3-T1**）

> **主从延迟的根本原因是：从库消费中转日志（`relay log`）的速度比主库生产 `binlog` 的速度慢。**

#### 2. 主从切换 ####

> 在实际场景下，可能会遇到主库所在机器异常、掉电、或者机房升级等等。  
> 这就会涉及到“主库”与“从库”之间的切换问题。  
> 由于主从延迟的存在，在主从切换的时候，就会有不同的策略。

![fcc6c3bdfc6f00b0df87d720f00c35a9.png][]

可靠性优先策略（推荐）：

1.  查询 `slave` 的 `seconds_behind_master`，如果小于预定的某个值（比如3秒），就下一步。  
    否则就一直轮训，直到出现满足条件的`Slave`。（选未来主库）
2.  将 `master` 的 `readonly = true`，降为从库。
3.  查询该 `slave`（未来主库） 的 `seconds_behind_master` 值变成 0。（即无主从延迟）
4.  将该 `slave` （未来主库）的状态变成读写。`readonly = false`，升成主库。
5.  将请求流量切到新主库。

*  优点：可靠性高，数据可靠。
 *  缺点：会有一小段不可用的时间。

> 因此，得选择 `seconds_behond_master` 比较短的 `slave` 升 `master`。

可用性优先策略：

1.  直接将 `slave` （未来主库）的状态变成读写。`readonly = false`，升成主库。
2.  将请求流量切到新主库。
3.  将老主库的 `readonly = true`，降为从库。

*  优点：可用性高，没有真空期。
 *  缺点：可能会出现数据不一致的情况。

## 三、如何保证高可用 ##

> MySQL 如果要保证高可用，就要满足三个条件。
> 
> 1.  数据不丢失。（双1策略）
> 2.  主从最终一致性。（主库所有binlog，备库都执行了）
> 3.  无主从延迟。

### 主从延迟的来源： ###

#### 1. `Slave` 所在机器性能问题。（部署在同一机器上） ####

我就遇到过这种 case：  
我们的数据库和飞书的数据库部署在同一个机器上，  
他们在大量的做一些DML操作，删除/归档很多老数据。  
导致于我们的Slave资源被一直抢占，进而出现主从延迟。

> 解决思路：
> 
> 1.  如果成本允许，按服务，分开独立部署。

#### 2. Slave 压力大，查询耗费了大量CPU资源，影响了同步速度。 ####

这种也比较常见，表/索引设计不合理、或者有临时任务在拖库，导致慢慢查询，耗费了大量`CPU`资源。导致 `io_thread`、`sql_thread` 抢占不到资源进而同步缓慢。

> 解决思路：  
> 1.优化表设计、索引设计。解决慢 SQL 问题。  
> 2.增加从库，分担现有从库的压力。  
> 3.对于一些临时/定时任务：可用 Binlog -> Hadoop。转移让另外一个系统来提供查询能力。

#### 3. **大事务** ####

这种也比较好理解，主库上执行一个大事务花了n分钟，那么大概率就会导致从库延迟n分钟。  
比如，磁盘空间快满了，需要归档一些历史数据，需要一次性删除大量历史数据。这时候和就会出现主从延迟。

> 解决思路：  
> 1.业务允许的话，控制每个事务的数据量，分成多次操作。

![watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAamF2YeaZtOWkqei_h-WQjg_size_10_color_FFFFFF_t_70_g_se_x_16][]  
链接：https://www.jianshu.com/p/4f640003027e

[15c298bb30e5943058c9c2d4437d1e44.png]: https://img-blog.csdnimg.cn/img_convert/15c298bb30e5943058c9c2d4437d1e44.png
[25eef1b692433defbab3720407eac0a8.png]: https://img-blog.csdnimg.cn/img_convert/25eef1b692433defbab3720407eac0a8.png
[c1630d6dee93e8fbb39141d9e7ff4a18.png]: https://img-blog.csdnimg.cn/img_convert/c1630d6dee93e8fbb39141d9e7ff4a18.png
[fcc6c3bdfc6f00b0df87d720f00c35a9.png]: https://img-blog.csdnimg.cn/img_convert/fcc6c3bdfc6f00b0df87d720f00c35a9.png
[watermark_type_d3F5LXplbmhlaQ_shadow_50_text_Q1NETiBAamF2YeaZtOWkqei_h-WQjg_size_10_color_FFFFFF_t_70_g_se_x_16]: https://img-blog.csdnimg.cn/cfca096af40e4865a8b29192d644d059.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAamF2YeaZtOWkqei_h-WQjg==,size_10,color_FFFFFF,t_70,g_se,x_16