Mysql 半同步复制

        传统的mysql的主从复制也就是异步复制，依靠mysql binary log进行数据复制。一台master主节点和从slave 从节点。

1. 主从复制：事务1写入binlog buffer，dumper 线程通知slave有新的事务；binlog buffer 进行checkpoint；slave的io线程接收到dumper进程发送的日志，并写入到本地的relay log；slave的sql线程写入到本地数据库，这时数据已经一致了。

1. 异常复制：事务1写入binlog buffer，dumper 线程通知slave有新的事务；binlog buffer 进行checkpoint；slave可能因为网络不稳定、主机宕机，一直没有收到传来的事务；master 挂掉，slave提升为新的master，事务1就丢失了。
2. 问题点：主机和从机事务更新的不同步，当并发数上来，slave因为要顺序执行master批量事务，导致很大的延迟。

        为了弥补以上业务场景的不足，mysql从5.5开始推出了半同步。即在master的dumper线程通知slave后，增加了一个ack，即是否成功收到事务1的标志码。也就是dumper线程除了发送事务1到slave，还承担了接收slave的ack工作。如果出现异常，没有收到ack，那么将自动降级为普通的复制，直到异常修复。

5.7 半同步复制的改进，主从一致性加强, 支持在事务commit前等待ACK

5.7的半同步最关键的一个新增参数是rpl_semi_sync_master_wait_point 。

  1） AFTER_COMMIT

        master将每个事务写入binlog ,传递到slave 刷新到磁盘(relay log)，同时主库提交事务。master等待slave 反馈收到relay log，只有收到ACK后master才将commit OK结果反馈给客户端。

   2）  AFTER_SYNC （5.7的默认值）

        master 将每个事务写入binlog , 传递到slave 刷新到磁盘(relay log)。master等待slave 反馈接收到relay log的ack之后，再提交事务并且返回commit OK结果给客户端。 即使主库crash，所有在主库上已经提交的事务都能保证已经同步到slave的relay log中。