MySQL 5.6版本说明
除了内置的异步复制，MySQL 5.6还支持通过插件实现的半同步复制接口。本节讨论什么是半同步复制及其工作原理。下面几节介绍半同步复制的管理界面以及如何安装、配置和监视它。
MySQL复制默认是异步的。源将事件写入其二进制日志，副本在准备好时请求它们。源不知道副本是否检索和处理了事务，也不知道何时检索和处理了事务，也不能保证任何事件到达任何副本。使用异步复制，如果源崩溃，它提交的事务可能没有传输到任何副本。在这种情况下，从源到副本的故障转移可能导致故障转移到缺少相对于源事务的服务器。
使用完全同步复制，当源提交事务时，所有副本也必须在源返回执行事务的会话之前提交事务。完全同步复制意味着可以在任何时候从源故障转移到任何副本。完全同步复制的缺点是完成事务可能会有很大的延迟。
半同步复制介于异步复制和全同步复制之间。源等待至少一个副本接收并记录事件，然后提交事务。源不需要等待所有副本确认收到，它只需要副本的确认，而不需要事件在副本端完全执行和提交。因此，半同步复制保证如果源崩溃，它提交的所有事务都已传输到至少一个副本。
重要的
对于半同步复制，如果源崩溃并进行了故障转移到副本，则不应将失败的源重用为复制源服务器，而应丢弃。它可能拥有任何副本都不承认的事务，因此在故障转移之前没有提交这些事务。
与异步复制相比，半同步复制的性能影响是为了提高数据完整性而进行的权衡。减速的程度至少是将提交发送到副本并等待副本确认接收的TCP/IP往返时间。这意味着半同步复制最适合通过快速网络进行通信的近距离服务器，而最不适合通过慢速网络进行通信的远程服务器。通过限制二进制日志事件从源发送到副本的速度，半同步复制还对繁忙会话设置了速率限制。当一个用户太忙时，这会降低速度，这在某些部署情况下很有用。
源和副本之间的半同步复制操作如下:
副本在连接到源时指示它是否具有半同步能力。
如果在源端启用了半同步复制，并且至少有一个半同步副本，则在源端执行事务提交的线程在提交完成后会阻塞，并等待，直到至少一个半同步副本确认它已接收到事务的所有事件，或者直到超时发生。
只有在事件写入事务的中继日志并刷新到磁盘之后，副本才承认收到事务的事件。
如果在没有任何副本确认事务的情况下发生超时，源将恢复到异步复制。当至少有一个半同步副本恢复时，源端返回到半同步复制。
源端和复制端都必须启用半同步复制。如果源端禁用了半同步复制，或者源端启用了半同步复制但没有复制，则源端使用异步复制。
当源处于阻塞状态(在执行提交后等待副本的确认)时，它不会返回执行事务的会话。当块结束时，源返回到会话，然后该会话可以继续执行其他语句。此时，事务已经在源端提交，并且至少一个副本已经确认其事件的接收。
阻塞也发生在写入二进制日志的回滚之后，当修改非事务性表的事务回滚时发生。回滚事务被记录下来，尽管它对事务性表没有影响，因为对非事务性表的修改不能回滚，必须发送到副本。
对于不在事务上下文中出现的语句(也就是说，当没有事务启动时)开始事务或SET autocommit = 0)时，自动提交被启用，每个语句都隐式提交。对于半同步复制，源在提交每个这样的语句后阻塞，就像显式事务提交时一样。