MySQL高可用，就这么完美？？？

原创已于 2022-06-01 15:23:47 修改 · 161 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#mysql #数据库

于 2021-10-11 16:49:43 首次发布

存储专栏收录该内容

30 篇文章

订阅专栏

MySQL以其容易学习和高可用，被开发人员青睐。它的几乎所有的高可用架构，都直接依赖于 binlog。MySQL 能够成为现下最流行的开源数据库，binlog 功不可没。MySQL是怎样实现高可用的？这种高可用足够完美吗？

主备同步流程

流程

主库为A，备库为B，其同步流程如下图所示，这张图也很好的阐明一条更新语句，在master会执行哪些动作：

备库 B 跟主库 A 之间维持了一个长连接。主库 A 内部有一个线程，专门用于服务备库 B 的这个长连接。一个事务日志同步的完整过程是这样的：

在备库 B 上通过 change master 命令，设置主库 A 的 IP、端口、用户名、密码，以及要从哪个位置开始请求 binlog，这个位置包含文件名和日志偏移量。
在备库 B 上执行 start slave 命令，这时候备库会启动两个线程，就是图中的 io_thread和 sql_thread。其中 io_thread 负责与主库建立连接。
主库 A 校验完用户名、密码后，开始按照备库 B 传过来的位置，从本地读取 binlog，发给 B。
备库 B 拿到 binlog 后，写到本地文件，称为中转日志（relay log）。
sql_thread 读取中转日志，解析出日志里的命令，并执行。

同步位置

主备切换后，从库需要从新的主库同步数据。即上面流程第一步，需要指定从哪个位置开始请求binlog。主要有两种方案：

基于位点

MySQL5.6之前，使用change master命令更换主库。

CHANGE MASTER TO 

MASTER_HOST=$host_name 
MASTER_PORT=$port 
MASTER_USER=$user_name 
MASTER_PASSWORD=$password 
MASTER_LOG_FILE=$master_log_name 
MASTER_LOG_POS=$master_log_pos

操作流程如下：

等待新主库 A’把中转日志（relay log）全部同步完成；
在 A’上执行 show master status 命令，得到当前 A’上最新的 File 和 Position；
取原主库 A 故障的时刻 T；
用 mysqlbinlog 工具解析 A’的 File，得到 T 时刻的位点。

基于GTID

基于位点的方案太过繁琐，MySQL 5.6 版本引入了 GTID，无需人工计算位点。

GTID 的全称是 Global Transaction Identifier，也就是全局事务 ID，是一个事务在提交的时候生成的，是这个事务的唯一标识。每个 MySQL 实例都维护了一个 GTID 集合，用来对应“这个实例执行过的所有事务”。

CHANGE MASTER TO 
MASTER_HOST=$host_name 
MASTER_PORT=$port 
MASTER_USER=$user_name 
MASTER_PASSWORD=$password 
master_auto_position=1

master_auto_position=1 就表示这个主备关系使用的是 GTID 协议。

在实例 B 上执行 start slave 命令，取 binlog 的逻辑如下所示，其中set_a和set_b为执行过的事务的 GTID 集合：

实例 B 指定主库 A’，基于主备协议建立连接。
实例 B 把 set_b 发给主库 A’。
实例 A’算出 set_a 与 set_b 的差集，也就是所有存在于 set_a，但是不存在于 set_b的 GTID 的集合，判断 A’本地是否包含了这个差集需要的所有 binlog 事务。

a. 如果不包含，表示 A’已经把实例 B 需要的 binlog 给删掉了，直接返回错误；

b. 如果确认全部包含，A’从自己的 binlog 文件里面，找出第一个不在 set_b 的事务，发给 B；
之后就从这个事务开始，往后读文件，按顺序取 binlog 发给 B 去执行。

基于GTID的操作，可以认为是系统自行计算出对应位点。