在线组成员之间发送的消息，Group Replication 默认启用消息压缩。是否将特定消息压缩取决于使用group_replication_compression_threshold系统变量配置的阈值。超过指定字节数的消息将被压缩。

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

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

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

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

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

您还可以使用捐赠者二进制日志中的状态转移方法来配置分布式恢复消息的压缩。控制这些消息（来自已经加入组的捐赠者发送到加入组的成员）的压缩使用group_replication_recovery_compression_algorithms和group_replication_recovery_zstd_compression_level系统变量。更多信息，请见第6.2.8节，“连接压缩控制”。

二进制日志事务压缩，通过系统变量binlog_transaction_compression启用，可以节省带宽。事务负载在传输到组成员之间时保持压缩状态。如果您将二进制日志事务压缩与Group Replication的消息压缩结合使用，消息压缩可以对未压缩的事务负载和事件头部进行压缩，但仍然可以对未压缩的事务负载进行压缩。有关二进制日志事务压缩的更多信息，请见第7.4.4.5节，“Binary Log Transaction Compression”。

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

图20.13 压缩支持

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