文章目录

18.5.4 分布式恢复
- 18.5.4.1 分布式恢复的连接
- - 18.5.4.1.1 为分布式恢复端点选择地址
  - 18.5.4.1.2 分布式恢复的压缩
  - 18.5.4.1.3 用于分布式恢复的复制用户
  - 18.5.4.1.4 分布式恢复的 SSL 和身份验证
- 18.5.4.2 分布式恢复的克隆
- - 18.5.4.2.1 克隆的先决条件
  - 18.5.4.2.2 克隆的阈值
  - 18.5.4.2.3 克隆操作
  - 18.5.4.2.4 克隆的其他用途
- 18.5.4.3配置分布式恢复
- - 连接尝试次数
  - 连接尝试的睡眠时间间隔
  - 在线标记加入成员
- 18.5.4.4 分布式恢复的容错
- 18.5.4.5 分布式恢复的工作原理
- - 视图和视图更改
  - 开始：稳定组
  - 视图更改：加入成员
  - 状态传输：补齐
  - 结束：补齐完成

18.5.4 分布式恢复

术语翻译说明
Distributed Recovery：分布式恢复。
Relay Log：中继日志。
State Transfer：状态传输，将数据库的一致性状态从供体传输给需要同步的受体（或叫做 加入成员）。准确来讲，应翻译为“传输、传递”而不是“转换、转移”，因为操作完成后供体的“状态”并没有被移除，仍然存在。

以下两个术语由于 MySQL 新版本更新仍存在的遗留问题，MySQL 官方正在逐步替换，但替换速度不尽如人意，只是每次小版本更新替换一部分，至今仍有很多没有替换的部分：

Source：源，同旧版本的 Master ；

Replica：副本，同旧版本的 Slave 。
Endpoint：终端，端点，是由连接使用的 IP 地址（或主机名）和端口、通信协议、加密传输协议、API接口等组成的逻辑概念。
Advertise：公布，广播。
Catch up：追赶，赶上，补齐。

每当成员加入或重新加入复制组时，它必须在加入之前或离开时赶上组成员应用的事务。此过程称为分布式恢复。

加入成员首先检查其 group_replication_applier 通道的中继日志，以查找任何已从该组接收但尚未应用的事务。如果加入成员以前在组中，它可能会发现在离开之前未应用的事务，在这种情况下，它会首先应用这些事务。新加入组的成员没有任何要应用的内容。

之后，加入成员连接到在线现有成员以执行状态传输。加入成员转存在其加入之前或离开时在组中发生的所有事务，这些事务由现有成员（称为供体，doner）提供。接下来，加入成员应用在进行状态传输时在组中发生的事务。当这个过程完成时，加入成员已经赶上了组中剩余的服务器，它开始正常参与组。

组复制在分布式恢复期间使用以下方法的组合进行状态传输：

使用 MySQL 8.0.17 中提供的克隆插件功能的 远程克隆操作 。要启用此状态传输方法，必须在组成员和加入成员上安装克隆插件。组复制自动配置所需的克隆插件设置并管理远程克隆操作。
供体二进制日志状态传输 。从供体的二进制日志复制并将事务应用于加入成员。此方法使用名为 group_replication_recovery 的标准异步复制通道，该通道在供体和加入成员之间建立。

在对加入成员发出START GROUP_REPLICATION后，组复制会自动选择这些方法的最佳组合进行状态传输。为此，组复制检查哪些现有成员适合作为供体，加入成员需要从供体处获取多少事务，以及任何组成员的二进制日志文件中是否不再存在任何必需的事务。如果加入成员和合适的供体之间的事务差距很大，或者某些必需的事务不在任何供体的二进制日志文件中，则组复制将通过远程克隆操作开始分布式恢复。如果没有大的事务间隙，或者没有安装克隆插件，则组复制将直接进行 供体二进制日志状态传输 。

在 远程克隆操作 期间，将删除加入成员上的现有数据，并替换为供体数据的副本。当远程克隆操作完成且加入成员已重新启动时，将执行 供体二进制日志状态传输 ，以获取远程克隆操作进行时组应用的事务。
在 供体二进制日志状态传输 期间，加入成员复制并应用供体二进制日志中的所需事务，在接收到事务时应用事务，直到二进制日志记录加入成员已加入组（视图更改事件）。在这一过程中，加入成员缓冲组应用的新事务。当二进制日志的状态传输完成时，加入成员才应用缓冲的事务。

当加入成员更新了组的所有事务时，它将在线声明，并可以作为正常成员加入组，分布式恢复完成。

