之前的文章提到过，Mysql 是支持互为主从的，这种结构可以在 某台库宕机后，将客户端的请求转发到 另外一个库 来实现故障迁移的效果。
但是如果直接转移，不等B消费掉 relay log 的话，会发生 数据不一致的现象。
同样举 A，B 两个库。A 充当写库，B充当 从库。
当 A 挂掉的时候，假设 B 已经接收到 A 的所有 binlog （另一种可能的情况是 A 有的 binlog 没发出去，没有被 B 接收到）
一部分 binlog 可能还以 relay log 的形式 存在于 从库，如果不将这部分 消化掉，就可能导致 B 无法承接上 之前 A 的状态，导致数据不一致（如果A没能发出 所有 binlog ，那么注定不一致，但是当前情况是假设都发出了）
从库从 主库取得 binlog 之前会通过 SELECT UNIX_TIMESTAMP() 来校正时间，并且binlog 上的每一条语句都会 记录时间，这样的话，在从库执行完 事务之后会 将当前时间 和 binlog 上的事务的时间相减，得出的差值就是主备延迟，可通过 show slave status 查看 seconds_behind_master 得出
导致 B 久久无法消化完所有 binlog 的原因 可能有：
1. B库上的 读压力太大，之前B库做为 从库，可能担负了很多的读请求，但是实际上B库还需要写 从 A 上传来的 binlog 的记录，如果 B 之前负责了 大部分读请求，那么之前就会较慢地消耗 传来的binlog。同理，B库的配置差的话，也会有同样的后果。
2. 主库执行了 长事务，主库的长事务传过来了，从库也要执行，这样的话，从库要长时间执行这个 长事务，那么之后的 binlog 都被堵住了。
3.另一种情况是 锁的问题，比如虽然 从库上开了 readonly = true，但是其他客户端连接执行一个 begin ; select * from table;
如果此时恰巧主库发来 针对 t 的ddl，那么超级线程（这个线程相当于一个链接，用来执行 relay log 的内容）将被卡住，直到上述事务完成
如果上述事务一直不提交，那么将是灾难性的。
