MySQL 组复制远程克隆为什么不使用组通信压缩参数

MySQL 组复制做分布式恢复时，远程克隆传输的是 donor 的数据和部分持久化设置，它并不走组成员之间的普通组通信消息压缩路径。因此，看到 group_replication_compression_threshold 一类组通信参数没有改变克隆传输效果，并不是参数失效，而是检查错了对象。

远程克隆使用 Clone 插件自己的 clone_enable_compression 设置；组复制只负责选择和管理这次克隆。两条通道的压缩参数不能互相替代。

官方地址：https://dev.mysql.com/doc/refman/8.4/en/group-replication-cloning.html

下面按“路径区分—前置条件—配置阈值—判断结果”的顺序拆开这个问题。示例语句用于说明检查思路，请先在测试组验证，再应用到生产成员。

先看清组通信和远程克隆不是同一条路径

组复制的组通信负责成员之间交换复制协议消息、成员状态和事务相关信息；远程克隆则由 joining member 向选定的 donor 请求大块数据传输。前者是 Group Replication 的通信设置，后者是 Clone 插件的传输设置。

所以排查时应先问一句“当前慢的是哪条路径”。如果问题发生在成员消息交换，才去看组通信压缩相关变量；如果问题发生在加入成员的数据初始化，则应看 Clone 插件变量、磁盘、网络和 donor 选择。

远程克隆为什么单独使用 Clone 插件参数

官方手册明确说明：为组复制配置远程克隆时，Clone 插件的 clone_enable_compression 设置适用于这次操作，而不是组复制的压缩设置；组复制不会替你配置 Clone 插件中用于管理网络负载和性能影响的变量。

这样设计的原因很直接：组通信消息和全量数据传输的大小、持续时间与资源模型不同。一个面向消息的压缩开关不能自动决定大批量数据复制是否压缩，也不能替代 Clone 插件对并发、带宽和磁盘的控制。

-- 在目标实例检查 Clone 插件的压缩开关；不要用组通信变量代替它。
SHOW VARIABLES LIKE 'clone_enable_compression';

-- 同时查看组复制相关设置，便于确认自己检查的是哪条路径。
SHOW VARIABLES LIKE 'group_replication%compression%';

如果第一条语句显示的是关闭状态，应该根据当前 MySQL 版本、网络带宽和 CPU 余量决定是否启用，而不是仅因为组通信已经开启压缩就推断克隆也会压缩。

先把 donor 和 joining member 的条件补齐

压缩开关不是远程克隆能否工作的唯一条件。donor 和 joining member 都需要安装并激活 Clone 插件；用于分布式恢复的复制用户还需要具备 BACKUP_ADMIN 权限。两端还必须使用相同操作系统和相同 MySQL Server release series，不能把不同小版本系列当成可以直接克隆的组合。

-- 在每个支持克隆的成员确认插件已安装并处于 ACTIVE。
SELECT PLUGIN_NAME, PLUGIN_STATUS
FROM INFORMATION_SCHEMA.PLUGINS
WHERE PLUGIN_NAME = 'clone';

-- 在 donor 上为分布式恢复复制用户补齐克隆所需权限。
GRANT BACKUP_ADMIN ON *.* TO 'rpl_user'@'%';

如果 Clone 插件只在 donor 上安装，joining member 仍然不能完成由组复制管理的远程克隆。反过来，只有 joining member 安装插件也不够，因为组复制需要从可用 donor 获取数据。

另外，远程克隆会先移除 joining member 上用户创建的表空间和数据，再传输 donor 数据。执行前应把它当作一次覆盖式初始化，而不是普通增量同步。

用 clone_enable_compression 和阈值分别做两件事

clone_enable_compression 决定 Clone 插件的数据传输是否启用压缩；group_replication_clone_threshold 决定在分布式恢复时，事务差距超过多少才倾向使用远程克隆。这两个变量解决的是不同问题：一个是“怎么传”，另一个是“什么时候选这条传输路径”。

