在组复制中，默认情况下，消息压缩是启用的。是否压缩特定消息取决于使用 group_replication_compression_threshold 系统变量配置的阈值。 payload 大小超过指定字节数的消息将被压缩。

默认压缩阈值为 1000000 字节。例如，您可以使用以下语句将压缩阈值增加到 2MB：

STOP GROUP_REPLICATION;
SET GLOBAL group_replication_compression_threshold = 2097152;
START GROUP_REPLICATION;

如果将 group_replication_compression_threshold 设置为零，则消息压缩将被禁用。

组复制使用 LZ4 压缩算法来压缩组内发送的消息。请注意，LZ4 压缩算法的最大输入大小为 2113929216 字节。这限制低于 group_replication_compression_threshold 系统变量的最大可能值，该值与 XCom 接受的最大消息大小相匹配。因此，LZ4 的最大输入大小是消息压缩的实际限制，超过该大小的交易无法在启用消息压缩时提交。使用 LZ4 压缩算法时，不要将 group_replication_compression_threshold 设置为大于 2113929216 字节的值。

组成员不需要将 group_replication_compression_threshold 设置为相同的值。但是，建议在所有组成员上设置相同的值，以避免交易回滚、消息传递失败或消息恢复失败。

您还可以使用 group_replication_recovery_compression_algorithms 和 group_replication_recovery_zstd_compression_level 系统变量来配置分布式恢复期间的消息压缩。有关更多信息，请参阅 第 6.2.8 节，“连接压缩控制”。

二进制日志事务压缩，启用了 binlog_transaction_compression 系统变量，也可以节省带宽。事务负载保持压缩状态，当它们在组成员之间传输时。如果您将二进制日志事务压缩与组复制的消息压缩结合使用，消息压缩将少有机会作用于数据，但仍可以压缩头部和未压缩的事件和事务负载。有关二进制日志事务压缩的更多信息，请参阅 第 7.4.4.5 节，“二进制日志事务压缩”。

组内消息压缩发生在组通信引擎级别，在数据被传递给组通信线程之前，因此它发生在 mysql 用户会话线程的上下文中。如果消息负载大小超过 group_replication_compression_threshold 设置的阈值，则事务负载将被压缩，然后发送到组中，并在接收时解压缩。成员在接收消息时检查消息封套，以确定是否压缩。如果需要，则成员解压缩事务，然后将其传递给上层。该过程如以下图所示。

图 20.13 压缩支持

当网络带宽成为瓶颈时，消息压缩可以在组通信级别上提供高达30-40%的吞吐量改进。这在大型服务器组下负载的情况下尤其重要。组中N个参与者的TCP点对点互连性使得发送方将相同的数据发送N次。此外，二进制日志很可能具有高压缩比。这使得压缩成为包含大事务的Group Replication工作负载的引人注目的功能。