跳转到主要内容

Binlog 优化

AliSQL 8.0.44-2 提供两种默认关闭的 Binlog 优化,分别面向不同类型的事务。Persist Binlog Into Redo V2 将符合条件的 Binlog 事件随 Redo 持久化;Binlog Cache Free Flush 避免在提交时再次复制符合条件的溢出大事务缓存。

事务不满足条件时,两种优化都会使用标准 Binlog Group Commit。

选择机制

机制工作方式默认值大小阈值DuckDB 限制
Persist Binlog Into Redo V2符合条件的事务 Binlog 缓存随 InnoDB Redo 持久化,再由后台线程写入 BinlogOFF默认最多 1 MiB;可配置 0–10 MiB可在 duckdb_mode=NONE 下运行;启用 DuckDB 模式时无法开启
Binlog Cache Free Flush将已完成且已溢出的事务缓存重命名为下一个 BinlogOFF默认大于 256 MiB;阈值最低可配置为 10 MiB当前包含 DuckDB 的构建即使 duckdb_mode=NONE 也会使用标准 Binlog Group Commit

只有满足全部条件的事务才会使用对应优化。请使用接近生产的事务和 Crash Recovery 测试确认实际行为。

Persist Binlog Into Redo V2

Binlog in Redo V2:传统提交路径、前台 Redo 提交、后台 Binlog 持久化、适用条件与崩溃恢复

对于符合条件的提交,Binlog 事件会随 InnoDB Redo 一起持久化。后台写入和同步线程随后将事件写入 Binlog 文件;发生崩溃后,恢复流程可以从 Redo 补齐缺失的 Binlog 尾部,再继续常规恢复。

启用前配置必要的提交顺序设置:

[mysqld]
sync_binlog=1
innodb_flush_log_at_trx_commit=1
binlog_order_commits=OFF
replica_preserve_commit_order=OFF
persist_binlog_to_redo=ON

当前实现要求 sync_binlog=1binlog_order_commits=OFFreplica_preserve_commit_order=OFF。建议同时设置 innodb_flush_log_at_trx_commit=1,但代码并不强制要求。

例如,事务使用非事务表、包含 Statement Binlog Cache、超过 persist_binlog_to_redo_size_limit、需要保持提交顺序,或存在不支持的 2PC 参与者时,都会使用标准 Binlog Group Commit。

变量默认值说明
persist_binlog_to_redoOFF全局、动态启用
persist_binlog_to_redo_size_limit1 MiB符合条件的事务缓存最大值;0–10 MiB
binlog_buffer_size20 MiB只读后台环形缓冲区;启动时配置
sync_binlog_interval50000 µs后台 Binlog 同步间隔
wait_binlog_flushON等待对应文件写入,不一定等待文件同步

Binlog Cache Free Flush

当大事务缓存溢出到临时文件时,标准 Binlog 提交流程会把该文件复制到 Binlog。Free Flush 会在临时文件中预留 Binlog 文件头空间,完成文件后将其重命名为下一个 Binlog 文件,从而避免再次复制大量数据。

仅当 Binlog 和 InnoDB 是已注册的 2PC 参与者时,才能使用该机制:

SET GLOBAL binlog_cache_free_flush_limit_size = 268435456;
SET GLOBAL binlog_cache_free_flush = ON;

仅开启配置不能证明事务实际使用了 Free Flush。事务还必须满足以下条件:缓存已溢出且写入完成,不含 Statement Cache 事件或故障,Binlog 和缓存文件未加密,Binlog 已打开,不更新 mysql.gtid_executed,并且除 InnoDB 外没有注册其他两阶段提交(2PC)引擎。

变量默认值文档记录的范围
binlog_cache_free_flushOFFONOFF
binlog_cache_free_flush_limit_size256 MiB10 MiB 到 ULLONG_MAX 字节
DuckDB 对两种机制的限制不同

Binlog in Redo 可以在 duckdb_mode=NONE 时运行;但只要构建中注册了 DuckDB 这一 2PC 参与者,即使 DuckDB 模式为 NONE,Free Flush 当前仍会使用标准 Binlog Group Commit。

验证清单

  1. 服务启动后检查实际的持久化和提交顺序变量。
  2. 分别执行符合条件和不符合条件的事务,确认优化路径与回退路径均符合预期。
  3. 同时测量 Redo 压力、Binlog 写延迟、存储带宽和提交延迟。
  4. 测试配置大小阈值两侧的事务。
  5. 加入崩溃注入、重启恢复、复制追赶、备份和恢复测试。
  6. 保留标准 Binlog Group Commit 作为回退方式;后台写入仍会产生底层 I/O。

参考来源