-- 查看当前克隆阈值；它以事务数量表示，不是字节数。
SHOW VARIABLES LIKE 'group_replication_clone_threshold';

-- 示例：根据测试得到的事务差距设置阈值。
-- 具体数值应结合克隆耗时和组内事务产生速度计算。
SET GLOBAL group_replication_clone_threshold = 100000;

-- 仅示意克隆压缩开关的配置入口，生产变更前应先评估 CPU 与带宽。
SET GLOBAL clone_enable_compression = ON;

手册指出，阈值默认值非常高，实际上会在二进制日志仍可完成状态传输时尽量不使用克隆。即使阈值没有触发，当所需事务已经不在任何成员的二进制日志中时，组复制仍可能尝试克隆，因为这时克隆是自动状态传输的替代路径。

阈值也不能设置得过低。克隆耗时期间如果组内产生的事务数持续超过阈值，joining member 可能在重启后再次触发克隆，形成反复尝试。应让阈值高于一次克隆期间预计产生的事务量。

排查时按这组证据判断，而不是只看一个变量

遇到“我已经打开组通信压缩，为什么克隆还是没有变化”时，可以按下面顺序缩小范围：

1. 确认当前确实发生的是分布式恢复中的远程克隆，而不是二进制日志状态传输。
2. 在 donor 和 joining member 分别检查 Clone 插件是否为 ACTIVE，并确认版本系列和操作系统匹配。
3. 检查 joining member 使用的复制用户是否在 donor 上拥有 BACKUP_ADMIN。
4. 读取 clone_enable_compression，把它与组通信压缩变量分开记录。
5. 结合 group_replication_clone_threshold、gtid_executed 和 gtid_purged 判断为什么选中了某种状态传输方式。

这里的检查结果需要放在同一份变更记录里：路径、donor、joining member、阈值、Clone 压缩开关和克隆状态缺一不可。只记录组通信变量，无法解释一次全量克隆的网络行为。

克隆结束后的重启和凭据边界

状态传输完成后，Group Replication 会重启 joining member 以完成流程。如果 group_replication_start_on_boot=OFF，重启后还需要手动执行 START GROUP_REPLICATION；如果启动所需设置已经写入配置文件或持久化变量，流程可以自动继续。

还要注意凭据的来源。如果复制用户凭据通过 CHANGE REPLICATION SOURCE TO 写入复制元数据仓库，远程克隆可能把它们传到 joining member；如果在 START GROUP_REPLICATION 时提供凭据，则这些凭据用于启动克隆，但不会在克隆后作为持久凭据传过去。生产环境应按安全要求选择方式，并清理不希望被带到新成员的存储凭据。

-- 只有在启动项被设置为 OFF 且实例已重启后，才需要手动继续组复制。
START GROUP_REPLICATION;

-- 用状态表确认成员是否已经回到可用状态。
SELECT MEMBER_HOST, MEMBER_STATE, MEMBER_ROLE
FROM performance_schema.replication_group_members;

常见问题

打开组通信压缩后，远程克隆会自动压缩吗？ 不会。远程克隆使用 Clone 插件的 clone_enable_compression。

把 group_replication_clone_threshold 调小是不是就一定会克隆？ 不是。阈值只是事务差距条件，插件、权限、版本、日志可用性等条件仍然决定操作是否可行。

克隆完成后 joining member 为什么没有自动上线？ 可能是克隆后的重启把 Group Replication 停在了关闭状态；检查 group_replication_start_on_boot，必要时手动启动。

远程克隆失败后能不能只看组通信日志？ 不够。还应同时查看 Clone 插件状态、权限、磁盘空间、网络路径和状态传输日志。

最后记住一句判断口诀：组通信压缩解决“成员消息怎么传”，Clone 压缩解决“初始化数据怎么传”，克隆阈值解决“什么时候选择克隆”。把这三件事分开记录，远程克隆的配置和排障就不会再被同名参数带偏。