MySQL 主备同步技术演化
主库出问题了，从库怎么办？
备库：同步主库的binlog，当主库出问题时，备库切换为主库。一般不提供读服务。
从库：同步主库的binlog，只对外提供读服务。
一主多从主备切换 方法
基于位点的主备切换
首先我们知道，设置从库时的命令
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
master_log_file和master_log_pos 表示从主库的这个文件的pos位置开始同步，
那如何获取这个pos位置呢？
一种取同步位点的方法是这样的：
- 等待新主库 A’把中转日志（relay log）全部同步完成；
- 在 A’上执行 show master status 命令，得到当前 A’上最新的 File 和 Position；
- 取原主库 A 故障的时刻 T；
- 用 mysqlbinlog 工具解析 A’的 File，得到 T 时刻的位点。
通过命令show master status 可以得到file和pos。这里的pos是最新的，从库同步的话，是需要找故障时刻T的位点，执行 mysqlbinlog File --stop-datetime=T --start-datetime=T 获取到end_log_pos 作为同步的位点。
这种取同步位点的方法是不精确的，往往在执行的时候，需要执行一些辅助命令来跳过某些错误。
- 主动跳过一个事务
set global sql_slave_skip_counter=1;
start slave;
缺点是没遇到一个错误，就需要手动执行一次。
- 指定错误码跳过
set slave_skip_errors = "1032,1062";
start slave;
在执行主备切换时，有这么两类错误，是经常会遇到的：
- 1062 错误是插入数据时唯一键冲突；
- 1032 错误是删除数据时找不到行。
千万注意，主备切换后，要将这个参数设置为空
GTID
MySQL 5.6版本引入了GTID，将自动找位点的这一步骤完全自动化了。
那什么是GTID？
GTID 的全称是 Global Transaction Identifier，也就是全局事务 ID，是一个事务在提交的时候生成的，是这个事务的唯一标识。
GTID=server_uuid:gno
1, server_uuid 是一个实例第一次启动时自动生成的，是一个全局唯一的值
2. gno 是一个整数，初始值是 1，每次提交事务的时候分配给这个事务，并加 1。
gtid_next=automatic 代表使用默认值。
如果设置gtid_next=current_gtid, 如果current_gtid已经在实例的gtid集合中，接下来这个事务会被直接跳过，否则分配current_gtid给接下来的事务执行。注意：每个MySQL实例都维护了一个GTID集合，用来对应执行过的所有事务
基于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 表示这个主备关系使用的是GTID协议。
模拟以下GTID的主备切换。实例A的gtid集合为set_a, 实例B的gtid集合为set_b.
- 实例B使用change master 设置主库，使用master_auto_position参数。
- 实例B将set_b 发送给主库A
- 实例A算出set_a 与 set_b 之间的差集，即只在set_a的gtid，然后判断A的binlog是否有这个差集的所有事务，如果少了一些，则会返回错误给B，拒绝实例B建立主从同步，否则找出差集中的第一个gtid给实例B，完成主动找pos的过程
- 之后就从binlog这个位置将事务发给B取执行。
利用GTID主动跳过导致从库同步失败的事务
set gtid_next='aaaaaaaa-cccc-dddd-eeee-ffffffffffff:10';
begin;
commit;
set gtid_next=automatic;
start slave;
aaaaaaaa-cccc-dddd-eeee-ffffffffffff:10 是主库已经存在的事物id，该事务id会导致从库同步失败，通过设置gtid_next并提交一个空事务，将其加入从库的gtid集合中，从而跳过执行该事务
最后一个问题：基于gtid的主备切换，怎么解决主库因为binlog缺少某些事务而拒绝建立主从同步呢？
- 如果业务允许主从不一致的情况，那么可以在主库上先执行 show global variables like ‘gtid_purged’，得到主库已经删除的 GTID 集合，假设是 gtid_purged1；然后先在从库上执行 reset master，再执行 set global gtid_purged =‘gtid_purged1’；最后执行 start slave，就会从主库现存的 binlog 开始同步。binlog 缺失的那一部分，数据在从库上就可能会有丢失，造成主从不一致。
- 如果需要主从数据一致的话，最好还是通过重新搭建从库来做。
- 如果有其他的从库保留有全量的 binlog 的话，可以把新的从库先接到这个保留了全量 binlog 的从库，追上日志以后，如果有需要，再接回主库。
- 如果 binlog 有备份的情况，可以先在从库上应用缺失的 binlog，然后再执行 start slave。
