正常情况下，只要主库执行更新生成的所有binlog，都可以传到备库并被正确地执行，备库就能达到跟主库一致的状态，这就是最终一致性。但是MySQL要提供高可用能力，只有最终一致性是不够的。
主备延迟问题
主备切换可能是一个主动运维动作：比如软件升级、主库所在机器按计划下线等，也可能是被动操作，比如主库所在机器掉电。
同步延迟的概念：与数据同步有关的时间点主要包括以下三个：
1、主库A执行完成一个事物，写入binlog，这个时刻记为T1;
2、之后传给备库B,备库B接收完这个binlog的时刻记为T2;
3、备库B执行完成这个事物，这个时刻记为T3.
所谓的主备延迟，就是同一个事物在备库执行完成的时间和主库执行完成的时间的差值。T3-T1.
主备延迟的来源：
1、备库所在机器的性能要比主库所在的机器性能差；
2、备库压力大；
3、大事物。
可靠性优先策略
双M结构下，主备切换的详细过程如下：
1、判断备库B现在的seconds_behind_master,如果小于某个值（比如5秒）继续下一步，否则持续重试这一步；
2、把主库A改成只读状态，即把readonly设置为true；
3、判断备库B的seconds_behind_master的值，直到这个值变成0为止；
4、把备库B改成可读写状态，也就是把readonly设置为false；
5、把业务请求切到备库B。
这个切换流程中是有不可用时间的。因为在步骤2之后，主库A和备库B都处于readonly状态，也就是说这时系统处于不可写状态，直到步骤5完成后才能恢复。在这个不可用状态中，比较耗时的是步骤3，可能需要耗费好几秒的时间。这也是为什么需要在步骤1 先做判断，确保seconds_behind_master的值足够小。
试想如果一开始主备延迟就长达30分钟，而不先做判断直接切换的话，系统的不可用时间就会长达30分钟。当然，系统的不可用时间，是由这个数据可靠性优先的策略决定的，可以选择可用性优先的策略，来把这个不可用时间几乎降为0.
可用性优先策略
如果把步骤4、5调整到最开始执行，也就是说不等主备数据同步，直接连接切换到备库B，别切让备库B可以读写，那么系统几乎就没有不可用时间了。