提示
二进制日志状态传输是组复制用于分布式恢复的基本机制，如果复制组中的供体和加入成员未设置为支持克隆，则这是唯一可用的选项。由于二进制日志的状态传输基于传统的异步复制，因此如果加入组的服务器根本没有组的数据，或者数据取自非常旧的备份映像，则可能需要很长时间。因此，在这种情况下，建议在将服务器添加到组之前，通过传输组中已存在的服务器的最新快照，使用组的数据进行建立。这最大限度地减少了分布式恢复所需的时间，并减少了对供体服务器的影响，因为它们所须保留和传输的二进制日志文件更少了。

18.5.4.1 分布式恢复的连接

当加入成员在分布式恢复期间连接到在线现有成员以进行状态传输时，加入成员充当连接上的客户端，而现有成员充当服务器。当通过此连接（使用异步复制通道 group_replication_recovery ） 供体二进制日志状态传输时，加入成员充当副本，现有成员充当源。当通过此连接进行远程克隆操作时，加入成员充当接收方，现有成员充当供体。应用于组复制环境之外的那些角色的配置设置也可以应用于组副本，除非它们被组复制特有的配置设置或行为覆盖。

现有成员为分布式恢复向加入成员提供的连接与组复制用于组的在线成员之间通信的连接不是同一个。

用于远程 XCom 实例之间 TCP 通信的组复制的组通信引擎（XCom，Paxos 变体） 的连接由 group_replication_local_address 系统变量指定。此连接用于在线成员之间的 TCP/IP 消息。与本地实例的通信通过使用共享内存的输入通道进行。
对于分布式恢复，在 MySQL 8.0.20 之前，组成员向加入成员提供标准的 SQL 客户端连接，这由 MySQL Server 的 hostname 和 port 系统变量指定。如果 report_port 系统变量指定了另一个端口号，则使用该端口号。
自 MySQL 8.0.21 ，组成员可以将分布式恢复终端的备选列表公布为加入成员的专用客户端连接，从而允许您与成员的常规客户端用户的连接分开控制分布式恢复流量。您可以使用 group_replication_advertise_recovery_endpoints 系统变量指定此列表，成员在加入组时将其分布式恢复终端列表发送到组。默认情况下，成员继续提供早期版本中的标准 SQL 客户端连接。

重点
如果加入成员无法使用 MySQL Server hostname 系统变量定义的主机名正确地标识其他成员，则分布式恢复可能会失败。建议运行 MySQL 的操作系统使用 DNS 或本地设置正确配置唯一主机名。可以在 Performance Schema 的replication_group_members表的 Member_host 列中验证服务器用于 SQL 客户端连接的主机名。如果多个组成员外部化了同一个由操作系统设置的默认主机名，则加入成员可能无法将其解析为正确的成员地址，并且无法连接以进行分布式恢复。在这种情况下，您可以使用 MySQL Server 的 report_host 系统变量来配置要由每个服务器外部化的唯一主机名。

加入成员建立分布式恢复连接的步骤如下：

当成员加入该组时，它将连接到其 group_replication_group_seeds 系统变量中定义的列表中包含的种子成员之一，最初使用该列表中指定的 group_repliation_local_address 连接。种子成员可能是组的子集。
通过此连接，种子成员使用组复制的成员身份服务以视图的形式向加入成员提供组中在线的所有成员的列表。成员身份信息包括每个成员为分布式恢复提供的分布式恢复端点或标准 SQL 客户端连接的详细信息。
加入成员根据第18.5.4.4节 “分布式恢复的容错” 中所述的行为，从该列表中选择一个合适的组成员作为分布式恢复的供体。
然后，加入成员尝试使用供体公布的分布式恢复端点连接到供体，并按列表中指定的顺序依次尝试每个端点。如果供体没有提供端点，则加入成员将尝试使用供体的标准 SQL 客户端连接进行连接。连接的 SSL 要求由第18.5.4.4节 “分布式恢复的 SSL 和身份验证” 中描述的 group_replication_recovery_ssl_* 选项指定。
如果加入成员无法连接到所选的供体，它将按照第18.5.4.4节“分布式恢复的容错” 中描述的行为使用其他合适的供体重试。请注意，如果加入成员在未建立连接的情况下耗尽了供体公布端点的列表，则它不会转而使用供体的标准 SQL 客户端连接，而是切换到另一个供体。
当加入成员与供体建立分布式恢复连接时，其使用该连接进行状态传输。所使用的连接的主机和端口显示在加入成员的日志中。请注意，如果使用远程克隆操作，当加入成员在操作结束时重新启动时，它将与新的供体建立连接，以便使用二进制日志进行状态传输。这可能是与用于远程克隆操作的原始供体不同的成员的连接，也可能是与原始供体的不同连接。无论如何，分布式恢复过程将以与原始供体相同的方式继续进行。

18.5.4.1.1 为分布式恢复端点选择地址

