目标
主库宕机不丢数据（Master Failover without data loss）
facebook有两篇不错的文章：
1. Loss Less Semisync
半同步复制实现的关键点是Master对于事务提交过程特殊处理。目前实现半同步复制主要有两种模式，AFTER_SYNC模式和AFTER_COMMIT模式。两种方式的主要区别在于是否在存储引擎提交后等待Slave的ACK。
下面展示了半同步复制中，binlog的提交过程。
1. binlog prepare (doing nothing)
2. innodb prepare (fsync)
3. binlog commit (writing to fscache)
4. binlog commit (fsync)
5. loss-less semisync wait (AFTER_SYNC)
6. innodb commit (releasing row locks, changes are visible to other users)
7. normal semisync wait (AFTER_COMMIT)半同步复制是否能保证不丢数据？
我们通过几种场景来简单分析下。
第一种情况：假设Master前4步binlog commit执行成功后，binlog还没来得及传递给Slave，此时Master挂了，Slave作为新Master提供服务，那么备库比主库要少一个事务(因为主库的redo 和binlog已经落盘)，但是不影响用户，对于用户而言，这个事务没有成功返回，那么提交与否，用户都可以接受，用户一定会进行异常捕获而重试。
第二种情况，假设innodb commit执行成功后，binlog还没来得及传递给Slave，此时Master挂了，此时与第一种情况一样，备库比主库少一个事务。如下图所示，在AFTER_COMMIT模式下，user1在innodb commit执行完后，其他用户可以看到该事务的更新，而切换到备库后，却发现再次读这个更新又没了，这个就发生了“幻读”，如果其他事务依赖于这个更新，则会对业务逻辑产生影响。当然这仅仅是极端情况。
AFTER_SYNC模式可以解决“幻读”问题。master在AFTER_SYNC模式下，Fsync binlog后，就开始等待Slave同步。那么在进行innodb commit后，即其它事务能看到该事务的更新时，Slave已经成功接收到binlog，即使发生切换，Slave拥有与Master同样的数据，不会发生“幻读”现象。但是对于上面描述的第一种情况，结果是一样的。
所以，在极端情况下，半同步复制的Master-Slave会有一个事务不一致，但是对于用户而言，由于这个事务并没有成功返回给用户，所以无论事务提交与否都是可以接受的，用户有必要进行查询或重试，判读是否更新成功。或者我们想想，对于单机而言，若事务执行成功后，返回给用户时，网络断了，用户也是面临一样的问题，所以，这不是半同步复制的问题。对于提交返回成功的事务，版同步复制保证Master-Slave一定是一致的，从这个角度来看，半同步复制不会丢数据，可以保证Master-Slave的强一致性。
2. Reduce durability on master
以前mysql5.6有个Bug: 主库在(2)(3)之间宕机，接着主库故障恢复后，主备之间的复制会中断，备库会报1206的错。
(1)master writes to binlog (writing to kernel buffer)
(2)binlog dump threads read the binlog events and send to slaves
(3)master flushes to binlog (fsync to binlog file)为什么会有这个Bu*生呢？原因是在5.6仅仅只是在writing to kernel buffer阶段持有LOCK_log锁。所以在 fsync()完成之前，binlog dump线程就可以读取主库的binlog，发送到备库去。
为了修复这个bug，主库增加了持有LOCK_log锁的时间，直到fsync()结束后释放。这个改进点退化了半同步复制的性能。因为在5.6中，LOCK_log锁是一个非常热的mutex锁。binlog dump线程和用户线程都需要去持有LOCK_log锁。
不过比较好的是，将持久化参数设置成非严格模式（sync_binlog=0;innodb_flush_log_at_trx_commit=0|2），可以缓解LOCK_log锁带来的性能退化。
对于LOCK_log锁的优化，可以看看这个链接：
http://my-replication-life.blogspot.com/2013/09/dump-thread-enhancement.html
http://www.actionsky.com/docs/archives/129
- 主库端拆分LOCK_log
在主库上，binlog的写入和读取都需要同一把锁来保护，也就是LOCK_log，当写入负载较大时，LOCK_log成为热点锁；而对于dump线程而言，每一个dump线程在读取binlog事件时，都需要先持有LOCK_log锁；dump线程越多，引起的竞争越激烈。
当dump线程无法及时获取LOCK_log锁时，就会影响发送binlog到备库的速率，进而影响备库IO线程返回ACK的速率。
拆分的思路也很简单，就是每次写入binlog时，维持该binlog文件末尾的偏移量；在该偏移量之前我们都可以安全读取binlog文件而无需加锁。
- 备库端拆分LOCK_log
首先区分一点，备库的LOCK_log属于relay log，和主库的LOCK_log属于不同的类对象。 备库上，SQL线程与IO线程在一种情况下会存在LOCK_log竞争，也就是当前SQL线程执行的relylog和IO线程写入的relaylog是同一个文件时，这时候IO线程和SQL线程使用的是同一个IO CACHE来操作文件，因此必须使用LOCK_log来保证读和写的互斥；
为了分拆LOCK_log，需要实现如下两点： a.SQL线程总是在读取事件时，使用自有的IO CACHE，而不是和IO线程公用IO CACHE b.和主库LOCK_log拆分类似，需要在IO线程写入relay log时，维持文件末尾偏移量，SQL线程可以根据该偏移量安全的读取事件