对于在线组成员之间发送的消息，组复制默认情况下启用消息压缩。特定消息是否被压缩取决于您使用 group_replication_compression_threshold 系统变量配置的阈值。负载大于指定字节数的消息将被压缩。

默认压缩阈值为 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 次。此外，二进制日志很可能表现出很高的压缩率。这使得压缩成为包含大型事务的组复制工作负载的引人注目的功能。