对于在线组成员之间发送的邮件，默认情况下，组复制使消息压缩能够。是否压缩了特定消息取决于您使用的阈值group_replication_compression_threshold.系统变量。压缩具有大于指定字节数大的有效载荷的消息。

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

停止group_replication;设置全局group_replication_compression_threshold = 2097152;开始group_replication;

如果你设置了group_replication_compression_threshold.为零，禁用消息压缩。

组复制使用LZ4压缩算法来压缩在组中发送的消息。请注意，LZ4压缩算法的最大支持输入大小为2113929216字节。该限制低于最大可能值group_replication_compression_threshold.系统变量与Xcom接受的最大消息大小匹配。因此，LZ4最大输入大小是消息压缩的实际限制，并且在启用消息压缩时无法提交此大小的交易。使用LZ4压缩算法，请勿设置大于2113929216字节的值group_replication_compression_threshold.。

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

从MySQL 8.0.18，您还可以通过从捐赠者二进制日志的状态传输方法为分布式恢复发送的消息来配置压缩。对这些消息的压缩从已经组中的捐赠者发送到连接成员，是单独控制的group_replication_recovery_compression_algorithms.和group_replication_recovery_zstd_compression_Level.系统变量。有关更多信息，请参阅第4.2.8节“连接压缩控制”。

二进制日志事务压缩（可用作mysql 8.0.20），由此激活binlog_transaction_compression.系统变量也可用于保存带宽。当在组成员之间传输时，交易有效载荷仍然被压缩。如果使用与组复制的消息压缩结合使用二进制日志事务压缩，则消息压缩可能较少机会用于对数据进行行动，但仍然可以压缩标题和未压缩的事件和事务有效负载。有关二进制日志事务压缩的更多信息，请参阅第5.4.4.5节“二进制日志事务压缩”。

在组通信引擎级别发生在组中发送的消息的压缩，在数据被移交给组通信线程之前，因此在上下文中发生mysql.用户会话线程。如果消息有效载荷大小超过阈值设置group_replication_compression_threshold.，事务有效载荷在被发送到组之前被压缩，并在收到时解压缩。在接收到消息时，成员检查消息包络以验证是否被压缩。如果需要，则该成员在将交易中解压缩到上层之前。此过程如下图所示。

图18.15压缩支持

当网络带宽是瓶颈时，消息压缩可以在组通信水平上提供高达30-40％的吞吐量改进。这在负载下的大型服务器的背景下尤为重要。互连之间的TCP对等性质N.集团的参与者使发件人发送相同数量的数据N.时代。此外，二进制日志可能表现出高压缩比。这使得压缩包含大型事务的组复制工作负载的令人信服的功能。