除了内置的异步复制外，MySQL 8.3 还支持半同步复制插件接口。本节讨论半同步复制是什么及其工作原理。以下部分涵盖半同步复制的管理接口、安装、配置和监控。

MySQL 复制默认是异步的。源服务器将事件写入二进制日志，副本服务器在准备好时请求它们。源服务器不知道副本服务器何时检索和处理事务，也没有保证任何事件最终会到达任何副本服务器。如果源服务器崩溃，已经提交的事务可能没有传输到任何副本服务器。在这种情况下，从源服务器到副本服务器的故障转移可能会导致转移到缺少事务的服务器。

与异步复制相比，全同步复制意味着源服务器在提交事务之前，所有副本服务器都已经提交了事务。这意味着从源服务器到任何副本服务器的故障转移可以随时进行。但是，全同步复制的缺点是可能会有很长的延迟来完成事务。

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

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

与全同步复制相比，半同步复制速度更快，因为它可以根据需要平衡数据完整性（副本服务器确认数量）和提交速度，后者由于需要等待副本服务器确认而变慢。

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

半同步复制在源服务器和副本服务器之间工作如下：

源阻塞（等待副本确认）时，不会返回到执行事务的会话。阻塞结束后，源将返回到会话，该会话然后可以继续执行其他语句。此时，事务已经在源侧提交，并且至少一个副本已经确认了其事件。源必须在每个事务中收到多少个副本确认才能返回到会话是可配置的，默认为一个确认（见第 19.4.10.2 节，“配置半同步复制”）。

回滚也会阻塞，回滚被写入二进制日志，这发生在回滚修改非事务表的交易时。即使回滚没有效果，因为非事务表的修改不能回滚，必须将其发送到副本。

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

默认情况下，源在将二进制日志同步到磁盘后等待副本确认事务接收，然后再将事务提交到存储引擎中。或者，您可以配置源，使其在将事务提交到存储引擎后等待副本确认，使用 rpl_semi_sync_source_wait_point 系统变量。该设置影响复制特性和客户端在源上可以看到的数据。有关更多信息，请参阅 第 19.4.10.2 节，“配置半同步复制”。

您可以通过启用系统变量 replication_sender_observe_commit_only，限制回调，并启用 replication_optimize_for_static_plugin_config，添加共享锁并避免不必要的锁定获取，以提高半同步复制的性能。这些设置在副本数量增加时特别有用，因为锁定争用可能会减慢性能。半同步复制源服务器也可以从启用这些系统变量中受益，因为它们使用与副本相同的锁定机制。