group_replication_advertise_recovery_endpoints 系统变量作为分布式恢复端点提供的 IP 地址不必由 MySQL Server 配置（也就是说，它们不必由 admin_address 系统变量或 bind_address 变量列表中指定）。必须将它们分配给服务器。使用的任何主机名都必须解析为本地 IP 地址。可以使用 IPv4 和 IPv6 地址。

为分布式恢复端点提供的端口必须为 MySQL Server 配置，因此必须由 port 、report_port 或 admin_port 系统变量指定。服务器必须侦听这些端口上的 TCP/IP 连接。如果指定 admin_port ，则分布式恢复的复制用户需要SERVICE_CONNECTION_ADMIN权限才能连接。选择 admin_port 将 分布式恢复连接 与 常规 MySQL 客户端连接 分开。

连接成员按列表中指定的顺序依次尝试每个端点。如果 group_replication_advertise_recovery_endpoints 设置为DEFAULT而不是端点列表，则提供 标准的 SQL 客户端连接 。请注意，标准 SQL 客户端连接 不会自动包含在分布式恢复端点列表中，如果供体的端点列表直到耗尽也没能产生一个连接，则不会作为备用。如果要将标准 SQL 客户端连接作为多个分布式恢复端点之一提供，则必须将其明确包含在 group_replication_advertise_recovery_endpoints 指定的列表中。你可以把它放在最后一个位置，这样它就可以作为连接的最后手段。

组成员的分布式恢复端点（或标准 SQL 客户端连接，如果未提供端点）不需要添加到 group_replication_ip_allowlist（MySQL 8.0.22 以后）或 group_repliation_ip_whitelist 系统变量指定的组复制允许列表中。允许列表仅适用于 group_replication_local_address 为每个成员指定的地址。加入成员与组的初始连接必须获得允许列表的允许，来检索用于分布式恢复的一个或多个地址。

设置系统变量并发出START GROUP_REPLICATION语句后，将验证您列出的分布式恢复端点。如果无法正确解析列表，或者由于服务器未侦听任何端点而无法在主机上访问这些端点，则组复制会记录错误，并且不会启动。

18.5.4.1.2 分布式恢复的压缩

从 MySQL 8.0.18 中，您可以选择通过 供体二进制日志状态传输 的方法，为分布式恢复配置压缩。压缩可以有利于分布式恢复，因为网络带宽有限，并且供体必须将许多事务传输到加入成员。
group_replication_recovery_compression_algorithms 和 group_repliation_recovery_zstd_compression_level 系统变量配置允许的压缩算法和 zstd 压缩级别，用于 供体二进制日志状态传输 。有关详细信息，请参阅第4.2.8节“连接压缩控制”。

请注意，这些压缩设置不适用于远程克隆操作。当远程克隆操作用于分布式恢复时，克隆插件的 clone_enable_compression 设置更适用。

18.5.4.1.3 用于分布式恢复的复制用户

分布式恢复需要具有正确权限的复制用户，以便组复制可以建立直接的成员间（member-to-member）的复制通道。复制用户还必须具有正确的权限，才能作为远程克隆操作的供体上的克隆用户。必须在每个组成员上使用相同的复制用户进行分布式恢复。有关设置此复制用户的说明，请参阅第18.2.1.3节 “分布式恢复的用户证书” 。有关保护复制用户证书的说明，请参阅第18.6.3.1节 “分布式恢复的安全用户证书” 。

18.5.4.1.4 分布式恢复的 SSL 和身份验证

分布式恢复的 SSL 与正常组通信的 SSL 是分开配置的，这取决于服务器的 SSL 设置和 group_replication_ssl_mode 系统变量。对于分布式恢复连接，专用的组复制分布式恢复 SSL 系统变量可用于配置证书和密码的使用，特别是用于分布式恢复。

默认情况下，SSL 不用于分布式恢复连接。要激活它，请将 group_replication_recovery_use_ssl=ON，并按照第18.6.3节 “保护分布式恢复连接的安全” 中的说明配置组复制分布式恢复 SSL 系统变量。您需要一个被设置为 使用 SSL 的复制用户。

当分布式恢复配置为 使用 SSL时，组复制将此设置应用于 远程克隆操作 ，以及 供体二进制日志状态传输 。组复制会自动配置克隆 SSL 选项（clone_ssl_ca ，clone_ssl_cert 和 clone_ssl_key ）的设置，以匹配相应组复制分布式恢复选项（group_replication_recovery_ssl_ca ，group_replication_recovery_ssl_cert 和group_replication_recovery_ssl_key）的设定。

