除了内置的异步复制外，MySQL 8.4 还支持通过插件实现的半同步复制接口。这一部分讨论半同步复制是什么和它是如何工作的。下面的部分涵盖半同步复制的管理接口、安装、配置和监控。

MySQL 复制默认是异步的。源服务器将事件写入到二进制日志中，副本服务器请求事件时写入。源服务器不知道副本服务器何时或是否已经请求了事件，并且没有任何保证事件是否已经到达了副本服务器。使用异步复制，如果源服务器崩溃，可能会导致副本服务器缺少事务。

使用完全同步复制时，当源服务器提交事务时，所有副本服务器都已经提交了事务，然后源服务器返回到执行事务的会话。完全同步复制意味着可以在任何时候从源服务器到副本服务器进行故障转移。完全同步复制的缺点是可能会出现延迟来完成事务。

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

相比异步复制，半同步复制提供了更好的数据一致性，因为当提交返回成功时，知道数据已经存在至少两个地方。直到半同步源服务器从所需的副本服务器接收确认，事务将保持不提交。

相比完全同步复制，半同步复制更快，因为它可以根据您的数据一致性需求（副本服务器确认的数量）和事务提交速度进行平衡。

半同步复制相比异步复制的性能影响是数据完整性的权衡。至少的延迟是将提交发送到备用服务器并等待备用服务器确认的TCP/IP回环时间。这意味着半同步复制在靠近的服务器之间使用快速网络时效果最好，在远距离的服务器之间使用慢速网络时效果最差。半同步复制还将对繁忙会话施加速率限制，通过限制源服务器将二进制日志事件发送到备用服务器的速度。当一个用户太忙，这可以在某些部署情况下有用。

半同步复制在源服务器和备用服务器之间的工作方式如下：

当源服务器阻塞（等待备用服务器的确认）时，它不会返回到执行事务的会话。等到阻塞结束，源服务器将返回到会话，然后可以继续执行其他语句。在这个点上，事务已经在源服务器上提交了，并且至少一个备用服务器已经确认了事务的事件。可以配置源服务器必须从备用服务器接收的确认次数（见第19.4.10.2节，“配置半同步复制”）。

阻塞也会在回滚事务时发生，这发生在对非事务表进行回滚时。回滚的事务将被记录，即使事务对事务表没有影响，因为对非事务表的修改不能被回滚并且必须被发送到备用服务器。

在没有事务上下文（即没有使用START TRANSACTION或SET autocommit = 0）时的语句中，自动提交是启用的，每个语句都隐式提交。使用半同步复制时，源将阻塞每个语句，就像它对明确事务提交那样。

默认情况下，源在将二进制日志同步到磁盘后，但在提交事务到存储引擎之前，等待复制节点确认事务接收。但是，您也可以配置源，以便在提交事务到存储引擎后等待复制节点确认，使用rpl_semi_sync_source_wait_point系统变量。这设置将影响复制特性和客户端在源上看到的数据。更多信息，请见第19.4.10.2节，“半同步复制配置”。

您可以通过启用系统变量replication_sender_observe_commit_only和replication_optimize_for_static_plugin_config来改进半同步复制的性能，这些设置限制回调和添加共享锁，以避免不必要的锁定获取。这些设置在 replica 数量增加时非常有用，因为锁定竞争可能会影响性能。半同步复制源服务器也可以从启用这些系统变量中获得性能提高，因为它们使用相同的锁定机制如 replica。