一.最终一致性

• 只要主库执行更新生成的所有binlog都会被传送到备库并被正确的执行
• 备库能达到主库一致的状态

二.主备延迟

   1.同步延迟

• 主库A执行完成一个事务，写入binlog，这时我们把这个时刻记为T1；
• 传给备库B，我们把备库B接收完这个binlog的时刻记为T2；
• 备库B执行完成这个事务，我们把这个时刻记为T3

主备延迟：同一个事务，在备库执行完成的时间和主库执行完成的时间之差----T3-T1

 2.show salve status命令

备库执行show slave status命令，返回结果显示seconds_behind_master,表示当前备库延迟了多少秒

3.seconds_behind_master计算方法

• 每个事务的binlog里面都有一个时间字段，用于记录主库上写入的时间；
• 备库取出当前正在执行的事务的时间字段的值，计算它与当前系统时间的差值

三.导致主备延迟的来源

1. 备库机器性能比主库差可能导致主备延迟

2. 备库上做统计分析与查询消耗了大量的CPU资源                                                                   解决方案:

• 一主多从：多连接从库分担读的压力
• binlog输出到外部系统，比如Hadoop系统，让外部系统提供统计类查询的能力

   3.大事务

四.可靠性优先策略

• 判断备库B现在的second_behind_master,如果小于5s就继续，否则重试
• 把主库A改成只读状态，把readonly设置为true
• 判断备库B的second_behind_master的值，直到值变为0（保持可靠性---需要足够小，因为此时不可用）
• 把备库B改为可读写状态，也就是readonly设置为false；
• 将业务请求切换为备库B

五.可用性优先策略

• 将步骤4 把备库B改为可读写状态，也就是readonly设置为false；
• 步骤5  将业务请求切换为备库B
• 直接执行不等数据同步一致

缺点：

   数据不一致

• 在满足数据可靠性的前提下，MYAQL高可用系统的可用性，是依赖主备延迟的

• 延迟时间越小，在主库故障服务恢复时间越短可用性越高