共计 13115 个字符，预计需要花费 33 分钟才能阅读完成。
1. 概述：
每当一个 MySQLserver 新退出或者重新加入一个 MGR 集群时，它都必须追平集群内相差的事务，保障这个节点的数据和集群内最新的数据是同步的。这个新退出集群的节点在追平集群中的数据或者重新加入集群的节点追评它脱离集群后到当初这段时间内相差的事务数据的过程称为分布式复原。
申请加入集群的节点首先查看 groupreplicationapplier 通道中的中继日志，查看该节点目前尚未从集群中同步过去的事务数据。如果是重新加入集群的节点，则该节点会找到在来到集群后到当初和集群最新数据中未回放的事务数据，在这种状况下，该节点首先会利用这些未同步的事务。对于新退出集群的节点，间接从一个疏导节点上进行全量数据恢复即可。
尔后，新退出的节点和集群中现有的 online 状态的节点（疏导节点）建设连贯进行状态转移。新退出的节点从集群中的疏导节点中同步退出集群之前或者来到集群后到当初未同步过去的数据，这些相差的事务由集群中的疏导节点提供。接下来，新退出的节点利用从集群中的疏导节点同步过去的未进行利用的事务。此时申请加入集群的节点将利用在状态传输过程中集群内新事务写入的数据。（此时集群内新事物写入的数据临时寄存在缓存队列中，并未将数据写入磁盘中）实现此过程后，新退出的节点的数据和整个集群的数据相比，处于一个追平的状态，并且该节点设置为 online 状态。
留神：新退出集群的节点，不论是之前有没有在此集群中，都会先随机选一个 online 节点先同步该节点和集群相差的事务。
组复制在分布式复原期间用下述办法实现状态传输：
应用克隆插件的性能进行近程克隆操作，该插件可从 MySQL 8.0.17 开始反对。要应用这种办法，必须在疏导节点和新退出的节点上提前装置克隆插件。组复制会主动配置所需的克隆插件设置，并治理近程克隆操作。
从疏导节点的二进制日志复制数据并在新退出的节点上利用这些事务。此办法须要在疏导节点和退出节点之间建设的名为 groupreplicationrecovery 的规范异步复制通道。
在退出节点上执行 STARTGROUP_REPLICATION 后，组复制会主动抉择上述办法的最佳组合进行状态转移。为此，组复制将会查看集群中哪些现有节点适宜用作疏导节点，退出节点须要疏导节点传输多少事务，以及是否有事务不再存在于集群中任意节点的二进制日志文件中。如果退出节点与疏导节点之间的事务差距很大，或者如果某些要求的事务不在疏导节点的二进制日志文件中，则组复制将通过近程克隆操作开始分布式复原。如果没有较大的事务间隙，或者未装置克隆插件，则组复制将间接从疏导节点的二进制日志进行状态转移。
在近程克隆操作期间，将删除退出节点上的现有数据，并用疏导节点数据的正本替换。当近程克隆操作实现并且新退出节点已重新启动时，将继续执行来自疏导节点二进制日志来进行状态转移，以获取在进行近程克隆操作时集群所写入的增量数据。
在从疏导节点的二进制日志进行状态转移期间，新退出节点从疏导节点的二进制日志中复制并利用所需的事务，并在收到事务时利用事务，直到二进制日志记录新退出节点退出了集群。（当退出节点胜利退出集群时，二进制日志中会记录对应的视图更改 event）在此过程中，退出节点将缓冲该集群利用的新事务数据。从二进制日志的状态传输实现后，新退出节点将利用缓冲的事务。
当退出节点与该集群的所有事务放弃最新时，该节点将在设置为 online 状态并能够作为一般节点退出集群，并且分布式复原已实现。
ps：从二进制日志进行状态转移是组复制进行分布式复原的根本机制，并且如果未将复制组中的疏导节点和退出节点设置为反对克隆。因为从二进制日志进行状态转移是基于经典的异步复制，因而，如果退出该集群的 MySQL server 基本没有该集群的数据，或者从十分旧的备份中获取了数据，则可能要花费很长时间来复原最新数据。因而，在这种状况下，倡议在将 MySQL server 增加到集群之前，则应通过传输集群中已有节点的相当近期的快照来应用集群的数据对其进行设置。这能够最大水平地缩小分布式复原所需的工夫，并缩小对疏导节点的影响，因为疏导节点必须保留和传输较少的二进制日志文件。
2. 分布式复原的连贯：
当退出节点连贯到现有节点中的疏导节点进行分布式复原期间的状态转移时，退出节点充当客户端，而疏导节点充当服务端。当通过此连贯（应用异步复制通道 groupreplicationrecovery）从疏导节点的二进制日志进行状态转移时，退出节点充当正本，疏导节点充当源端。通过此连贯进行近程克隆操作时，新退出节点充当全量数据接收者，疏导节点充当全量数据提供者。利用于组复制上下文之外的角色的配置设置也能够利用于组复制，除非它们被特定于组复制的配置设置或行为所笼罩。
现有节点提供给新退出节点以进行分布式复原的连贯与组复制用于集群内节点之间的通信的连贯是不同的。
组通信引擎用于组复制（XCom，Paxos 变体），用于近程 XCom 实例之间的 TCP 通信的连贯由 groupreplicationlocal_address 零碎变量指定。此连贯用于集群内 online 节点之间的 TCP / IP 消息传递。与本地实例的通信是通过应用内存内共享的传输通道进行的。
对于分布式复原，直到 MySQL8.0.20 为止，集群内的节点都将其规范 SQL 客户端连贯提供给退出节点，这由 MySQL Server 的主机名和端口零碎变量指定。如果 report_port 零碎变量指定了备用端口号，则改用该端口号。
从 MySQL 8.0.21 开始，组成员能够将分布式复原端点的代替列表作为加入成员的专用客户端连贯，从而使得独立于成员的惯例客户端用户的连贯能够用来管制分布式复原。能够应用 groupreplicationadvertiserecoveryendpoints 零碎变量来指定此列表，并且成员在退出组时将其分布式复原端点的列表传输到该组。默认值为成员持续提供与晚期版本雷同的规范 SQL 客户端连贯。
PS：
如果退出节点无奈应用 MySQLServer 的零碎变量定义的主机名正确辨认其余节点，则分布式复原可能会失败。倡议运行 MySQL 的操作系统应用 DNS 或本地设置具备正确配置的惟一主机名。能够在“performanceschema”库下的 Replicationgroupmembers 表的 Memberhost 列中验证 server 用于 SQL 客户端连贯的主机名。如果多个组成员将操作系统设置的默认主机名内部化，则退出节点有可能无奈将其解析为正确的地址，并且无奈连贯以进行分布式复原。在这种状况下，能够应用 MySQL Server 的 report_host 零碎变量来配置由每个 server 内部化的惟一主机名。
退出节点为分布式复原建设连贯的步骤如下：
当节点退出集群时，它会应用 groupreplicationgroupseeds 零碎变量中列表中蕴含的一个种子节点进行连贯，最后应用该列表中指定的 groupreplicationlocaladdress 连贯。种子节点可能是集群数据的子集。
通过此连贯，种子节点应用组复制的成员资格服务以视图的模式向退出的节点提供集群中所有 online 节点的列表。成员资格信息包含每个成员为分布式复原提供的分布式复原端点或规范 SQL 客户端连贯的详细信息。
退出节点从此列表中抉择适合的 online 节点作为其疏导节点进行分布式复原
退出节点尝试应用疏导节点的分布式复原端点来连贯到疏导节点，并按列表中指定的程序顺次尝试连贯每个端点。如果疏导节点没有提供端点，则退出节点将尝试应用疏导节点的规范 SQL 客户端连贯进行连贯。连贯的 SSL 要求由 groupreplicationrecoveryssl * 选项指定。
如果退出节点无奈连贯到指定的疏导节点，则它将与其余适合的疏导节点重试连贯。如果退出节点在没有建设连贯的状况下耗尽了端点的播送列表，则它不会回退到疏导节点的规范 SQL 客户端连贯，而是切换到另一个疏导节点尝试从新建设连贯。
退出节点与疏导节点建设分布式复原连贯时，它将应用该连贯进行状态转移，退出节点的日志中显示了所应用的连贯的主机和端口。如果应用近程克隆操作，则在操作完结时重新启动退出节点时，它将与新的疏导节点建设连贯，从疏导节点的二进制日志进行状态转移。这可能是与用于近程克隆操作的疏导节点不同的连贯，也可能是与疏导节点建设雷同的连贯。无论如何，分布式复原将以雷同的形式与疏导节点建设连贯。
2.1 分布式复原端地址的查找：
groupreplicationadvertiserecoveryendpoints 零碎变量作为分布式复原端提供的 IP 地址，不用为 MySQL Server 配置（也就是说，不用由 adminaddress 零碎变量或在 bindaddress 零碎变量的列表中指定）。
为 MySQL Server 配置为分布式复原端提供的端口，必须由 port，reportport 或 adminport 零碎变量指定。必须在这些端口上侦听 TCP / IP 连贯。如果指定 adminport，则用于分布式复原的复制用户须要 SERVICECONNECTIONADMIN 权限能力连贯。抉择 adminport 可使分布式复原连贯与惯例 MySQL 客户端连贯离开。
退出节点按列表中指定的程序顺次尝试每个端点。如果将 groupreplicationadvertiserecoveryendpoints 设置为 DEFAULT 而不是端点列表，则将提供规范 SQL 客户端连贯。规范 SQL 客户端连贯不会主动蕴含在分布式复原端点列表中，并且如果疏导节点的端点列表在没有连贯的状况下被用尽，则不会将其作为备用。如果要提供规范 SQL 客户端连贯作为多个分布式复原端点之一，则必须将其显式包含在 groupreplicationadvertiseadvertiserecovery_endpoints 指定的列表中。能够将其放在最初，以便作为连贯的最初伎俩。
无需将组成员的分布式复原起点（或规范 SQL 客户端连贯，如果未提供起点）增加到 groupreplicationipallowlist（来自 MySQL 8.0.22）或 groupreplicationipwhitelist 零碎变量指定的组复制容许列表中。许可列表仅实用于由 groupreplicationlocal_address 为每个节点指定的地址。退出节点必须具备与容许列表容许的集群的初始连贯，以便检索一个或多个地址进行分布式复原。
设置零碎变量和执行 STARTGROUP_REPLICATION 语句后，将验证列出的分布式复原端点。如果无奈正确解析列表，或者因为服务未在侦听列表而无奈在主机上拜访任何端点，则组复制将记录谬误并且无奈启动。
2.2 分布式复原压缩
在 MySQL 8.0.18 中，能够抉择应用疏导节点二进制日志中的状态转移办法为分布式复原配置压缩。在网络带宽无限的状况下，压缩能够使分布式复原受害，而疏导节点必须将许多事务传输给退出节点。groupreplicationrecoverycompressionalgorithm 和 groupreplicationrecoveryzstdcompression_level 零碎变量配置容许的压缩算法以及 zstd 压缩级别，这些级别用于从疏导节点的二进制日志执行状态转移时应用。
这些压缩设置不适用于近程克隆操作。当近程克隆操作用于分布式复原时，将利用克隆插件的 cloneenablecompression 设置。
2.3 分布式复原的用户
分布式复原须要具备正确权限的复制用户，以便组复制能够建设间接的节点到节点的复制通道。复制用户还必须具备正确的权限，如果该复制用户还同充当近程克隆操作中的克隆用户，则在疏导节点中该复制用户还必须具备近程克隆相干的权限（BACKUP_ADMIN 权限）能力充当疏导节点上的克隆用户以进行近程克隆操作。除此之外，必须将同一复制用户用于集群内每个节点上的分布式复原。
2.4 分布式复原和 SSL 认证
用于分布式复原的 SSL 与用于一般组通信的 SSL 离开配置，这由 server 的 SSL 设置和 groupreplicationssl_mode 零碎变量确定。对于分布式复原连贯，能够应用专用的组复制分布式复原 SSL 零碎变量来配置专门用于分布式复原的证书和密钥的应用。
默认状况下，SSL 不用于分布式复原连贯。设置 groupreplicationrecoveryusessl= ON 启用，而后配置组复制分布式复原 SSL 零碎变量，将复制用户设置为应用 SSL。
将分布式复原配置为应用 SSL 时，组复制会将此设置利用于近程克隆操作以及从疏导节点的二进制日志进行状态转移。组复制会主动配置克隆 SSL 选项（clonesslca，clonesslcert 和 clonesslkey），以匹配相应组复制分布式复原选项（groupreplicationrecoverysslca，groupreplicationrecoverysslcert 和 groupreplicationrecoverysslkey）的设置。
如果未应用 SSL 进行分布式复原（groupreplicationrecoveryusessl 设置为 OFF），并且组复制的复制用户帐户应用 cachingsha2password 插件（MySQL 8.0 中的默认设置）或 sha256password 插件进行身份验证，则 RSA 密钥对为用于明码替换。在这种状况下，应用 groupreplicationrecoverypublickeypath 零碎变量指定 RSA 公共密钥文件，或者应用 groupreplicationrecoverygetpublic_key 零碎变量申请公共密钥。否则整个分布式回复会因为报错导致复原失败。
3. 利用克隆插件进行分布式复原：
MySQLServer 的克隆插件可从 MySQL8.0.17 取得。如果要将近程克隆操作用于集群中的分布式复原，则必须事后设置现有节点和退出节点能力反对此性能。如果不想在集群中应用此性能，请不要进行设置，在这种状况下，组复制仅应用二进制日志中的状态传输。
要应用克隆插件，必须事后设置至多一个现有的集群节点和退出节点反对近程克隆操作。至多，必须在疏导节点和退出节点上装置克隆插件，将 BACKUPADMIN 权限授予复制用户以进行分布式复原，并将 groupreplicationclonethreshold 零碎变量设置为适当的级别。（默认状况下为 GTID 序列容许的最大值，示意失常状况下，始终优先应用基于二进制日志的状态传输，除非 joiner 节点所申请的事务在组中任意成员中都不存在，这个时候，如果设置好了克隆性能，则无论该零碎变量的值设置为多少，都会触发通过克隆的形式进行分布式复原，例如：全新初始化的 Server 申请加入组时。如果不心愿应用克隆性能，则不要对其进行装置与配置）为了确保疏导节点的最大可用性，倡议设置所有以后和未来的集群节点反对近程克隆操作。以便后续有 Server 退出集群时可能应用近程克隆操作来疾速追赶集群中的最新数据。
在从疏导节点向退出节点传输数据之前，近程克隆操作会删除退出节点中用户创立的表空间和数据。如果在中途意外终止操作，则退出节点可能只剩下局部数据或没有数据。能够通过从新执行组复制主动执行的近程克隆操作来修复此问题。
这里次要针对近程克隆时应用 DATADIRECTORY 子选项指定了一个数据保留门路的状况，指定门路时，数据会保留在指定的目录下，即克隆之后的数据与操作克隆的实例没有关联，须要手动启动实例并指定 datadir 到保留克隆数据的目录进行启动，当然，MGR 插件能够主动执行近程克隆的重试操作（须要保障克隆操作不指定 DATA DIRECTORY 子选项，在这种状况下，近程克隆数据会笼罩掉操作近程克隆的 Server 数据，实现近程克隆操之后，操作近程克隆的 Server 会基于克隆数据主动重新启动）。另外，克隆插件尽管与组复制配合应用对组复制的治理保护来说更加自动化，然而，克隆插件不要求必须在集群中运行（但 MGR 插件必须要装置）。
3.1 克隆的根本条件
对于组复制，应用克隆插件进行分布式复原须要留神以下要点和区别：
现有集群节点和退出节点必须已装置克隆插件并处于激活状态。
疏导节点和退出节点必须在雷同的操作系统上运行，并且必须具备雷同的 MySQL Server 版本（必须为 MySQL 8.0.17 或更高版本能力反对克隆插件）。因而，克隆不适用于成员运行不同 MySQL 版本的集群。
疏导节点和退出节点必须已装置并激活了“组复制”插件，疏导节点上所有激活的其余插件（例如，密钥环插件）也必须在退出节点上处于激活状态。
如果将分布式复原配置为应用 SSL（groupreplicationrecoveryusessl= ON），则组复制会将此设置利用于近程克隆操作。组复制会主动配置克隆 SSL 选项（clonesslca，clonesslcert 和 clonesslkey）的设置，以匹配相应组复制分布式复原选项（groupreplicationrecoverysslca，groupreplicationrecoverysslcert 和 groupreplicationrecoverysslkey）的设置。
不须要在退出节点上为退出集群而在 clonevaliddonor_list 零碎变量中设置无效疏导节点列表。MGR 主动从现有的集群节点中抉择疏导节点后，组复制会主动配置此设置。留神，近程克隆操作应用 server 的 SQL 协定主机名和端口，而非集群成员之间外部通信的地址和端口。
克隆插件具备许多零碎变量，可治理近程克隆操作的网络负载和性能影响。组复制未配置这些设置，因而能够查看它们并依据须要进行设置，也能够将其设置为默认设置，当应用近程克隆操作进行分布式复原时，克隆插件的 cloneenablecompression 设置将利用于该操作，而不会影响现有配置好的组复制压缩设置。
为了对退出节点调用近程克隆操作，组复制应用外部 mysql.session 用户，该用户曾经具备 CLONE_ADMIN 特权，因而无需进行特地设置。
作为近程克隆操作的疏导节点上的克隆用户，组复制应用为分布式复原设置的复制用户。因而，必须在所有反对克隆的集群节点上将此复制用户赋予 BACKUP_ADMIN 特权。在为节点配置组复制时，如果有退出节点，还应向该节点上的复制用户授予此权限，因为退出节点退出集群后，他们能够充当其余退出节点的疏导节点。同一复制用户用于每个集群节点上的分布式复原。要将此权限授予现有节点上的复制用户，能够在禁用二进制日志记录的状况下在每个集群节点上独自执行此语句，或者在启用二进制日志记录的状况下在一个集群的 primary 节点上执行如下语句：
GRANT BACKUP_ADMIN ON *.* TO *rpl_user*@'%';如果在应用 STARTGROUPREPLICATION 以前在提供用户凭据的 server 上应用 CHANGE MASTER TO 指定复制用户凭据，请确保在进行任何近程克隆操作之前，从复制元数据存储库中删除该用户凭据。还要确保在加入成员上设置了 groupreplicationstartonboot =OFF。如果未勾销设置用户凭据，则在近程克隆操作期间会将它们转移到加入成员。而后，可能会在原始成员或从其克隆的成员上意外地应用存储的凭据启动 groupreplicationrecovery 通道。server 启动时（包含在近程克隆操作之后）主动启动组复制将应用存储的用户凭据，并且如果未在 START GROUPREPLICATION 命令上指定分布式复原凭据，也将应用它们。
3.2 克隆的阈值
设置组成员反对克隆后，groupreplicationclonethreshold 零碎变量将指定一个阈值，示意为多少个事务，以便在分布式复原中应用近程克隆操作。如果疏导节点上的事务与退出节点上的事务之间的数量大于此数目，则在技术上可行时，将应用近程克隆操作将状态转移到退出节点。组复制基于现有组成员的 gtidexecuted 集来计算是否已超过阈值。在事务间隙较大的状况下应用近程克隆操作，能够将新成员增加到集群中，而无需当时将集群的数据手动传输到服务器，还能够使落后的节点更无效地进行数据追赶。
groupreplicationclone_threshold 组复制零碎变量的默认设置十分高（GTID 中事务的最大容许序列号），因而，只有有可能从二进制日志转移状态，它都会无效地禁用克隆。要使组复制可能抉择更适宜状态传输的近程克隆操作，设置零碎变量，以指定多少个事务作为要进行克隆的事务距离。
PS：
不要在沉闷的集群中为 groupreplicationclone_threshold 应用较低的设置。如果在进行近程克隆操作的同时集群中产生了超过阈值的事务，则加入成员在重新启动后会再次触发近程克隆操作，并且能够无限期地持续进行。为防止这种状况，确保将阈值设置为一个牢靠的数字，该阈值应大于在近程克隆操作所破费的时间段内集群中预期产生的事务数。
当无奈从疏导节点的二进制日志进行状态转移时，组复制尝试执行近程克隆操作，而不论此时的阈值如何，例如，因为加入成员所需的事务在任何现有组成员的二进制日志中均不可用。组复制基于现有组成员的 gtidpurged 集对此进行标识。当所需的事务在任何成员的二进制日志文件中不可用时，不能应用 groupreplicationclonethreshold 零碎变量来停用克隆，因为在这种状况下，克隆是手动将数据传输到退出节点的惟一选
3.3 克隆操作
设置集群节点和退出节点进行克隆后，组复制将治理近程克隆操作。近程克隆操作须要一些工夫能力实现，具体取决于数据的大小。
performanceschema.cloneprogress 表中记录了整个克隆操作的每一个阶段及其对应的阶段信息，每一个阶段会生成一行记录（留神，该表中只记录一次克隆操作的过程信息，下一次执行克隆操作时，上一次的信息会被笼罩）
select * from clone_progress;
+------+-----------+-----------+----------------------------
+----------------------------+---------+------------+--------
----+------------+------------+---------------+
| ID | STAGE | STATE | BEGIN_TIME | END_TIME | THREADS |
ESTIMATE | DATA | NETWORK | DATA_SPEED | NETWORK_SPEED |
+------+-----------+-----------+----------------------------
+----------------------------+---------+------------+-------
-----+------------+------------+---------------+
| 1 | DROP DATA | Completed | 2019-10-08 16:46:58.757964 |
2019-10-08 16:46:59.128436 | 1 | 0 | 0 | 0 | 0 | 0 |
| 1 | FILE COPY | Completed | 2019-10-08 16:46:59.128766 |
2019-10-08 16:47:16.857536 | 8 | 8429731840 | 8429731840 |
8430190882 | 0 | 0 |
| 1 | PAGE COPY | Completed | 2019-10-08 16:47:16.857737 |
2019-10-08 16:47:17.159531 | 8 | 0 | 0 | 785 | 0 | 0 |
| 1 | REDO COPY | Completed | 2019-10-08 16:47:17.159748 |
2019-10-08 16:47:17.460516 | 8 | 2560 | 2560 | 3717 | 0 | 0
|
| 1 | FILE SYNC | Completed | 2019-10-08 16:47:17.460788 |
2019-10-08 16:47:20.926184 | 8 | 0 | 0 | 0 | 0 | 0 |
| 1 | RESTART | Completed | 2019-10-08 16:47:20.926184 | | 1 | RESTART | Completed | 2019-10-08 16:47:20.926184 |
2019-10-08 16:47:28.623732 | 0 | 0 | 0 | 0 | 0 | 0 |
| 1 | RECOVERY | Completed | 2019-10-08 16:47:28.623732 |
2019-10-08 16:47:34.898453 | 0 | 0 | 0 | 0 | 0 | 0 |
+------+-----------+-----------+----------------------------
+----------------------------+---------+------------+-------
-----+------------+------------+---------------+
7 rows in set (0.00 sec)
select * from clone_status\G
*************************** 1. row ***************************
ID: 1
PID: 0
STATE: Completed
BEGIN_TIME: 2019-10-08 16:46:58.758
END_TIME: 2019-10-08 16:47:34.898
SOURCE: 10.10.30.162:3306
DESTINATION: LOCAL INSTANCE
ERROR_NO: 0
ERROR_MESSAGE:
BINLOG_FILE: mysql-bin.000022
BINLOG_POSITION: 222104704
GTID_EXECUTED: 320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-2771494
1 row in set (0.01 sec)PS：
状态转移实现后，组复制将重新启动退出节点以实现该过程。如果在退出节点上设置了 groupreplicationstartonboot = OFF，例如，因为在 START GROUPREPLICATION 语句上指定了复制用户凭据，则在重新启动后必须再次手动公布 START GROUPREPLICATION。如果在配置文件中或应用 SET PERSIST 语句设置了 groupreplicationstartonboot = ON 以及启动组复制所需的其余设置，则无需干涉，该过程会主动持续使退出节点设置为 online 状态。
近程克隆操作会将疏导节点的数据目录下的各种数据文件克隆到退出节点中（表中可能蕴含了一些配置信息及其用户数据等）。但保留在配置文件（如组复制本地地址配置等）中的组复制成员设置不会被克隆，也不会在退出节点上做任何更改。即，组复制相干的配置须要自行配置好，不能跟集群中的现有成员抵触，近程克隆操作只负责克隆数据文件，不会克隆配置信息（当然，如果某些配置信息保留在表里，对于克隆操作来说，也会被当做数据进行克隆）。
如果近程克隆过程破费很长时间，则在 MySQL 8.0.22 之前的发行版中，在该时间段内为该集群累积的一组认证信息可能会变得太大而无奈传输给加入成员。在这种状况下，加入成员会记录一条谬误音讯，并且不会退出该集群。从 MySQL 8.0.22 开始，组复制以不同的形式治理利用事务的垃圾收集过程，以防止产生这种状况。在晚期版本中，如果的确看到此谬误，则在近程克隆操作实现之后，请期待两分钟，以容许进行一轮垃圾收集，以减小集群的认证信息的大小。而后在加入成员上收回以下申明，以使其进行尝试利用先前的认证信息集：
RESET SLAVE FORCHANNEL group_replication_recovery;
RESET REPLICA FOR CHANNEL group_replication_recovery;（从 8.0.22 开始）疏导节点中用于组复制专用通道 groupreplicationrecovery 的用户凭证（复制用户和明码），在克隆操作实现之后，会被新成员应用，所以，该用户和明码及其权限必须在新成员中也无效。因而，所有组成员才可能应用雷同的复制用户和明码通过近程克隆操作接管状态传输进行分布式复原。然而，组复制会保留与应用 SSL 相干的组复制通道设置，这些设置对单个成员来说能够是惟一的（即，每个组成员应用不同的复制用户和明码）。如果应用了 PRIVILEGECHECKSUSER 帐户来帮忙爱护复制利用线程（从 MySQL8.0.18 开始，能够创立一个具备特定权限的用户账号，而后将其指定为 PRIVILEGECHECKSUSER 帐户，这样能够避免将未经受权或意外将具备特权的账号用于组复制通道），则在克隆操作实现之后新加入成员不会应用该用户帐户作为组复制通道的用户。此时必须为组复制通道手工指定适合的复制用户。
如果疏导节点用于 groupreplicationrecovery 复制通道的复制用户凭据已应用 CHANGE MASTER TO 语句存储在复制元数据存储库中，则在克隆后将它们转移到加入成员并由其应用，并且它们在此处必须无效。因而，应用存储的凭据，所有通过近程克隆操作接管状态转移的组成员都会主动接管复制用户和明码，进行分布式复原。如果在 START GROUPREPLICATION 语句上指定了复制用户凭据，则这些凭据将用于启动近程克隆操作，然而在克隆后它们不会传输到退出节点并由其应用。如果不心愿将凭据转移到新的 server 上并记录在那里，确保在进行近程克隆操作之前勾销设置它们，并应用 START GROUPREPLICATION 代替提供它们。
ps: 如果已应用 PRIVILEGECHECKSUSER 帐户来帮忙爱护复制应用程序，则从 MySQL 8.0.19 开始，会将 PRIVILEGECHECKSUSER 帐户以及来自疏导节点的相干设置克隆进去。如果将退出节点设置为在启动时启动组复制，它将主动应用该帐户在相应的复制通道上进行权限查看。（在 MySQL 8.0.18 中，因为许多限度，倡议不要将 PRIVILEGECHECKSUSER 帐户用于组复制通道。）
3.4 克隆的其余用途
组复制启动并治理用于分布式复原的克隆操作。设置为反对克隆的组成员也能够参加用户手动启动的克隆操作。例如，可能心愿通过从组成员作为疏导节点来进行克隆来创立新的 MySQL 实例，然而不心愿新的服务器实例立刻退出或可能永远不会退出该集群。
在所有反对克隆的发行版中，能够手动启动波及进行了组复制的组成员的克隆操作。因为克隆要求疏导节点和接收数据的节点上的克隆插件必须匹配，因而即便不心愿该实例退出集群，也必须在另一个实例上装置并激活组复制插件。能够通过收回以下语句来装置插件：
INSTALL PLUGIN group_replication SONAME'group_replication.so';在 MySQL 8.0.20 之前的发行版中，如果操作波及正在运行“组复制”的组成员，则无奈手动启动克隆操作。从 MySQL8.0.20 开始，只有克隆操作不会删除和替换接收者上的数据，就能够执行此操作。因而，如果正在运行组复制，则用于启动克隆操作的语句必须蕴含 DATA DIRECTORY 子句。