如果您没有使用 SSL 进行分布式恢复（因此 group_replication_recovery_use_ssl 设置为OFF），并且组复制的复制用户帐户使用 caching_sha2_password 插件（这是 MySQL 8.0 中的默认插件）或 **sha256_password ** 插件进行身份验证，则将使用 RSA 密钥对 进行密码交换。在这种情况下，要么使用 group_replication_recovery_public_key_path 系统变量指定 RSA 公钥文件，要么使用 group_replication_recovery_get_public_key 系统变量从源请求公钥，如第18.6.3.1.1节 “使用缓存的 SHA-2 身份验证插件的复制用户” 所述。

18.5.4.2 分布式恢复的克隆

MySQL 8.0.17 提供了 MySQL Server 的克隆插件。如果要在组中使用 远程克隆操作 进行分布式恢复，必须事先设置现有成员和加入成员以支持此功能。如果您不想在组中使用此功能，请不要设置它，在这种情况下，组复制仅使用 （供体）二进制日志状态传输。

要使用克隆，必须事先设置至少一个现有组成员和加入成员以支持 远程克隆操作 。至少，必须在供体和加入成员上安装克隆插件，向复制用户授予BACKUP_ADMIN权限以进行分布式恢复，并将 group_replication_clone_threshold 系统变量设置为适当的级别。为了确保供体的最大可用性，最好设置所有当前和未来的组成员用于支持远程克隆操作。

请注意，在从供体传输数据之前， 远程克隆操作 会从加入成员中删除用户创建的表空间和数据。如果操作在进行过程中停止，则加入成员可能会残留部分数据或无数据残留。组复制会自动执行重试 远程克隆操作 来修复此问题。

18.5.4.2.1 克隆的先决条件

有关设置和配置克隆插件的完整说明，请参阅第5.6.7节 “克隆插件” 。第5.6.7.3节 “克隆远程数据” 中介绍了 远程克隆操作 的详细先决条件。对于组复制，请注意以下要点和区别：

供体（现有组成员）和受体（加入成员）必须安装并激活克隆插件。有关执行此操作的说明，请参阅第5.6.7.1节“安装克隆插件” 。
供体和受体必须在相同的操作系统上运行，并且必须具有相同的MySQL Server 版本（必须是支持克隆插件的 MySQL 8.0.17 或更高版本）。因此，克隆不适合成员运行不同 MySQL Server 版本的组。
供体和受体必须安装组复制插件并处于活动状态，并且供体上活动的任何其他插件（如 keyring 插件）也必须在受体上处于活动状态。
如果分布式恢复配置为使用 SSL（group_replication_recovery_use_ssl=ON），则组复制将此设置应用于远程克隆操作。组复制会自动配置克隆 SSL 选项（clone_ssl_ca 、 clone_ssl_cert 和 clone_ssl_key）的设置，以匹配相应组复制分布式恢复选项（group_replication_recovery_ssl_ca、group_replication_recovery_ssl_cert和group_replication_recovery_ssl_key）的设定。
为了加入复制组，不需要在 clone_valid_donor_list 系统变量中设置有效供体的列表。组复制在从现有组成员中选择供体后自动为您配置此设置。请注意，远程克隆操作使用服务器的 SQL 协议主机名和端口。
克隆插件有许多管理远程克隆操作的网络负载和性能影响的系统变量。组复制不配置这些设置，因此您可以查看它们并根据需要进行设置，或者允许它们默认设置。请注意，当远程克隆操作用于分布式恢复时，克隆插件的 clone_enable_compression 设置将应用于该操作，而不是组复制压缩设置。
要在受体上调用远程克隆操作，组复制使用内部mysql.session用户，该用户已经具有CLONE_ADMIN权限，因此不需要设置此权限。
作为远程克隆操作的供体上的克隆用户，组复制使用您为分布式恢复设置的复制用户（这在第18.2.1.3节 “分布式恢复的用户证书” 中介绍）。因此，您必须在所有支持克隆的组成员上向该复制用户授予BACKUP_ADMIN权限。当您为组复制配置成员时，还可以为加入成员上的复制用户授权，以使他们可以在加入组后充当供体。每个组成员上的分布式恢复使用相同的复制用户。要将此权限授予现有成员上的复制用户，可以在禁用二进制日志记录的情况下对每个组成员单独执行此语句，或者在启用二进制日志记录时对一个组成员发出此语句：
```
GRANT BACKUP_ADMIN ON *.* TO rpl_user@'%';
```
如果在以前使用CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO提供用户证书的服务器上，使用START GROUP_REPLICATION指定复制用户证书，请确保在执行任何远程克隆操作之前从复制元数据存储库中删除用户证书。还要确保在加入成员上设置了group_replication_start_on_boot=OFF。有关说明，请参阅 [第18.6.3节 “保护分布式恢复连接的安全”]。如果不取消设置用户证书，则在远程克隆操作期间，这些证书将传输给加入成员。然后，可能会在原始成员或从中克隆的成员上无意中使用存储的证书启动 group_replication_recovery通道。在服务器启动时（包括远程克隆操作之后）自动启动的组复制将使用存储的用户证书，如果操作员未在START GROUP_REPLICATION上指定分布式恢复证书，也将使用这些证书。

