上一篇介绍了binlog的基本内容，在主备关系中，是每个备库接收主库的binlog并执行。
正常情况下，只要主库执行更新生成的所有的binlog，都可以传到备库并被正确执行，备库就能跟主库一致的状态，之就是最终一致性，但是，mysql要提供高可用能力，只有最终一致性是不够的
主备延时
主备切换可能是一个主动运维动作，比如软件升级，主库所在机器按计划下线，也可能是被动操作，比如主库所在机器掉电。
在主从切换之前，先了解一下同步延时
1 主库A执行完成一个事务，写入binlog，这个时刻记T1
2 之后传给备库B，我们把备库B接收完这个binlog的时刻记T2
3 备库B执行完成这个事务，这个时刻记T3
所谓主备延迟，就是同一个事务，在备库执行完成的时间和主库执行完成的时间差值，也就是T3-T1
可以在slave上执行show slave status查看，Seconds_Behind_Master 这个参数，用于表示当前备库延时了多少秒
Seconds_Behind_Master的计算方法
1 每个事务的binlog里面有一个时间字段，用于记录主库写入的时间
2 备库取出当前正在执行的事务的时间字段，计算他与当前系统的差值，得到Seconds_Behind_Master。
可以看到，这个Seconds_Behind_Master参数计算的就是T3-T1，这个参数可以用来作为主备的延时，单位是秒
如果主备机器的系统时间设置不一致，会不会导致主备延时的值不准
其实不会，在备库接收到主库的时候，会通过执行select UNIX_TIMESTAMP() 来活动当前主库的系统时间，如果发现主库的系统时间与自己不一致，备库计算Seconds_Behind_Master的时候会自动扣掉这个差值
在网络正常的时候，日志从主库传给备库是需要很短时间的，及T2-T1需要很短的时间，也就是说网络正常的情况下，主备延时的主要来源是备库接收完binlog和执行任务之间的时间差。
主备延时的来源
首先，有些部署环境下，备库所在机器的性能要比主库所在的机器性能要差。
一般情况下，有的备库的请求要少很多，所以，这种情况是存在的，备库的机器的性能要差一些，更新请求对iops的压力，在主库和备库上是没有差别的，所以这种部署时，一般都会将备库设置为”非双1”模式。
但实际上，更新过程中也会触发大量的读操作，所以，当备库机器上的多个备库都在争抢资源是，可能会导致主备延时。
在对称部署时，主备的机器都相同规格，在备库上运行一些报表之类的运营业务，也可能出现主备延时的情况
遇到这种情况
1 一主多从，除了备库，可以多接几个从库，来分担读的压力
2 通过binlog输出到外部系统，比如hadoop，让外部系统提供查询的能力
大事务，影响主备延时，因为主库上必须等待执行完成了，才能将binlog发送到备库，然后备库在执行相同的时间，可能更久
避免在线上系统一次性的删除大量的数据，避免在业务高峰期执行这些比较大的事务和ddl操作等。
造成主备延时的还有一个原因，就是备库的并行能力，mysql5.6提供了并行复制，slave_parallel_workers，在5.7以上，有更好的并行复制。
可靠性优先策略
在主从环境下，主库A，假如这个时候备库B上存在延时Seconds_Behind_Master，落后主库5秒，这个时候需要主从切换，（设置为read_only=on），需要等待B库上的延时为0，等待备库完全追赶了主库的日志，在做切换，这时候叫可靠性优先切换。当然在等待的这段时间内，应用是有一定的影响的。
可用性优先策略
就是强行在B库上进行更新操作，没有等待B库上完全同步和应用了日志就把改变了ip的指向，这个时候发生切换，可能会导致数据的不一致。
小结
由于主备延时的存在，切换策略就有不同的选择，在可靠性和可用性优先的策略之间，进行选择，根据不同的业务需要进行不同的选择。
在实际应用中， 更建议使用可靠性优先的策略，毕竟保证数据的准确，应该是数据库服务的底线。在这个基础上，通过减少主备的延时，提升系统的可用性。