MySQL GTID主备切换协议

一主多从的设置主要用来读写分离，主库负责所有的写入和一部分读，其他的读请求由从库承担。

其中A'和A还互为主备库，当主库A发生故障时，A'会成为新的主库，此时从库B和C需要改到同步A'。一般这种都会有专门的系统完成，我们可以看一下这种专门的系统大体有哪几种方式完成主备切换。

主备切换的方式有几种？

• 基于位点的主备切换
• 基于GTID的主备切换

如何设置节点B成为A'的主库？

需要在节点B上执行以下命令：

-- master_host：主库A'的IP
-- master_port：主库A'的端口
-- master_user：用户名
-- master_password：密码
-- master_log_file：从库需要从哪个文件开始同步
-- master_log_pos：从库需要从日志文件的哪个偏移量开始同步
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;

节点B在发生切换前是A的从库，因此本地记录的也是A的位点，但是相同的日志，在A和A'的位点是不同的。因此在切换前，需要找到同步位点。

如何找同步位点？

• 等待节点A'把中转日志全部同步完成
• 在A'上执行show master status，得到A'上最新的File和Position
• 取主库A故障的时刻T
• 用MySQLbinlog工具解析A'的File，得到T时刻的位点

mysqlbinlog file --stop-datetime=T --start-dateTime=T

上图中，end_log_pos后面的123表示的A'实例在故障时刻T写入新的binlog的位置，此位置用在节点B的的change master指令中。

基于位点主备切换的弊端？

无法精准的找出同步位置，在上面的找的位置我们是不准确的，假设有一种情况，主库A在执行一条insert语句以后插入了一行数据R，并且已经将binlog传给了A'和B，此时A（T时刻）发生宕机，此时系统的状态如下：

• 从库B，由于同步了binlog，R这一行会被插入
• 在A'上，R这一行也会存在，但是日志是写在T时刻以后

此时如果们在库B上执行change master命令，从T时刻的position开始同步，就会把插入R这一行的binlog再次同步到从库执行，此时从库B的同步线程会因主键冲突而停止同步。

如何暴力解决上述错误？

• 主动跳过一个事务
• 主动跳过指定错误

如何主动跳过一个事务？

-- 每次遇到错误都要执行一次sql_slave_skip_counter
set global sql_slave_skip_counter=1;
start slave;

如何跳过指定错误？

mysql主要有很多错误类型，如下两种：

• 1062：插入数据时唯一键冲突
• 1032：删除数据时找不到行

我们可以在mysql配置文件中添加以下内容：

slave_skip_errors=1062,1032

或者在启动的时候增加启动参数--slave_skip_errors=1062,1032。

等主备同步关系建立完成以后并且稳定执行一段时间，我们再还原参数，避免后续的问题。

什么是GTID？

GTID（Global Transaction Identifier）全称是全局事务ID，是一个事务在提交的时候生成的，是这个事务唯一的表示，格式如下：

GTID=server_uuid:gno

• server_uuid：实例第一次启动时自动生成，全局唯一的值
• gno：初始值为1，每次提交事务的时候分配给这个事务，并加1

如何启动GTID？

# 在配置文件中增加下面两行参数
gtid_mode = on
enforce_gtid_consistency = on

-- 查看GTID相关参数
show variables like "%gtid%";

GTID的生成方式？

GTID有两种生成方式，使用哪种方式取决于Session变量gtid_next的值：

• gtid_next=automatic：使用默认值，mysql会将server_uuid:gno分配给此事务
• gtid_next是指定的值：比如通过set gtid_nex='current_gtid'指定

每个MySQL实例都维护了一个GTID集合，用来对应这个实例执行过的所有事务。

GTID automatic

gtid使用默认值时：

1. 记录binlog的时候，会先记录一行set @@session.gtid_next='server_uuid:gno'
2. 将改GTID加入本实例的GTID集合

GTID current_gtid

gtid使用指定值时：

• 如果current_gtid已经存在于实例的GTID集合，该事务会被忽略
• 如果current_gtid不存在于实例的GTID集合，就将current_gtid分配给接下来要执行的事务，也就是说系统不需要生成新的GTID

一个current_gtid只能给一个事务使用。如果要执行下一个事务必须使用另一个唯一的gtid或者变成automatic。

基于GTID的主备切换

-- master_host：主库A'的IP
-- master_port：主库A'的端口
-- master_user：用户名
-- master_password：密码
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协议，假设当前时刻下，节点A'的GTID集合是set_a，实例B的GTID集合是set_b，我们在B上执行start slave指令以后，节点B对binlog的处理逻辑如下：

1. 节点B指定主库A'，基于主备协议建立连接
2. 节点B把set_b发送给主库A'
3. 节点A'计算出set_b和set_a的差集（在set_a但不存在与set_b的GTID集合），判断A'是否包含了这个差集所需要的所有binlog事务：如果不包含，表示A'已经把实例B需要的binlog删掉了，直接返回错误；如果确认包含，A'从自己的binlog文件中找出第一个不存在set_b的事务发送给B
4. 之后就从这个事务开始，往后读取文件，按顺序取binlog发送给B执行