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

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

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

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

与异步复制相比，半同步复制提供了更好的数据完整性，因为当提交成功返回时，可以知道数据至少存在于两个位置。在半同步源从所需数量的副本接收到确认之前，事务处于暂停状态，不提交。

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

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

源和副本之间的半同步复制原理如下:

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

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

对于不在事务上下文中出现的语句(也就是说，当没有事务开始时)开始事务或设置自动提交= 0)，自动提交被启用，每个语句隐式提交。对于半同步复制，源块用于每个这样的语句，就像显式事务提交一样。

默认情况下，源在将二进制日志同步到磁盘之后，但在将事务提交到存储引擎之前，等待事务接收的副本确认。属性将事务提交到存储引擎后，可以对源进行配置，以等待副本确认rpl_semi_sync_source_wait_point或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，它增加了共享锁，避免了不必要的锁获取。随着副本数量的增加，这些设置会有所帮助，因为锁争用会降低性能。半同步复制源服务器还可以通过启用这些系统变量获得性能优势，因为它们使用与副本相同的锁定机制。