18.7.4 消息压缩

对于在线群组成员之间发送的消息，群组复制默认启用消息压缩。是否压缩特定消息取决于您使用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 压缩算法时，不要设置大于 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系统变量，也可以用来节省带宽。事务有效负载在组成员之间传输时保持压缩状态。如果将二进制日志事务压缩与 Group Replication 的消息压缩结合使用，消息压缩作用于数据的机会较少，但仍可以压缩标头以及未压缩的事件和事务有效负载。有关二进制日志事务压缩的更多信息，请参阅第 5.4.4.5 节，“二进制日志事务压缩”.

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

图 18.13 压缩支持

当网络带宽成为瓶颈时，消息压缩可以在组通信级别提供高达 30-40% 的吞吐量提升。这在有大量服务器负载的情况下尤其重要。TCP之间互连的对等性质ñ组中的参与者使发送者发送相同数量的数据ñ次。此外，二进制日志可能表现出高压缩比。这使得压缩成为包含大型事务的组复制工作负载的一项引人注目的功能。