对于在线组成员之间发送的消息，组复制默认启用消息压缩。是否对特定消息进行压缩取决于您使用 group_replication_compression_threshold 系统变量配置的阈值。有效负载超过指定字节数的消息将被压缩。For messages sent between online group members, Group Replication enables message compression by default. Whether a specific message is compressed depends on the threshold that you configure using the group_replication_compression_threshold system variable. Messages that have a payload larger than the specified number of bytes are compressed.

默认的压缩阈值为 1000000 字节。例如，您可以使用以下语句将压缩阈值增加到 2MB：The default compression threshold is 1000000 bytes. You could use the following statements to increase the compression threshold to 2MB, for example:

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

如果将 group_replication_compression_threshold 设置为零，则消息压缩将被禁用。If you set group_replication_compression_threshold to zero, message compression is disabled.

组复制使用 LZ4 压缩算法对组中发送的消息进行压缩。请注意，LZ4 压缩算法支持的最大输入大小为 2113929216 字节。该限制低于 group_replication_compression_threshold 系统变量的最大可能值，该值与 XCom 接受的最大消息大小相匹配。因此，LZ4 最大输入大小是消息压缩的实际限制，当启用消息压缩时，超过此大小的事务无法提交。使用 LZ4 压缩算法时，请不要为 group_replication_compression_threshold 设置大于 2113929216 字节的值。Group Replication uses the LZ4 compression algorithm to compress messages sent in the group. Note that the maximum supported input size for the LZ4 compression algorithm is 2113929216 bytes. This limit is lower than the maximum possible value for the group_replication_compression_threshold system variable, which is matched to the maximum message size accepted by XCom. The LZ4 maximum input size is therefore a practical limit for message compression, and transactions above this size cannot be committed when message compression is enabled. With the LZ4 compression algorithm, do not set a value greater than 2113929216 bytes for group_replication_compression_threshold.

group_replication_compression_threshold 的值并不要求在所有组成员上相同。然而，建议在所有组成员上设置相同的值，以避免不必要的事务回滚、消息传递失败或消息恢复失败。The value of group_replication_compression_threshold is not required by Group Replication to be the same on all group members. However, it is advisable to set the same value on all group members in order to avoid unnecessary rollback of transactions, failure of message delivery, or failure of message recovery.

您还可以配置通过从捐赠者的二进制日志进行状态转移的方法发送的分布式恢复消息的压缩。这些消息由已经在组中的捐赠者发送给加入的成员，其压缩单独由 group_replication_recovery_compression_algorithms 和 group_replication_recovery_zstd_compression_level 系统变量控制。有关更多信息，请参见 第 6.2.8 节，“连接压缩控制”。You can also configure compression for messages sent for distributed recovery by the method of state transfer from a donor's binary log. Compression for these messages, which are sent from a donor already in the group to a joining member, is controlled separately using the group_replication_recovery_compression_algorithms and group_replication_recovery_zstd_compression_level system variables. For more information, see Section 6.2.8, “Connection Compression Control”.

二进制日志事务压缩，可以通过 binlog_transaction_compression 系统变量启用，也可用于节省带宽。事务有效负载在其在组成员之间传输时保持压缩状态。如果您将二进制日志事务压缩与组复制的消息压缩结合使用，消息压缩对数据的作用机会会减少，但仍然可以压缩头部以及未压缩的事件和事务有效负载。有关二进制日志事务压缩的更多信息，请参见 第 7.4.4.5 节，“二进制日志事务压缩”。Binary log transaction compression, enabled by the binlog_transaction_compression system variable, can also be used to save bandwidth. The transaction payloads remain compressed when they are transferred between group members. If you use binary log transaction compression in combination with Group Replication's message compression, message compression has less opportunity to act on the data, but can still compress headers and those events and transaction payloads that are uncompressed. For more information on binary log transaction compression, see Section 7.4.4.5, “Binary Log Transaction Compression”.

在群组中发送的消息压缩发生在群组通信引擎级别，在数据交给群组通信线程之前，因此它发生在mysql用户会话线程的上下文中。如果消息负载大小超过group_replication_compression_threshold设置的阈值，事务负载会在发送到群组之前被压缩，并在接收时解压。接收到消息时，成员会检查消息封套以确认其是否被压缩。如果需要，成员会在将事务传递给上层之前进行解压。此过程如下图所示。Compression for messages sent in the group happens at the group communication engine level, before the data is handed over to the group communication thread, so it takes place within the context of the mysql user session thread. If the message payload size exceeds the threshold set by group_replication_compression_threshold, the transaction payload is compressed before being sent out to the group, and decompressed when it is received. Upon receiving a message, the member checks the message envelope to verify whether it is compressed or not. If needed, then the member decompresses the transaction, before delivering it to the upper layer. This process is shown in the following figure.

图 20.13 压缩支持Figure 20.13 Compression Support

当网络带宽成为瓶颈时，消息压缩可以在组通信层面提供高达 30-40% 的吞吐量提升。这在大型服务器负载组的背景下尤为重要。组中 N 个参与者之间的 TCP 点对点互连性质使得发送者需要发送相同数量的数据 N 次。此外，二进制日志很可能表现出较高的压缩比。这使得压缩成为包含大事务的组复制工作负载中的一个有吸引力的特性。When network bandwidth is a bottleneck, message compression can provide up to 30-40% throughput improvement at the group communication level. This is especially important within the context of large groups of servers under load. The TCP peer-to-peer nature of the interconnections between N participants in the group makes the sender send the same amount of data N times. Furthermore, binary logs are likely to exhibit a high compression ratio. This makes compression a compelling feature for Group Replication workloads that contain large transactions.