17.9.7.2 邮件压缩

对于在线组成员之间发送的消息,默认情况下,组复制启用消息压缩。是否压缩特定消息取决于您使用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 压缩算法支持的最大 Importing 大小为 2113929216 字节。此限制低于group_replication_compression_threshold系统变量的最大可能值,该值与 XCom 接受的最大消息大小匹配。因此,LZ4 最大 Importing 大小是消息压缩的实际限制,并且在启用消息压缩时无法提交超过此大小的事务。使用 LZ4 压缩算法时,请不要为group_replication_compression_threshold设置大于 2113929216 字节的值。

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

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

图 17.15 压缩支持

如先前主题中所述,显示了 MySQL 组复制插件体系结构,该插件的五层位于 MySQL 服务器和复制组之间。压缩和解压缩由 Group Communication System API 处理,这是 Group Replication 插件的第四层。组通信引擎(插件的第五层)和组成员使用数据量较小的压缩事务。 MySQL Server 核心和组复制插件的三个较高层(API,捕获,应用程序和恢复组件以及复制协议模块)使用具有较大数据量的原始事务。

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