18.5.4.2.2 克隆的阈值

当组成员已设置为支持克隆时，group_replication_clone_threshold 系统变量将指定一个阈值，以事务数表示，用于在分布式恢复中使用远程克隆操作。如果供体的事务和加入成员的事务之间的间隔（gap）大于此数字，则在技术上可行的情况下，使用远程克隆操作将状态传输到加入成员。组复制根据现有组成员的gtid_executed集合计算是否已超过阈值。在出现大的事务间隔时使用远程克隆操作，可以向组中添加新成员，而无需事先手动将组的数据传输到服务器，而且还可以使非常过时的成员追赶更高效。

组复制系统变量 group_replication_clone_threshold 的默认设置非常高（GTID 中事务允许的最大序列号），因此它可以在任何允许使用 二进制日志状态传输 的地方有效地禁用克隆。要使组复制能够在更合适的情况下为状态传输选择远程克隆操作 ，请设置系统变量，将事务数指定为要进行克隆的事务间隔。

警告
在活动组中的 group_replication_clone_threshold 不要使用低设置。如果在进行远程克隆操作期间，组中发生的事务数超过阈值，则加入成员将在重新启动后再次触发远程克隆操作，并且可以无限地继续此操作。要避免这种情况，请确保将阈值设置为高于远程克隆操作所需时间内组中预期发生的事务数。

当无法使用 供体二进制日志状态传输 时，组复制会尝试执行 远程克隆操作 ，而不考虑您的阈值，例如，因为加入成员所需的事务在任何现有组成员的二进制日志中都不可用。组复制基于现有组成员的gtid_purged集合来标识它。当所需事务在任何成员的二进制日志文件中都不可用时，不能使用 group_replication_clone_threshold 系统变量来停用克隆，因为在这种情况下，克隆是手动将数据传输到加入成员的唯一选择。

18.5.4.2.3 克隆操作

当为克隆设置组成员和加入成员时，组复制将为您管理远程克隆操作。远程克隆操作可能需要一些时间才能完成，具体取决于数据的大小。有关监控过程的信息，请参见第5.6.7.10节 “监控克隆操作”。

说明
状态传输完成后，组复制将重新启动加入成员以完成该过程。如果在加入成员上设置了group_replication_start_on_boot=OFF，例如，因为在START GROUP_REPLICATION语句中指定了复制用户证书，则必须在重新启动后再次手动执行START GROUP_REPLICATION。如果group_replication_start_on_boot=ON，并且在配置文件中或使用SET PERSIST语句设置了启动组复制所需的其他设置，则无需干预，过程将自动继续以使加入成员联机。

如果远程克隆过程需要很长时间，在 MySQL 8.0.22 之前的版本中，在这段时间内为组累积的认证信息集合可能会变得太大，无法传输给加入成员。在这种情况下，加入成员会记录一条错误消息，并且不会加入组。从 MySQL 8.0.22 开始，组复制以不同的方式管理已应用事务的垃圾收集过程，以避免这种情况。在早期版本中，如果确实看到此错误，则在远程克隆操作完成后，请等待两分钟，以便进行一轮垃圾收集，以减少组的认证信息的大小。然后对加入成员执行以下语句，使其停止尝试应用之前的认证信息集合：

RESET SLAVE FOR CHANNEL group_replication_recovery;
#或 MySQL 8.0.22 以后：
RESET REPLICA FOR CHANNEL group_replication_recovery;

远程克隆操作克隆表中从供体到受体已持久化的设置以及数据。组复制管理组复制通道的专属设置。保留在配置文件中的组复制成员设置（如组复制本地地址）不会被克隆，也不会在加入成员上更改。组复制还保留与 SSL 使用相关的通道设置，因此这些设置对于单个成员是唯一的。

如果供体为group_replication_recovery复制通道使用的复制用户证书已使用CHANGE REPLICATION SOURCE TO | CHANGE MASTER TO 语句存储在复制元数据存储库中，则在克隆后，它们将被传输到加入成员并被其使用，并且必须在加入成员上有效。使用存储的证书，所有通过远程克隆操作接收状态传输的组成员都会自动接收复制用户和密码，以进行分布式恢复。如果在START GROUP_REPLICATION语句中指定了复制用户证书，则这些证书将用于启动远程克隆操作，但在克隆后不会传输到加入成员并由其使用。如果您不希望将证书传输到新的加入者并记录在那里，请确保在执行远程克隆操作之前取消设置证书，如第18.6.3节 “保护分布式恢复连接的安全” 所述，并使用START GROUP_REPLICATION提供证书。

