### 18.7.4 消息压缩

[](<>)

对于在线群组成员之间发送的消息，群组复制默认启用消息压缩。是否压缩特定消息取决于您使用[`group_replication_compression_threshold`](group-replication-options.html#sysvar_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-options.html#sysvar_group_replication_compression_threshold)为零，消息压缩被禁用。

Group Replication 使用 LZ4 压缩算法来压缩在组中发送的消息。请注意，LZ4 压缩算法支持的最大输入大小为 2113929216 字节。此限制低于最大可能值[`group_replication_compression_threshold`](group-replication-options.html#sysvar_group_replication_compression_threshold)系统变量，与 XCom 接受的最大消息大小匹配。因此，LZ4 最大输入大小是消息压缩的实际限制，当启用消息压缩时，无法提交超过此大小的事务。使用 LZ4 压缩算法时，不要设置大于 2113929216 字节的值[`group_replication_compression_threshold`](group-replication-options.html#sysvar_group_replication_compression_threshold).

的价值[`group_replication_compression_threshold`](group-replication-options.html#sysvar_group_replication_compression_threshold)组复制并不要求所有组成员都相同。但是，建议对所有组成员设置相同的值，以避免不必要的事务回滚、消息传递失败或消息恢复失败。

从 MySQL 8.0.18 开始，您还可以通过从捐赠者的二进制日志中转移状态的方法，为分布式恢复发送的消息配置压缩。这些消息的压缩是从已经在组中的捐助者发送给加入成员的，使用[`group_replication_recovery_compression_algorithms`](group-replication-options.html#sysvar_group_replication_recovery_compression_algorithms)和[`group_replication_recovery_zstd_compression_level`](group-replication-options.html#sysvar_group_replication_recovery_zstd_compression_level)系统变量。有关详细信息，请参阅[第 4.2.8 节，“连接压缩控制”](connection-compression-control.html).

二进制日志事务压缩（自 MySQL 8.0.20 起可用），由[`binlog_transaction_compression`](replication-options-binary-log.html#sysvar_binlog_transaction_compression)系统变量，也可以用来节省带宽。事务有效负载在组成员之间传输时保持压缩状态。如果将二进制日志事务压缩与 Group Replication 的消息压缩结合使用，消息压缩作用于数据的机会较少，但仍可以压缩标头以及未压缩的事件和事务有效负载。有关二进制日志事务压缩的更多信息，请参阅[第 5.4.4.5 节，“二进制日志事务压缩”](binary-log-transaction-compression.html).

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

[](<>)

**图 18.13 压缩支持**

<img alt="The MySQL Group Replication plugin architecture is shown as described in an earlier topic, with the five layers of the plugin positioned between the MySQL server and the replication group. Compression and decompression are handled by the Group Communication System API, which is the fourth layer of the Group Replication plugin. The group communication engine (the fifth layer of the plugin) and the group members use the compressed transactions with the smaller data size. The MySQL Server core and the three higher layers of the Group Replication plugin (the APIs, the capture, applier, and recovery components, and the replication protocol module) use the original transactions with the larger data size." src="images/gr-compress-decompress.png" height="608" width="588" />

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