在一主多从架构下， 主库故障后的主备切换问题。

一主一备的切换流程， 一主多从结构在切换完成后， A’会成为新的主库， 从库B、 C、 D也要改接到A’。 正是由于多了从库B、 C、 D重新指向的这个过程， 所以主备切换的复杂性也相应增加了。
image.png

1 基于位点的主备切换
节点B设置成节点A’的从库的时候， 需要执行一条change master命令 

  1. CHANGE MASTER TO
  2. MASTER_HOST=$host_name
  3. MASTER_PORT=$port
  4. MASTER_USER=$user_name
  5. MASTER_PASSWORD=$password
  6. MASTER_LOG_FILE=$master_log_name
  7. MASTER_LOG_POS=$master_log_pos

最后两个参数MASTER_LOG_FILE和MASTER_LOG_POS表示， 要从主库的master_log_name文件的master_log_pos这个位置的日志继续同步

原来节点B是A的从库， 本地记录的也是A的位点。 但是相同的日志， A的位点和A’的位点是不同的。 因此， 从库B要切换的时候， 就需要先经过“找同步位点”这个逻辑。

一种取同步位点的方法是这样的：
1. 等待新主库A’把中转日志（relaylog） 全部同步完成；
2. 在A’上执行show master status命令， 得到当前A’上最新的File 和 Position；
3. 取原主库A故障的时刻T；
4. 用mysqlbinlog工具解析A’的File， 得到T时刻的位点。

mysqlbinlog File —stop-datetime=T —start-datetime=T

从库B的同步线程就会报告 Duplicate entry‘id_of_R’ for key‘PRIMARY’ 错误， 提示出现了主键冲突， 然后停止同步

出现错误停止同步的问题解决：

1主动跳过一个事务
2 通过设置slave_skip_errors参数， 直接设置跳过指定的错误。在执行主备切换时， 有这么两类错误， 是经常会遇到的：
1062错误是插入数据时唯一键冲突；
1032错误是删除数据时找不到行。
因此， 我们可以把slave_skip_errors 设置为 “1032,1062”， 这样中间碰到这两个错误时就直接跳过

2 基于GTID的主备切换

2.1GTID

GTID的全称是Global Transaction Identifier， 也就是全局事务ID， 是一个事务在提交的时候生成的， 是这个事务的唯一标识。 它由两部分组成， 格式是：

GTID=server_uuid:gno
server_uuid是一个实例第一次启动时自动生成的， 是一个全局唯一的值；
gno是一个整数， 初始值是1， 每次提交事务的时候分配给这个事务， 并加1

在MySQL的官方文档里， GTID格式是这么定义的
GTID=source_id:transaction_id

这里的source_id就是server_uuid； 而后面的这个transaction_id， 我觉得容易造成误导， 所以我
改成了gno。 为什么说使用transaction_id容易造成误解呢？

MySQL里面我们说transaction_id就是指事务id， 事务id是在事务执行过程中分配的， 如果这个事务回滚了， 事务id也会递增， 而gno是在事务提交的时候才会分配

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

2.2 基于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协议。 MASTER_LOG_FILE和MASTER_LOG_POS参数， 已经不需要指定了


我们把现在这个时刻， 实例A’的GTID集合记为set_a， 实例B的GTID集合记为set_b。 接下来，

在实例B上执行start slave命令， 取binlog的逻辑是这样的：
1. 实例B指定主库A’， 基于主备协议建立连接。
2. 实例B把set_b发给主库A’。
3. 实例A’算出set_a与set_b的差集， 也就是所有存在于set_a， 但是不存在于set_b的GITD的集合， 判断A’本地是否包含了这个差集需要的所有binlog事务。
a. 如果不包含， 表示A’已经把实例B需要的binlog出现错误， 直接返回错误；
b. 如果确认全部包含， A’从自己的binlog文件里面， 找出第一个不在set_b的事务， 发给B；
4. 之后就从这个事务开始， 往后读文件， 按顺序取binlog发给B去执行。
其实， 这个逻辑里面包含了一个设计思想： 在基于GTID的主备关系里， 系统认为只要建立主备关系， 就必须保证主库发给备库的日志是完整的。 因此， 如果实例B需要的日志已经不存在， A’就拒绝把日志发给B。

3 小结

你使用的MySQL版本支持GTID的话， 我都建议你尽量使用GTID模式来做一主多从的切换