在前两天刚刚释放的mysql5.7.2代码中，可以看到semisync终于做了进一步的改进；在之前用户线程的逻辑为：
1.在binlog写入文件后，调用semisync记录事务位点信息；
2.sync binlog（如果需要）
3.将事务提交；
4.等待备库ack；
该逻辑存在的问题是，当主库crash时，可能binlog还没有传递到备库，这时候做一次主备切换，备库提升为新主库，老主库降级为新备库，这时候主备库是处于不一致状态的；
而在5.7.2中，可以使用如下逻辑：
1.在binlog写入文件后，记录事务位点信息；
2.sync binlog(如果需要)
3.等待备库ack;
4..将事务提交；
在新版本5.7.2中，增加了新的hook函数：after_sync，通过参数rpl_semi_sync_master_wait_point来控制，默认为after_sync，如果设置为after_commit则在commit之前等待备库ack，这可以确保备库接受到了最新的binlog，即使主库随后crash掉，也可以在recovery阶段恢复，因为主库已经完成了prepare阶段；
尽管该特性仅存在于官方5.7.2中，使用mysql5.6的同学也可以很容易的把这个特性port过来，因为代码的改动量非常小.但需要注意一个问题，即在rotate时,由于需要持有lock_log并等待所有preare的事务完成commit，而dump线程也需要持有lock_log来发送binlog，这里rotate, 用户线程等待ack， dump线程三者很容易形成死锁。
解释下，rotate为什么要等待prepare的线程commit，由于我们默认使用的xa事务，在crash recovery时，会扫描最后一个binlog文件，找出其中的xid，然后再跟所有处于prepare状态的事务xid做对比，如果事务xid存在于binlog，则将该prepare的事务commit，否则rollback。
如果rotate时不等待prepare的事务commit,那么我们可能需要往前扫描多个binlog文件来
关于这个问题，有几种解决办法：
1.mariadb版本，rotate线程无需等待prepare线程commit，而是在binlog中写入事件的方式，类似于给binlog做了个checkpoint。
2.mysql5.7.2/facebookmysql5.6, 通过维护当前active的binlog尾部偏移量的方式来解除dump线程对lock_log锁的需求