一：为什么要进行主备切换？
- 比如软件升级、主库所在机器按计划下线等。主动运维。
- 比如主库所在机器掉电,为了保证服务的正常运行，而进行切换。可能是被动操作。
- 流程图
- 
二：什么是同步延迟？
- 在介绍主动切换流程的详细步骤之前，先跟你说明一个概念，既“同步延迟”
- 与数据同步有关的时间点主要包括以下三个：
- 主库 A 执行完成一个事务，写入 binlog，我们把这个时刻记为 T1;
- 之后传给备库 B，我们把备库 B 接收完这个 binlog 的时刻记为 T2;
- 备库 B 执行完成这个事务，我们把这个时刻记为 T3。
二：什么是主备延迟？
- 所谓主备延迟，就是在备库执行完成的时间和主库执行完成的时间之间的差值，也就是 T3-T1。
- 可以在备库上执行 show slave status 命令，它的返回结果里面会显示 seconds_behind_master，用于表示当前备库延迟了多少秒。
- seconds_behind_master 计算规则
- 每个事务的 binlog 里面都有一个时间字段，用于记录主库上写入的时间。
- 备库取出当前正在执行的事务的时间字段的值，计算它与当前系统时间的差值，得到 seconds_behind_master。
- 需要说明的是，在网络正常的时候，日志从主库传给备库所需的时间是很短的，即 T2-T1 的值是非常小的。
- 所以说，主备延迟最直接的表现是，备库消费中转日志（relay log）的速度（T2-T3 之间） ，比主库生产 binlog 的速度要慢。
三：什么情况会导致主备延迟？
- (主 / 从) (机器不同 / 配置不同)（不常见）
- 当备库所在机器性能较差/Mysql配置不同，备库争抢资源/配置问题，就可能会导致主备延迟了。
- 备库压力过大
- 备库上的查询耗费了大量的 CPU 资源，影响了同步速度，造成主备延迟。
- 解决
- 一主多从。除了备库外，可以多接几个从库，让这些从库来分担读的压力。
- 通过 binlog 输出到外部系统，比如 Hadoop 这类系统，让外部系统提供统计类查询的能力。
- 大事务 / 大表 DDL
- 因为主库上必须等事务执行完成才会写入 binlog，再传给备库。所以当有大事务的进行，会导致延迟。
- 例如： 不要一次性地用 delete 语句删除太多数据。其实，这就是一个典型的大事务场景。
- 其他
- 主库 DML 并发大，从库 QPS 高。
- 从库备份。
四：如何主备切换？
- 由于主备延迟的存在，所以在主备切换的时候，就相应的有不同的策略。
- 可靠性优先策略
- 流程（在图 1 的双 M 结构下）( 一般是由专门的 HA（双机集群系统） 来完成)
- 判断备库 B 现在的 seconds_behind_master，如果小于某个值（比如 5 秒）继续下一步，否则持续重试这一步；
- 把主库 A 改成只读状态，即把 readonly 设置为 true；
- 判断备库 B 的 seconds_behind_master 的值，直到这个值变成 0 为止；
- 把备库 B 改成可读写状态，也就是把 readonly 设置为 false；
- 把业务请求切到备库 B。
- 问题
- 可以看到，这个切换流程中是有不可用时间的。
- 因为在步骤 2 之后，主库 A 和备库 B 都处于 readonly 状态，也就是说这时系统处于不可写状态，直到步骤 5 完成后才能恢复。
- 总结
- 在确定使用可用性优先策略时候，先做判断，确保 seconds_behind_master 的值足够小。这样可以保证切换够快。
- 试想如果一开始主备延迟就长达 30 分钟，而不先做判断直接切换的话，系统的不可用时间就会长达 30 分钟，这种情况一般业务都是不可接受的。
- 优点
- 数据可靠。无需修复数据。
- 可用性优先策略
- 流程（在图 1 的双 M 结构下）
- 不检查 seconds_behind_master，直接进行上面 4,5 步的主从切换。
- 问题
- 这个切换流程的代价，就是可能出现数据不一致的情况。(binglog 推荐使用 row 模式，使得不一致错误更容易发现 )
- 优点
- 无不可用时间。
- 策略选择？
- 更多的从业务上去考虑。
- 如过这个业务已经是不可用的状态，那么也只能选择可用优先。
- 如果这个业务是正常的切换，那么就应该选择可靠优先策略。