Mysql的高可用

主备延迟

所谓主备延迟，就是同一个事务，在备库执行完成的时间和主库执行完成的时间之间的差值。

你可以在备库上执行show slave status命令，它的返回结果里面会显示seconds_behind_master，用于表示当前备库延迟了多少秒。

有些部署条件下，备库所在机器的性能要比主库所在的机器性能差。
第二种常见的可能了，即备库的压力大：由于主库直接影响业务，大家使用起来会比较克制，反而忽视了备库的压力控制。结果就是，备库上的查询耗费了大量的CPU资源，影响了同步速度，造成主备延迟。

解决方式：
- 一主多从。除了备库外，可以多接几个从库，让这些从库来分担读的压力。
- 通过binlog输出到外部系统，比如Hadoop这类系统，让外部系统提供统计类查询的能力。
第三种，大事务。如果一个主库上的语句执行10分钟，那这个事务很可能就会导致从库延迟10分钟。

例如：
- 一次性地用delete语句删除太多数据
- 大表DDL

在图中的双M结构下，从状态1到状态2切换的详细过程是这样的：

这个切换流程，一般是由专门的HA系统来完成的，我们暂时称之为可靠性优先流程。

如果我强行把上面的步骤4、5调整到最开始执行，也就是说不等主备数据同步，直接把连接切到备库B，并且让备库B可以读写，那么系统几乎就没有不可用时间了。

例如：可用性优先策略，且binlog_format=mixed时的切换流程和数据结果。

现在，我们一起分析下这个切换流程：

步骤2中，主库A执行完insert语句，插入了一行数据（4,4），之后开始进行主备切换。
步骤3中，由于主备之间有5秒的延迟，所以备库B还没来得及应用“插入c=4”这个中转日志，就开始接收客户端“插入 c=5”的命令。
步骤4中，备库B插入了一行数据（4,5），并且把这个binlog发给主库A。
步骤5中，备库B执行“插入c=4”这个中转日志，插入了一行数据（5,4）。而直接在备库B执行的“插入c=5”这个语句，传到主库A，就插入了一行新数据（5,5）。

最后的结果就是，主库A和备库B上出现了两行不一致的数据。可以看到，这个数据不一致，是由可用性优先流程导致的。

但设置binlog_format=row后，因为row格式在记录binlog的时候，会记录新插入的行的所有字段值，所以最后只会有一行不一致。而且，两边的主备同步的应用线程会报错duplicate key error并停止。

从上面的分析中，你可以看到一些结论：

使用row格式的binlog时，数据不一致的问题更容易被发现。而使用mixed或者statement格式的binlog时，数据很可能悄悄地就不一致了。如果你过了很久才发现数据不一致的问题，很可能这时的数据不一致已经不可查，或者连带造成了更多的数据逻辑不一致。
主备切换的可用性优先策略会导致数据不一致。因此，大多数情况下，我都建议你使用可靠性优先策略。毕竟对数据服务来说的话，数据的可靠性一般还是要优于可用性的。