技术分享 | MySQL binlog 压缩功能对性能的影响

之前有做过一个 binlog 压缩能节约多少空间的测试，效果上看还是比较理想的，可以节约一半以上的空间。但是这个又引出了一个新的问题，那就是这个功能对性能有多大影响呢？于是我又在测试环境试了一下，测试环境的物理配置如下。

根据之前的经验这套测试环境在 120 个表 + 240 个并发的情况，可以取得一个性能上的极大值；所以在这里就直接使用这个作为测试压力。

第一步：安装。

第二步：创建测试用户。

第三步：填充数据并进行压力测试。

性能表现。

资源消耗情况。

第一步：安装。

第二步：创建测试用户。

第三步：填充数据并进行压力测试。

性能表现。

资源消耗情况。

第一步: 关闭 binlog 压缩功能。

第二步：进行压力测试。

性能表现。

资源消耗情况。

开启 binlog 压缩会对性能有影响，大概会让性能下降 1%，cpu 多消耗 1%。

1. 开启压缩功能后，通过 ZSTD 算法对每个事务进行压缩，写入二进制日志。

2. 新版本更改了 libbinlogevents，新增 Transaction_payload_event 作为压缩后的事务表示形式。

class Transaction_payload_event : public Binary_log_event { protected:  const char *m_payload uint64_t m_payload_size transaction::compression::type m_compression_type uint64_t m_uncompressed_size

3. 新增 Transaction_payload_event 编码器/解码器，用于实现对压缩事务的编码和解码。

namespace binary_log {

namespace transaction {

namespace compression {

enum type {

/* No compression. */

NONE = 0,

/* ZSTD compression. */

ZSTD = 1,

}

4. 在 mysqlbinlog 中设计和实现每个事务的解压缩和解码，读取出来的日志与未经压缩的原日志相同，并打印输出所用的压缩算法，事务形式，压缩大小和未压缩大小，作为注释。

#200505 16:24:24 server id 1166555110  end_log_pos 2123 CRC32 0x6add0216    Transaction_Payload     payload_size=863    compression_type=ZSTD   uncompressed_size=2184# Start of compressed events!

5. 从库（或 MGR-member）在接收已压缩的 binlog 时识别 Transaction_payload_event，不进行二次压缩或解码。以原本的压缩状态写入中继日志；保持压缩状态。回放日志的解码和解压缩过程由 SQL 线程负责。

总结日志压缩过程为：

1）单位事务需要提交并记录 binlog。

2）压缩编码器在缓存中通过 ZSTD 算法压缩以及编码该事务。

3）将缓存中压缩好的事务写入日志中，落盘。

日志读取过程为：

客户端工具（mysqlbinlog、sql 线程）对压缩日志进行解压缩、解码。解压出原本未压缩的日志进行读取或回放。

注意事项

1. 压缩功能以事务为单位进行压缩，不支持非事务引擎。

2. 仅支持对 ROW 模式的 binlog 进行压缩。

3. 目前仅支持 ZSTD 压缩算法，但是，底层设计是开放式的，因此后续官方可能会根据需要添加其他压缩算法（例如 zlib 或 lz4）。

4. 压缩动作是并行进行的，并且发生在 binlog 落盘之前的缓存步骤中。

5. 压缩过程占用本机 CPU 及内存资源。在主从延迟的场景中，如果性能瓶颈时，网络带宽、压缩功能可以有效缓解主从延迟；但是如果性能瓶颈是本机自身处理能力，那么压缩功能反而可能加大主从延迟。

---