主库出问题了，从库怎么办?
今天这篇文章，我们就先聊聊一主多从的切换正确性。
如下图所示：是一个基本的一主多从结构
虚线箭头表示的是主备关系，也就是A和A'互为主备，从库B,C,D指向主库A\。一主多从的设置，一般用于读写分离，主库负责所有的写入和一部分度，其他的读请求则由从库分担。
我们接下来就要讨论在一主多从架构下，主库故障后主备切换问题。
如图下所示，主库发生故障，主备切换后的结果
一主多从切换完成后，A'会成为新的主库，从库B，C，D也要改接到A'。正是由于多了从库B，C，D重新指向的这个过程，所以主备切换的复杂性也增加了。
1.基于位点的主备切换
一般的当我们把B设置成节点A'的从库时候，需要执行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'的ip、端口号、用户名称和密码
MASTER_LOG_FILE：文件日志。
MASTER_LOG_POS：同步位点，要从 MASTER_LOG_FILE文件里找到MASTER_LOG_POS位置的日志继续同步，这个位置就是同步位点。
但是这两个参数位点怎么设置呢？
A与A'位点可能不同，所以需要找同步位点，这个位点很难精确取到，只能取到一个大致位置，为什么这么说呢？
考虑到切换过程中不能丢数据，所以我们找位点的时候，总是要找一个”稍微往前“的，然后通过判断跳过哪些在从库B上已经执行过的事务。
一种取同步位点方法是这样的？
1.等待新主库A’把中转日志(relaylog)全部同步完成;
2.在A’上执行showmasterstatus命令，得到当前A’上最新的File和Position;
3.取原主库A故障的时刻T;
4.用mysqlbinlog工具解析A’的File，得到T时刻的位点。
假如end_log_pos后面的值“123”，表示的就是A’这个实例，在T时刻写入新的binlog的位置。
然后，我们就可以把123这个值作为$master_log_pos ，用在节点B的change master命令里。
这个值不精确，设想这样一种情况，
这时候系统状态是这样的：
1.在从库B上，由于同步了binlog， R这一行已经存在;
2.在新主库A’上， R这一行也已经存在，日志是写在123这个位置之后的;
3.我们在从库B上执行changemaster命令，指向A’的File文件的123位置，就会把插入R这一行数据的binlog又同步到从库B去执行。
这时候，从库B的同步线程就会报告 Duplicate entry ‘id_of_R’ for key ‘PRIMARY’ 错误，提示出 现了主键冲突，然后停止同步。
针对这种情况，一般在切换任务的时候，主动跳过这些错误，
一种做法是，主动跳过一个事务/跳过命令的写法是：
set global sql_slave_skip_counter=1;
start slave;因为切换过程中，可能会不止重复执行一个事务，所以我们需要在从库B刚开始接到新主库 A’时，持续观察，每次碰到这些错误就停下来，执行一次跳过命令，直到不再出现停下来的情 况，以此来跳过可能涉及的所有事务。
另一种方式，设置参数s l a ve _ s k i p _ e r r o r s 直接跳过指定的错误
比如切换过程中可能会频繁出现以下两种情况：
- 1062错误是插入数据时唯一键冲突;
- 1032错误是删除数据时找不到行。
可以把把slave_skip_errors 设置为 “1032,1062”，这样中间碰到这两个错误时就直接跳过。
这个slave_skip_errors参数。等到主备间的同步关系建立完成，并稳定执行一段时间 之后，我们还需要把这个参数设置为空，以免之后真的出现了主从数据不一致，也跳过了。
2.GTID
MySQl5.6引入了GTID解决了建立从库和新主库的主备关系。设在T这个时刻，主库A已经执行完成了一个insert 语句插入了一行数据R，并且已经将binlog传给了A’和B，然后在传完的瞬间主库A的主机就掉电了。
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是在事务提交的时候才会分配。从效果上看，GTID往往是连续的，因此用gno来表示更容易理解。
GTID模式的启动，只需要在启动一个MySQL实例的时候，加上参数gtid_mode=on和enforce_gtid_consistency=on就OK了。
在GTID模式下，每个事务都会跟一个GTID一一对应。这个GTID有两种生成方式，而使用哪种方式取决于session变量gtid_next的值。
- 如果gtid_next=automatic，代表使用默认值。这时，MySQL就会把server_uuid:gno分配给这个事务。
a.记录binlog的时候，先记录一行 SET @@SESSION.GTID_NEXT=‘server_uuid:gno’;
b.把这个GTID加入本实例的GTID集合。
- 如果gtid_next是一个指定的GTID的值，比如通过set gtid_next='current_gtid’指定为 current_gtid，那么就有两种可能
a. 如果current_gtid已经存在于实例的GTID集合中，接下来执行这个事务会直接被系统忽 略
b.如果current_gtid没有存在于实例的GTID集合中，就将这个current_gtid分配给接下来要执行的事务，也就是说系统不需要给这个事务生成新的GTID，因此gno也不用加1。
一个current_gtid只能给一个事务使用。这个事务提交后，如果要执行下一个事务，就要执行set 命令，把gtid_next设置成另外一个gtid或者automatic。
这样，每个MySQL实例都维护了一个GTID集合，用来对应“这个实例执行过的所有事务”。
例子说明一下：
我们在实例X中创建一个表t。
CREATE TABLE `t` (
`id` int(11) NOT NULL,
`c` int(11) DEFAULT NULL, PRIMARY KEY (`id`)
) ENGINE=InnoDB;
insert into t values(1,1);
可以看到，事务的BEGIN之前有一条SET @@SESSION.GTID_NEXT命令。这时，如果实例X有从库，那么将CREATE TABLE和insert语句的binlog同步过去执行的话，执行事务之前就会先 执行这两个SET命令， 这样被加入从库的GTID集合的，就是图中的这两个GTID。
假设，现在这个实例X是另外一个实例Y的从库，并且此时在实例Y上执行了下面这条插入语句:
insert into t values(1,1);这条语句在实例Y上的GTID假如是这个：“aaaaaaaa-cccc-dddd-eeee-ffffffffffff:10”
那么要同步这个事务一定会出现主键冲突，导致实例X的同步线程停止。这时我们应该怎么处理呢？
你可以用如下方式处理：
set gtid_next='aaaaaaaa-cccc-dddd-eeee-ffffffffffff:10';
begin;
commit;
set gtid_next=automatic;
start slave;这个语句前三条的意思是提交一个空事务，把这个GTID加入到X的GTID集合中，如下图所示：执行完这个空事务之后的show master status的结果
实例X的Executed_Gtid_set里面，已经加入了这个GTID。
这时，我在执行start slave命令让同步线程执行起来的时候，虽然实例X上还是会继续执行实例Y 传过来的事务，但是由于“aaaaaaaa-cccc-dddd-eeee-ffffffffffff:10”已经存在于实例X的GTID集 合中了，所以实例X就会直接跳过这个事务，也就不会再出现主键冲突的错误。
set gtid_next=automatic;这个语句的意思是“恢复GTID的默认分配行为”，如果之后有新的事务再执行，就还是按照原来的分 配方式，继续分配gno=3。
3.基于GTID的主备切换
在GTID模式下，备库B要设置为新主库A’的从库的语法如下:
CHANGE MASTER TO
MASTER_HOST=$host_name
MASTER_PORT=$port
MASTER_USER=$user_name
MASTER_PASSWORD=$password
master_auto_position=1master_auto_position=1就表示这个主备关系使用的是GTID协议。已经不需要指定文件和日志位置参数了。
我们把现在这个时刻，实例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去执行。
之后这个系统就由新主库A’写入，主库A’的自己生成的binlog中的GTID集合格式是:server_uuid_of_A’:1-M。
如果之前从库B的GTID集合格式是 server_uuid_of_A:1-N， 那么切换之后GTID集合的格式就变成了server_uuid_of_A:1-N, server_uuid_of_A’:1-M。
当然，主库A’之前也是A的备库，因此主库A’和从库B的GTID集合是一样的。这就达到了我们预期。
4.GTID和在线DDl
如果业务高峰时慢查询性能问题，如果分析到是索引引起时，可以通过在线加索引，但是考虑到增加索引时对主库造成的影响，我们可以现在备库加索引，然后再切换。
在双M结构下，备库执行的DDL语句也会传给主库，为了避免传回后对主库造成影响，要通过set sql_log_bin=off关掉binlog。但是这样操作的话，数据库加了索引，binlog里没有记录这一更新，会导致数据和日志不一致。这时我们就可以采用GTID。
我们来看下怎么使用：
假设，这两个互为主备关系的库还是实例X和实例Y，且当前主库是X，并且都打开了GTID模 式。这时的主备切换流程可以变成下面这样:
- 在实例X上执行stop slave。
- 在实例Y上执行DDL语句。注意，这里并不需要关闭binlog。
- 执行完成后，查出这个DDL语句对应的GTID，并记为 server_uuid_of_Y:gno。
- 到实例X上执行以下语句序列:
set GTID_NEXT="server_uuid_of_Y:gno";
begin;
commit;
set gtid_next=automatic;
start slave;这样做的目的在于，既可以让实例Y的更新有binlog记录，同时也可以确保不会在实例X上执行这 条更新。接下来，执行完主备切换，然后照着上述流程再执行一遍即可。
以上就是全部内容啦！感谢林晓斌老师的课程，可以让我们学习那么多。