全部文档
当前文档
最近更新时间：2025-12-19 20:08:29
Binlog in Redo功能重构数据库持久化流程，使得事务提交仅需持久化一次 Redo Log，即可同步完成 Binlog 关键信息的持久化。该机制在确保数据一致性与可靠性的同时，显著减少了事务提交过程中的同步 I/O 开销，从而有效提升了数据库整体事务处理性能。
数据库实例内核版本为MySQL 8.0.34；
实例参数innodb_redo_log_capacity取值大于2Gb，参数innodb_log_buffer_size大于32Mb；
在事务的提交过程中有两次存储IO的写操作，第一次是Redo的写操作，将事务的Prepare状态持久化。第二次是Binlog的写操作，将事务的Binlog Events持久化。两次IO操作，保证了Binlog和引擎中数据的一致性。但是在事务的提交过程中，存储IO的写操作是一个比较慢的过程，尤其对于云盘更是如此，两次IO写操作对事务的提交性能有很大的影响。
在如下所示的双1设置下，每个事务提交会对磁盘进行两次I/O操作，虽然Binlog采用了Group Commit的方式合并I/O来提升效率，但两次I/O等待的本质没有改变，影响事务处理的效率，当使用云盘存储时，影响会更明显。
sync_binlog = 1;
innodb_flush_log_at_trx_commit = 1;另一方面，组提交I/O合并的效率是由同时提交的并发事务数量决定的，当并发量不够时，I/O合并的效果也不理想，表现为少量的写操作事务提交时所需要的时间比较久，响应时间较长。
为了提高事务提交效率，KingSQL开发了Binlog in Redo特性，概括来说把 Binlog 转成一种 Redo Type，在事务提交时有序的将Binlog内容同步写入到Redo Log中。在这个架构下，binlog 对于 redo log 来说也是一份“数据”，受到 redo log 的保护；binlog 的刷盘由异步线程完成，事务提交过程中，无需等待 binlog 刷盘。如果发生 crash，根据 redo log 恢复binlog 文件即可。
参数名 | 参数描述 | 是否重启生效 | 默认值 | 取值范围 | 支持版本 |
enable_binlog_in_redo | binlog in redo功能开关，开启不需重启。 | 否 | off | 布尔值，on | off | 8.0.34 |
binlog_in_redo_cache_size | 缓存binlog日志的全局buffer。用于在事务提交时，暂存写入redo和binlog file的日志。 单位：字节（Byte） | 否 | 20MB（20971520） | 长整型，8KB ~ 256MB（8192, 268435456） | 8.0.34 |
binlog_in_redo_sync_interval | 异步线程执行sync binlog的时间间隔。 单位：毫秒（ms） | 否 | 50ms | 长整型，1ms ~ 2000ms（1, 2000） | 8.0.34 |
测试环境
配置项 | 配置信息 |
|---|---|
服务器 | 金山云云主机 |
MySQL实例类型 | 高可用版 |
MySQL实例版本 | 8.0.34 |
MySQL实例规格 | 128 GB内存；500G |
测试工具
SysBench
测试用例
oltp_read_write
oltp_write_only
oltp_insert
测试数据
64 tables、1000000 rows
测试结果
读写场景（oltp_read_write），打开binlog in redo功能，中低并发性能提高1~35%（8-256），高并发性能基本持平（512并发以上）
只写场景（oltp_write_only），中低并发性能提高3~28%（8-256），高并发性能基本持平（512并发以上）
insert场景(oltp_insert)，性能提高3~47%（8-256），高并发提高1~3%(512并发以上)。
测试环境
配置项 | 配置信息 |
|---|---|
服务器 | 金山云云主机 |
MySQL实例类型 | 高可用版 |
MySQL实例版本 | 8.0.34 |
MySQL实例规格 | 16 GB内存；500G |
测试工具
SysBench
测试用例
oltp_read_write
oltp_write_only
oltp_insert
测试数据
64 tables、1000000 rows
测试结果
读写场景（oltp_read_write），打开binlog in redo功能，在云盘环境中，中低并发性能提高5~40%（8-256），高并发性能基本持平（512并发以上）
只写场景（oltp_write_only），中低并发性能提高7~34%（8-256），高并发性能提升（3~6%）
insert场景(oltp_insert)，性能提高7~49%（8-256），高并发基本持平(512以上)。
binlog in redo 功能对性能的提升和延迟的降低都非常显著，但是对于大并发的场景，性能提升效果有限。这是由于大并发下，组提交合并 IO 的作用更加明显，Binlog 提交期间的瓶颈来到了串行化的 write binlog，另外高并发场景下GTID分配与释放的锁竞争问题。对此，可以开启线程池特性，来提高大并发下的性能；
云原生数据库模式下计算节点和存储节点之间的带宽资源变得更加珍贵，而binlog in redo极大节省了事务提交过程中IO使用。
纯净模式