1. 备库IO线程从哪个位置读取主库的 binlog event 的？
2. 备库SQL线程如何记录执行到的 relaylog 的位点？

下面对这几个问题挨个解答。

问题 1: 主库什么时间将产生的binlog 真正刷到文件中

事务ordered_commit 中，会将 thd->cache_mngr 中的 binlog cache 写入到 binlog 文件中，但并没有执行fsync()操作，即只将文件内容写入到 OS 缓存中，详细 bt 为：

commit 时，会判断是否将产生的 binlog flush 到文件中，即执行 fsync操作，详细bt 为：

1. 主备同步无延迟，此时主库机器恢复后，备库接着之前的位点重新拉binlog, 但是主库由于没有fsync最后的binlog，所以会返回1236 的错误：
2. 备库没有读到主库失去的binlog，此时备库无法同步主库最后的更新，备库不可用。

问题 2: 备库IO线程从哪个位置读取主库的binlog event 的

更新位点信息的 bt 如下：

备库通过 master_log_info 来记录主库的相关信息，通过参数 sync_master_info 来设置备库经过多少个 binlog event 来更新已经读取到的位点信息。当stop slave时，会把正常的位点更新到master_log_info中，此时，如果最后的位点不是commit，则在start slave后，会继续上一位点拉取 binlog，从而造成同一个事务的binlog event分布在不同的binlog file中，此时如果执行顺利则不会有问题；如果在拉这个事务的过程中，sql 线程出错中断，在并行复制下会引起分发线程停在事务中间，再次启动的时候，会从上一次分发的事务继续分发，会造成在并行复制中不可分发的情况，因此需要注意。

当 sync_master_info > 1000时，可能在第1000个binlog 拉取的时候机器出问题，此时重启后会从主库多拉999个 binlog event，造成事务在备库多次执行问题，对于没有 primary key, unique key 可能会有问题，造成主备数据不一致，最常遇到的是1062问题。

同问题2一样，相关的 bt 也类似， 记录的是备库已经执行了的最后的位点，这个位点不会处于事务中间，即是每 sync_relay_log_info 个事务更新一下这个位点。

相关 bug 原因: 备库异常 crash 后，可能造成事务在拉取过程中被重新拉取，binlog序列如下：

在并行复制条件下，由于出现了不完整的事务，所以会造成绑定事务信息无法恢复，造成hang的情况，详情见 bug 分析。

问题 4: 备库IO线程何时将cache中的event 刷到relay log 文件中的

MySQL 通过 sync_binlog，sync_master_info，，sync_relay_log 来记录相关的位点信息，出于性能考虑以及程序本身的健壮性，引入了各式要样的bug，类似的bug在此不在列举，那么有没有更好的方法来记录这些信息呢，当然有，即GTID 协议，会在下期月报分析。