主备切换
主备切换分为主动运维与被动操作。
软件升级、主库所在机器按计划下线为主动运维。
主库所在机器掉电为被动操作。
同步延迟
1、主库A执行完一个事务，写入binlog，时刻T1
2、传给备库B，备库B接受完这个binlog，时刻T2；
3、备库B执行完这个事务，时刻T3；
同一个事务，在备库执行完成的时间和主库执行完成的时间之差为T3-T1，又称主备延迟。
在备库执行show slave status命令会显示seconds_behind_master，表示备库延迟了多少秒。
主备库机器系统时间设置不一样并不会导致主备延迟的值不准。
在网络正常的时候，日志从主库传给备库的时间T2-T1是很短的。也就是说网络正常时，主备延迟的主要来源是备库接受完binlog和执行这个事务之间的时间差。
主备延迟最直接的表现就是：备库消费中转日志(relay log)的速度，比主库生产binlog的速度慢。
主备延迟的原因
1、备库所在机器的性能可能比主库所在的机器性能差
2、备库压力大。（主库提供写能力，备库提供读能力）
由于主库直接影响业务，使用起来比较克制，反而忽视了备库的压力控制。结果就是，备库上的查询耗费了大量的CPU资源，影响了同步速度，造成主备延迟。
这种情况可以这么解决：
1、一主多从。除了备库外，可以多接几个从库，让这些从库来分担读的压力
2、通过binlog输出到外部系统，让外部系统提供统计查询的能力
3、大事务情况
由于主库必须等事务执行完才会写入binlog，再传给备库。
如果一个主库上的语句执行10分钟，那么这个事务很可能会导致从库延迟10分钟。
典型大事务场景
a、一次性删掉大量历史数据。需要控制每个事务删除的数据量，分成多次删除
b、大表DDL
4、备库并行复制能力差
可靠性优先策略的主备切换流程
在M-M结构下，状态1切换到状态2流程如下：
1、判断备库B现在的seconds_behind_master，如果小于某个值(比如5s)继续下一步，否则继续重试这一步
2、把主库A改成只读状态，(readonly设置为true)
3、判断备库B的seconds_behind_master，直到这个值变为0
4、把备库改成可读写状态，(readonly设置为false)
5、把业务请求切换到备库B
step2之后，主库A和备库B都处于readonly状态，此时系统处于不可写状态，直到step5才能恢复。step3比较耗时。
可用性优先策略的主备切换流程
如果强行把上面的step4、5调整到最开始执行，也就是说不等主备数据同步，直接把连接切到备库B，并且让备库B可以读写，那么系统几乎没有不可用时间。
这个切换流程，称为可用性优先流程，不过这个切换的代价，就是可能出现数据不一致的情况。
结论如下：
1、使用row格式的binlog时，数据不一致的问题更容易被发现。使用mixed或者statement格式的binlog时，数据很可能就不一致了。
2、主备切换的可用性优先策略会导致数据不一致，所以一般情况下使用可靠性优先策略。
下面介绍一个使用可用性优先策略的情形：
-
有一个库的作用是记录操作日志。如果数据不一致可以通过binlog来修补，而这个短暂的不一致也不会引发业务问题。
-
同时，业务系统依赖于这个日志写入逻辑，如果这个库不可写，会导致线上的业务操作无法执行。
如果使用可靠性优先的思路，只能等待备库慢慢应用中转日志，在备库应用完中转日志且切换成读写状态之前，数据库是处于不可用的状态。 这时也不能直接切换到备库B，然后保持B库只读。
所以此时就需要用到可用性优先策略。
Mysql的高可用性，依赖于主备延迟。主备延迟的时间越小，出现故障的时候，服务需要恢复的时间就越短，可用性就越高