如果一个PRIVILEGE_CHECKS_USER帐户已用于帮助保护 MySQL 8.0.19 中的复制应用器（请参阅第17.3.3.2节 “组复制通道的权限检查”），则该PRIVILEEGE_CHECKS_USER帐户和供体的相关设置将克隆到加入成员。如果加入成员设置为在启动时启动组复制，它将自动使用该帐户在相应的复制通道上进行权限检查。（在 MySQL 8.0.18 中，由于一些限制，建议不要将PRIVILEGE_CHECKS_USER帐户用于组复制通道。）

18.5.4.2.4 克隆的其他用途

组复制启动并管理分布式恢复的克隆操作。已设置为支持克隆的组成员也可以参与用户手动启动的克隆操作。例如，您可能希望通过克隆作为供体的组成员来创建一个新的服务器实例，但不希望新服务器实例立即或永远加入组。

在所有支持克隆的版本中，您可以手动启动克隆操作，该操作涉及已停止组复制的组成员。请注意，因为克隆要求供体和受体上的活动插件必须匹配，所以即使您不希望该服务器实例加入组，也必须在其他服务器实例上安装并激活组复制插件。您可以通过执行以下语句来安装插件：

INSTALL PLUGIN group_replication SONAME 'group_replication.so';

在 MySQL 8.0.20 之前的版本中，如果克隆操作涉及正在运行组复制的组成员，则无法手动启动克隆操作。在 MySQL 8.0.20 以后，允许您这样做，但前提是克隆操作不会删除和替换受体的数据。因此，如果组复制正在运行，则启动克隆操作的语句必须包含DATA DIRECTORY子句。

18.5.4.3配置分布式恢复

以下是可以根据您的系统配置组复制的分布式恢复过程的几个方面。

连接尝试次数

对于 二进制日志状态传输 ，组复制限制了加入成员在尝试连接到供体池中的供体时的尝试次数。如果在未成功连接的情况下达到连接重试限制，则分布式恢复过程将终止，并显示错误。请注意，此限制指定了加入成员连接到供体的尝试总数。例如，如果 2 个组成员是合适的供体，并且连接重试限制被设置为 4 ，则加入成员在达到限制之前进行 2 次尝试连接到每个供体。

默认连接重试限制为 10 。可以使用 group_replication_recovery_retry_count 系统变量配置此设置。以下命令将连接到供体的最大尝试次数设置为 5 ：

mysql> SET GLOBAL group_replication_recovery_retry_count= 5;

对于 远程克隆操作 ，此限制不适用。在开始尝试 二进制日志状态传输 之前，组复制仅对每个适合的克隆供体进行一次连接尝试。

连接尝试的睡眠时间间隔

对于 二进制日志状态传输 ，group_replication_recovery_reconnect_interval 系统变量定义分布式恢复进程在供体连接尝试之间应该休眠多长时间。请注意，分布式恢复不会在每次供体连接尝试后休眠。由于加入成员正在连接到不同的服务器，而不是重复连接到同一个服务器，因此可以假设影响服务器 A 的问题不会影响服务器 B 。因此，分布式恢复只有在遍历所有可能的供体后才会挂起。一旦加入组的服务器尝试连接到组中的每一个合适的供体，分布式恢复过程将休眠由 group_replication_recovery_reconnect_interval 系统变量配置的秒数。例如，如果 2 个组成员是合适的供体，并且连接重试限制被设置为 4 ，则加入成员尝试连接到每个供体，然后休眠连接重试间隔，然后在达到限制之前再尝试连接到各个供体。

默认连接重试间隔为 60 秒，您可以动态更改此值。以下命令将分布式恢复供体连接重试间隔设置为 120 秒：

mysql> SET GLOBAL group_replication_recovery_reconnect_interval= 120;

对于 远程克隆操作 ，此间隔不适用。在开始尝试 二进制日志状态传输 之前，组复制仅对每个适合的克隆供体进行一次连接尝试。

在线标记加入成员

当分布式恢复成功完成从供体到加入成员的状态传输时，加入成员可以在组中被标记为在线并准备好加入。默认情况下，这是在加入成员接收并应用了所有缺少的事务之后完成的。或者，您可以允许加入成员在收到并验证（即，完成冲突检测）所有缺失的事务之后，但在应用这些事务之前，将其标记为在线。如果要执行此操作，请使用 group_replication_recovery_complete_at 系统变量指定TRANSACTIONS_CERTIFIED可选设置。

18.5.4.4 分布式恢复的容错

