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使用默认值时：
- 记录binlog的时候，会先记录一行set @@session.gtid_next='server_uuid:gno'
- 将改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的处理逻辑如下：
- 节点B指定主库A'，基于主备协议建立连接
- 节点B把set_b发送给主库A'
- 节点A'计算出set_b和set_a的差集（在set_a但不存在与set_b的GTID集合），判断A'是否包含了这个差集所需要的所有binlog事务：如果不包含，表示A'已经把实例B需要的binlog删掉了，直接返回错误；如果确认包含，A'从自己的binlog文件中找出第一个不存在set_b的事务发送给B
- 之后就从这个事务开始，往后读取文件，按顺序取binlog发送给B执行
