Binlog in Redo功能在事务提交时将Binlog内容同步写入到Redo Log中，减少对磁盘的同步IO次数，进而提高数据库性能。
前提条件
实例大版本为MySQL 8.0。
实例内核小版本为20200430或以上。
如需升级实例内核小版本，请参见升级内核小版本。
实例的
sync_binlog参数取值为1，binlog_order_commits参数取值为OFF，请参见设置实例参数。实例的数据复制方式配置为异步复制，请参见查询和修改数据复制方式。
背景信息
在MySQL关键业务场景中，为了业务数据的安全，事务提交时必须将对应的Binlog和Redo Log同步落盘，即以下两个参数必须同时设置为1：
sync_binlog = 1;
innodb_flush_log_at_trx_commit = 1;在原生MySQL中，每个事务提交时会对磁盘进行2次同步I/O操作（1次Binlog落盘+1次Redo Log落盘），这影响了事务提交的效率。当使用云盘存储时，同步I/O带来的影响会更明显。
为提升事务提交效率，AliSQL引入了Binlog in Redo功能（通过参数persist_binlog_to_redo=ON开启，默认关闭）。该功能在事务提交时，将Binlog内容与Redo Log合并写入，仅需一次同步I/O完成Redo Log的持久化，Binlog数据也随之落盘。这一设计减少了原生MySQL中Binlog和Redo Log分别落盘所需的两次I/O 操作，显著降低数据库响应延迟并提升吞吐量。
此外，针对高并发场景下GTID分配与释放的锁竞争问题，Binlog in Redo采用 批量处理优化，通过成组提交机制减少锁冲突，进一步保障高并发性能。
Binlog文件的写入由后台线程异步执行，按周期批量追加到文件中，避免了实时fsync带来的文件系统压力，从而提升整体I/O效率。即使数据库发生异常重启，系统也能通过回放Redo Log中的Binlog 数据，自动修复Binlog文件的完整性，确保数据一致性。
Binlog in Redo功能不会改变Binlog的格式，基于Binlog的复制及第三方工具也不会受任何影响。
注意事项
开启Binlog in Redo功能后，高性能本地盘实例如果需要使用物理备份文件恢复到自建数据库，需要使用RDS提供的XtraBackup工具。安装XtraBackup工具请参见工具准备。
参数介绍
persist_binlog_to_redo
Binlog in Redo功能开关。全局系统变量，取值：on或off。修改本参数立刻生效，不需要重启实例。
说明开启本功能除了需要将
persist_binlog_to_redo设置为on，您还需配置binlog_order_commits为off，并将实例的数据复制方式配置为异步复制。设置实例参数请参见设置实例参数。
设置数据复制方式请参见查询和修改数据复制方式。
如果您实例的
sync_binlog参数配置不为1，设置上述参数也不会开启Binlog in Redo功能，建议您使用Binlog Parallel Flush功能来优化实例的性能。sync_binlog_interval
Binlog异步保存的间隔。全局系统变量，当
persist_binlog_to_redo = on时生效。默认值：50，单位：毫秒（ms），通常使用默认值即可。修改本参数立刻生效，不需要重启实例。
性能压力测试
测试环境
应用服务器：阿里云ECS实例
RDS实例规格： 32核、128 GB内存、ESSD云盘
实例类型：高可用系列（数据复制方式为异步复制）
测试用例
使用的Sysbench内置用例如下：
oltp_update_non_index
oltp_write_only
测试结果
oltp_update_non_index
开启Binlog in Redo后，TPS在低并发场景下提升显著，高并发场景下也有明显提升，具有较低的延迟。
oltp_write_only
开启Binlog in Redo后，TPS在低并发和高并发场景下有明显提升，同时具有较低的延迟。
测试总结
oltp_update_non_index只包含单语句事务，事务提交次数多，而oltp_write_only包含多语句事务（2个UPDATE、1个DELETE、1个INSERT），相比oltp_update_non_index事务提交次数较少，所以oltp_update_non_index的性能提升比oltp_write_only更为明显。
在低于64并发时，Binlog in Redo功能可以明显提升性能和降低延迟，对绝大多数的实际使用场景来说效果显著。
在高于256并发时，Binlog in Redo功能具有更高的峰值性能和更低的延迟，可以更好地承接突增流量。