组复制的分布式恢复过程具有许多内置措施，以确保在过程中出现任何问题时的容错性。

分布式恢复的供体是从当前视图中合适的在线组成员的现有列表中随机选择的。选择一个随机供体意味着当多个成员进入组时，很有可能不会多次选择同一服务器。在 MySQL 8.0.17 以后，对于 二进制日志状态传输 ，加入成员只选择运行较低或等同于自身的 MySQL Server 补丁版本的供体。对于早期版本，所有在线成员都可以成为供体。对于 远程克隆操作，连接程序只选择运行与其自身相同修补程序版本的供体。请注意，当加入成员在远程克隆操作结束时重新启动时，它将从二进制日志中建立与新供体的连接以进行状态传输，该供体可能与用于远程克隆操作的原始供体不同。

在以下情况下，组复制会检测到分布式恢复中的错误，自动切换到新的供体，并重试状态传输：

连接错误 ——与候选供体连接时存在身份验证问题或其他问题。
复制错误 ——用于二进制日志状态传输的一个复制线程（接收器或应用器线程）失败。由于这种状态传输方法使用现有的 MySQL 复制框架，因此一些暂时错误可能会导致接收器或应用器线程出错。
远程克隆操作错误 ——远程克隆操作失败或在完成之前停止。
施主离开组 ——供体离开组，或供体上的组复制停止，而此时状态传输正在进行。

PERFORMANCE_SCHEMA.replication_applier_status_by_worker表显示导致上次重试的错误。在这些情况下，将尝试使用新的候选供体进行错误后的新连接。在出现错误的情况下选择不同的供体意味着新的候选供体可能没有相同的错误。如果安装了克隆插件，组复制将首先尝试与每个合适的支持在线克隆的供体进行远程克隆操作。如果所有这些尝试都失败，则组复制将尝试使用二进制日志依次与所有合适的供体进行状态传输（如果可能的话）。

警告
对于 远程克隆操作 ，在远程克隆操作开始从供体传输数据之前，将删除用户创建的表空间和受体（加入成员）的数据。如果远程克隆操作开始但未完成，则加入成员可能只剩下一部分原始数据文件，或者没有用户数据。如果在完全克隆数据之前停止克隆操作，则供体传输的数据将从受体删除。可以通过重试克隆操作来修复这种情况，组复制会自动执行克隆操作。

在以下情况下，分布式恢复过程无法完成，加入成员将离开组：

清除的事务——加入成员所需的事务不存在于任何在线组成员的二进制日志文件中，并且无法通过远程克隆操作获取数据（因为未安装克隆插件，或者因为尝试与所有可能的供体进行克隆但失败）。因此，加入成员无法赶上组。
额外事务——加入成员已包含组中不存在的某些事务。如果执行了远程克隆操作，这些事务将被删除并丢失，因为加入成员上的数据目录将被删除。如果使用供体二进制日志进行状态传输，这些事务可能会与该组的事务发生冲突。有关处理这种情况的建议，请参阅额外事务。
已达到连接重试限制——加入成员已进行了连接重试限制所允许的所有连接尝试。您可以使用 group_replication_recovery_retry_count 系统变量对此进行配置（请参阅第 18.5.4.3 节 “配置分布式恢复”）。
没有更多的供体——加入成员依次尝试与每个支持克隆的在线供体进行远程克隆操作失败（如果安装了克隆插件），然后在可能的情况下，依次尝试使用每个合适的在线供体进行二进制日志状态传输失败。
加入成员离开组——加入成员离开了组，或者在状态传输过程中停止了加入成员的组复制。

如果加入成员无意中离开了组，那么在上面列出的任何情况下（最后一种情况除外），它将继续执行 group_replication_exit_state_action 系统变量指定的操作。

18.5.4.5 分布式恢复的工作原理

当组复制的分布式恢复过程执行二进制日志状态传输时，为了将加入成员与供体同步到特定时间点，加入成员和供体使用 GTID（请参阅第17.1.3节 “使用全局事务标识符的复制”）。然而，GTID 仅提供了一种方法来了解加入成员缺少哪些事务。它们不会帮助标记加入组的服务器必须赶上的特定时间点，也不会传递认证信息。这是 二进制日志视图标记（Binary Log View Marker） 的工作，它标记二进制日志流中的视图更改，还包含其他元数据信息，为加入成员提供缺失的认证相关数据。

本主题介绍了视图更改和视图更改标识符的作用，以及使用二进制日志执行状态传输的步骤。

视图和视图更改

视图对应于在当前配置下（换句话说，在特定的时间点）一组积极参与的成员。它们在组中正常运行并在线。

当修改组配置（例如成员加入或离开）时，会发生视图更改。任何组成员身份更改都会导致在同一逻辑时间点向所有成员传达独立的视图更改。

