ADSL拨号VPS包含了中国大陆（联通，移动，电信，）

中国香港，国外拨号VPS。

Prepare the transaction in the storage engine(s).
Write the transaction to the binlog, flush the binlog to disk.
Wait for at least one slave to acknowledge the reception for the binlog events for the transaction.
Commit the transaction to the storage engine(s).

半同步复制AFTER_COMMIT模式的基本流程

MySQL 5.5和5.6的半同步复制只支持AFTER_COMMIT：

Prepare the transaction in the storage engine(s).
Write the transaction to the binlog, flush the binlog to disk.
Commit the transaction to the storage engine(s).
Wait for at least one slave to acknowledge the reception for the binlog events for the transaction.

AFTER_SYNC和AFTER_COMMIT两种方式的小结

AFTER_SYNC：日志复制到Slave之后，Master再commit。
所有在master上commit的事务都已经复制到slave。
所有已经复制到slave的事务在master不一定commit了（比如，master将日志复制到slave之后，在commit之前宕机了）

AFTER_COMMIT：Master commit之后再将日志复制到Slave。
所有master上commit的事务不一定复制到slave。（比如，master commit之后，还没来得及将日志复制到slave就宕机了）
所有已经复制到slave的事务在master上一定commit了。
很明显，AFTER_COMMIT在master宕机的情况下，无法保证数据的一致性（master commit之后，还没来得及将日志复制到slave就宕机了）。本文接下来只讨论AFTER_SYNC模式。
MySQL5.7.3开始支持配置半同步复制等待Slave应答的个数：rpl_semi_sync_master_wait_slave_count 。

AFTER_SYNC模式下的异常情况分析

异常情况1：master宕机后，主备切换。

master执行事务T，在将事务T的binlog刷到硬盘之前，master发生宕机。slave升级为master。master重启后，crash recovery会对事务T进行回滚。主备数据一致。

master执行事务T，在将事务T的binlog刷到硬盘之后，收到slave的ACK之前，master发生宕机（存在pendinglog）。slave升级为master。

2.1 slave还没有收到事务T的binlog，master重启后，crash recovery会直接提交pendinglog。主备数据不一致。

2.2 slave已经收到事务T的binlog。主备数据一致。

异常情况2：master宕机后，不切换主机。只需考虑异常情况1中的2.1。

master重启后，直接提交pendinglog，此时，主备数据不一致：

slave连接上master，通过异步复制的方式获得事务T的binlog。主备数据一致。
slave还没来得及复制事务T的binlog，如果master又发生宕机，磁盘损坏。主备数据不一致，事务T的数据丢失。
异常情况处理

从上面异常情况的简单分析我们得知，半同步复制需要处理master宕机后重启存在pendinglog（slave没有应答的binlog）的特殊情况。

针对master宕机后，不进行主备切换的情形：

在crash recovery之后，master等到slave的连接和复制，直到至少有一个slave复制了所有已提交的事务的binlog。（SHOW MASTER STATUS on master and SELECT master_pos_wait() on slave）。