除了内置的异步复制外，MySQL 5.7 还支持由插件实现的半同步复制接口。本节讨论什么是半同步复制及其工作原理。以下部分介绍了半同步复制的管理界面以及如何安装、配置和监控它。

MySQL 复制默认是异步的。源将事件写入其二进制日志，副本在准备就绪时请求它们。源不知道副本是否或何时检索并处理了事务，并且不能保证任何事件都会到达任何副本。对于异步复制，如果源崩溃，它提交的事务可能还没有传输到任何副本。在这种情况下，从源到副本的故障转移可能会导致故障转移到缺少与源相关的事务的服务器。

对于完全同步复制，当源提交事务时，所有副本也必须在源返回到执行事务的会话之前提交事务。完全同步复制意味着随时可以从源故障转移到任何副本。完全同步复制的缺点是完成事务可能会有很多延迟。

半同步复制介于异步和完全同步复制之间。源等待直到至少一个副本已接收并记录事件（所需的副本数是可配置的），然后提交事务。源不等待所有副本确认接收，它只需要来自副本的确认，而不是事件已在副本端完全执行和提交。因此，半同步复制保证如果源崩溃，它提交的所有事务都已传输到至少一个副本。

与异步复制相比，半同步复制提供了改进的数据完整性，因为当提交成功返回时，已知数据至少存在于两个地方。在半同步源收到来自所需数量的副本的确认之前，事务将暂停且不会提交。

与完全同步复制相比，半同步复制更快，因为它可以配置为平衡您对数据完整性的要求（确认收到事务的副本数）和提交速度，由于需要等待，提交速度较慢副本。

与异步复制相比，半同步复制的性能影响是提高数据完整性的权衡。减速量至少是将提交发送到副本并等待副本确认接收的 TCP/IP 往返时间。这意味着半同步复制最适合通过快速网络进行通信的近距离服务器，而最不适合通过慢速网络进行通信的远程服务器。半同步复制还通过限制二进制日志事件从源发送到副本的速度来限制繁忙会话的速率。当一个用户太忙时，这会减慢速度，这在某些部署情况下很有用。

源与其副本之间的半同步复制操作如下：

当源处于阻塞状态（等待来自副本的确认）时，它不会返回到执行事务的会话。当块结束时，源返回到会话，然后可以继续执行其他语句。此时，事务已在源端提交，并且其事件的接收已被至少一个副本确认。源在返回会话之前必须在每个事务中接收的副本确认数可以使用 rpl_semi_sync_master_wait_for_slave_count 系统变量进行配置，默认值为 1。

在写入二进制日志的回滚之后也会发生阻塞，回滚修改非事务表的事务时会发生这种情况。回滚的事务即使对事务表没有影响也会被记录下来，因为对非事务表的修改无法回滚，必须发送到副本。

对于不在事务上下文中出现的语句（即，当没有事务以 START TRANSACTIONor 开始时SET autocommit = 0），启用自动提交并且每个语句隐式提交。对于半同步复制，每个这样的语句的源块，就像它对显式事务提交所做的那样。

rpl_semi_sync_master_wait_point 系统变量控制半同步复制源在将状态返回给提交事务的客户端之前等待副本确认事务接收的时间点 。 这些值是允许的：

这些设置的复制特征不同如下：