视图标识符唯一标识视图。每当视图发生更改时，都会生成它。

在组通信层，视图更改及其关联的视图标识符标记成员加入之前和之后交换的数据之间的边界。这个概念是通过二进制日志事件实现的：“视图更改日志事件”（VCLE）。它记录了视图标识符以区分在组成员身份发生变化之前和之后传输的事务。

视图标识符本身由两部分组成：随机生成的部分和单调递增的整数。随机生成的部分在创建组时生成，并且在组中至少有一个成员时保持不变。每次发生视图更改时，整数部分都会递增。使用这两个不同的部分，视图标识符可以识别由于成员加入或离开而导致的新增组更改。视图标识符还可以识别在完全关闭组时所有成员离开组的情况，因此在这种情况下不会保留组所处的视图信息。最初启动组时随机生成部分标识符确保二进制日志中的数据标记保持唯一，并且在完全关闭组后不会重复使用相同的标识符，否则这将导致将来分布式恢复出现问题。

开始：稳定组

所有服务器都处于联机状态，并处理来自组的传入事务。有些服务器在复制的事务方面可能稍有落后，但最终它们会趋同。该组表现为一个分布式的、复制的数据库。

图 18.8 稳定组

视图更改：加入成员

每当新成员加入组并随即执行视图更改时，每个在线服务器都会将视图更改日志事件排队等待执行。这是排队的，因为在视图更改之前，在要应用的服务器上可能存在已排队的事务，因此这些事务属于旧视图。在视图更改事件之后对其进行排队可确保正确标记发生此事件的时间。

同时，加入成员通过视图抽象从成员服务声明的在线服务器列表中选择合适的供体。一个成员加入视图 4 ，在线成员将视图更改事件写入二进制日志。

图 18.9 加入一个成员

状态传输：补齐

如果使用克隆插件设置了组成员和加入成员（请参阅第 18.5.4.2 节 “分布式恢复的克隆” ），并且加入成员和组之间的事务间隔超过了为 远程克隆操作 设置的阈值（group_replication_clone_threshold），则组复制将通过远程克隆操作开始分布式恢复。如果任何组成员的二进制日志文件中不再存在所需的事务，也会执行远程克隆操作。在远程克隆操作期间，将删除加入成员上的现有数据，并替换为供体数据的副本。当远程克隆操作完成且加入成员已重新启动时，将执行来自供体二进制日志的状态传输，以获取远程克隆操作进行时组应用的事务。如果没有大的事务间隙，或者没有安装克隆插件，则组复制将直接执行供体二进制日志状态传输。

对于 供体二进制日志状态传输 ，在加入成员和供体之间建立连接，状态传输开始。与供体的这种交互一直持续到加入组的服务器的应用器线程，处理完与加入组的服务器进入组时触发的视图更改相对应的视图更改日志事件。换言之，加入组的服务器从供体复制，直到它到达具有与它已经所在的视图标记匹配的视图标识符的标记。

译者
加入成员在加入时产生视图更改事件，进而生成一个新的全组可见且唯一的视图标识符 ID_1 ，并在供体的二进制日志上做一个标记（Marker）marker_a ，然后加入成员开始进行从供体的复制工作，直到它自身的二进制日志应用到 marker_a 标记的位置。

图 18.10 状态传输：补齐

由于视图标识符在同一逻辑时间传输到组中的所有成员，因此加入组的服务器知道应该在哪个视图标识符处停止复制。这避免了复杂的 GTID 集计算，因为视图标识符清楚地标记了哪些数据属于哪个组视图。

当加入组的服务器正在从供体复制时，它也在缓存来自组的传入事务。最终，它停止从供体复制，并转而应用缓存的那些事务。

图 18.11 排队的事务

结束：补齐完成

当加入组的服务器识别到具有预期视图标识符的视图更改日志事件时，将终止与供体的连接，并开始应用缓存的事务。虽然它在二进制日志中充当区分视图更改的标记，但视图更改日志事件也起着另一个作用。当加入组的服务器进入组时，即最后一次视图更改时，它传递所有服务器所感知的认证信息。如果没有它，加入该组的服务器将没有必要的信息来验证（检测冲突）后续事务。

追赶的持续时间是不确定的，因为它取决于工作负载和组中传入事务的速率。此过程完全在线，加入组的服务器在追赶时不会阻塞组中的任何其他服务器。因此，加入组的服务器在更改到此阶段时所落后的事务数量可能会有所不同，因此会根据工作负载而增加或减少。

当加入组的服务器达到零排队事务且其存储的数据与其他成员相等时，其公共状态将被更改为联机（在线）。

图 18.12 实例上线（变为在线）