异步复制和半同步复制

# 异步复制

#### 什么是异步复制
> Master**先提交事务**，然后写binlog，将binlog发送给Slave；

#### 异步复制的过程
1. Master 提交事务(commit)；
2. Master 将事务写入binlog buffer，dumper线程通知Slave有新的事务；
3. binlog buffer进行checkpoint；
4. Slave的`IO线程`接收到binlog并写入到自己的的中继日志，并将binlog的pos信息写入`master.info`文件，下次请求binlog的时候会将位置信息提供给Master，Master就知道从哪开始推送数据；
5. Slave的`SQL线程`读取binlog文件内容并写入到本地数据库，并在`relay-log.info` 中记录已解析的中继日志位置，当服务器重启后可以从这个文件获取中继日志解析的位置；

这时，master和slave都能看到这条新的事务，即使master挂了，slave可以提升为新的master。

#### 异步复制存在的问题
1. 当Master在写binlog的过程中宕机，则Slave将无法同步到这部分数据；Master重启后也不会重新写binlog，所以Slave等于是永远丢失了这部分数据。

2. 如果Master在写binlog的过程中宕机，或者已经写完binlog，在发送给Slave的过程中宕机，此时业务系统肯定会切换到Slave，或者将Slave升级为Master，此时业务系统将无法从Slave节点读取到这部分数据。

为了弥补以上几种场景的不足，MySQL从5.5开始推出了半同步复制。

# 半同步复制
#### 什么是半同步复制
> Master 先写binglog，将binlog发送给Slave，等待Slave返回ACK，**最后再提交事务**；

#### 半同步复制的特性
>1. 需要在主库和从库分别配置使用半同步机制；
2. Slave只有在接收到某一个事务的所有binlog，将其写入并flush到中继日志后，才会返回ACK；
3. 如果Master等待ACK的时间超过限定的值，没有得到任何一个Slave响应，那么此时Master会自动转为异步复制。当至少一个Slave重新连接时（之前的连接是不是都断开了？线程都结束了？），才会再次转为半同步复制；

#### 半同步复制的两种模式
1. **after_commit** (5.6默认)
> Master将事务写入`binlog`(sync_binlog=1)，将`binlog`发送给Slave，然后**提交事务**(commit)，
开始等待Slave返回`ACK`，收到`ACK`后，才将`CommitOK`返回给Client；

2. **after_sync** (5.7默认)
> Master将事务写入`binlog`(sync_binlog=1)，将`binlog`发送给Slave，然后等Slave返回`ACK`。
收到`ACK`后，才**提交事务**(commit)并将`CommitOK`返回给Client；