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

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

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

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

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

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

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

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

当源处于阻塞状态（等待来自副本的确认）时，它不会返回到执行事务的会话。当块结束时，源返回到会话，然后可以继续执行其他语句。此时，事务已在源端提交，并且其事件的接收已被至少一个副本确认。在返回会话之前，源必须在每个事务中接收的副本确认数是可配置的，并且默认为一个确认（请参阅 第 17.4.10.2 节，“配置半同步复制”）。

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

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

默认情况下，源在将二进制日志同步到磁盘之后等待事务接收的副本确认，但在将事务提交到存储引擎之前。rpl_semi_sync_source_wait_point 作为替代方案，您可以配置源，以便源在将事务提交到存储引擎后使用or rpl_semi_sync_master_wait_point 系统变量等待副本确认 。此设置会影响复制特征和客户端可以在源上看到的数据。有关详细信息，请参阅 第 17.4.10.2 节，“配置半同步复制”。

从 MySQL 8.0.23 开始，您可以通过启用 replication_sender_observe_commit_only限制回调的系统变量和 replication_optimize_for_static_plugin_config添加共享锁并避免不必要的锁获取来提高半同步复制的性能。随着副本数量的增加，这些设置会有所帮助，因为锁的争用会降低性能。半同步复制源服务器也可以从启用这些系统变量中获得性能优势，因为它们使用与副本相同的锁定机制。