bajieyuanma 信息公告 2022-05-07

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

之前，有一年多的工作客户端领域的工作经验。
后来，也在字节做了一年多的后端业务。
现在希望做一些 MySQL 总结，丰富一下自己在后端领域的积累。
目录如下：
MySQL 基础技术（一） —— MySQL 是如何查询的？
MySQL 基础技术（二） —— MySQL 是如何更新的？
MySQL 基础技术（三）—— MySQL 如何保证数据不丢失？
MySQL 基础技术（四）—— MySQL 如何保证高可用？

一、引子

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

二、主从同步

主从同步（简化）

原理：

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

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

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

详细来说，

主从同步（详细）

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

创建从库的过程：

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

问题：

1. 主从延迟

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

主从延迟时间

时间线：

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

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

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

show slave status;

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

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

2. 主从切换

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

主从切换

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

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