MySQL如何保持高可用？？
主备延迟分为两类，一类主动比如软件升级，主库所在机器按照计划下线等，另外一类是被动，比如主库所在机器掉电。
在看这个概念之前，我们先来看看“同步延迟”，与数据同步有关的时间点有三个
1.主库A完成事务，写入binlog，这是T1时刻
2.主库A将binlog发送给备库B，B接收完毕，这是T2时刻
3. 备库B执行完成这个事务，这是时刻T3。
所谓的主备延迟就是T3-T1的差值。
可以使用show slave status命令来看seconds_behind_master来看看备库延迟了多少秒。
因为在每个事务的binlog当中都有一个时间字段来记录主库写入的时间，备库他会将正在执行事务的时间字段与当前系统的时间做差，得到延迟时间。
那么我们可能会想，既然是与备库的系统时间作差实现的，那么有没有可能备库的系统时间与主库的系统时间不同，从而导致延迟时间不准呢？其实这是不必担心的，在备库连接到主库的时候，他会通过一个select unix_timestamp（）函数来获得主库的系统时间，要是发现与自己的不同，他会在计算的时候直接扣除这个时间差。
主备延迟最直接的表现是，备库消费中转日志（relay log）的速度，比主库生产binlog的速度要慢，这是什么导致的呢?
首先在有些情况下，备库的机器性能是比主库的机器性能要差的。
或者备库的压力太大，因为大多数情况下，因为主库提供了写能力，那么备库就提供一些读能力，或者一些分析语句，因为主库是直接影响业务的，所以全在备库上运行导致压力过大，耗费了大量的CPU资源从而影响了同步速度，造成了主备延迟。
要解决这种问题，我们可以多接几个从库，让从库来分担压力，或者通过binlog输出到外部系统，比如Hadoop这类系统，让外部系统提供查询的功能。
还有一种可能就是大事务造成的，因为主库上必须得等事务执行完了之后才会写入binlog，假如他执行了10分钟，就会导致10分钟的主备延迟。
在双M结构下，从状态1到状态2切换的详细过程是这样的：
判断备库B现在的seconds_behind_master，如果小于某个值（比如5秒）继续下一步，否则持续重试这一步；
把主库A改成只读状态，即把readonly设置为true；
判断备库B的seconds_behind_master的值，直到这个值变成0为止；
把备库B改成可读写状态，也就是把readonly 设置为false；
把业务请求切到备库B。
如果一开始主备延迟就长达 30 分钟，而不先做判断直接切换的话，系统的不可用时间就长达30分钟。
如果我强行将步骤4.5放到刚开始就执行，就是说不用等主备数据同步，直接将连接切换到备库B上，让备库可以读写，那么系统就没有不可用时间了。这样操作的代价是可能出现数据不一致的情况。
在紧急情况下，比如主库掉电，就不能使用可靠性优先策略，因为要等待seconds_behind_master为0，直接使用可用性优先策略，进行切换，事后再补数据。