MySQL使用的是逻辑复制，一个事务在主库执行结束后，会发送事务产生的Binlog event到备库应用，进而保证主备的一致性。在这种架构下，对于耗时长的DDL，会导致备库有显著的复制延迟。为解决此问题，RDS MySQL推出了DDL 实时应用功能。该功能可以在主库执行DDL时即通知备库执行DDL，达到主备同时执行DDL的效果，从而基本消除DDL导致的复制延迟，保障实例的高可用。
逻辑复制的延迟主要由两部分构成：Binlog event传输时间 + 备库事务回放时间。对于DDL，仅产生一个Gtid_log_event和一个Query_log_event，传输量少，Binlog event传输时间可以忽略不计，所以DDL复制延迟的主因就是执行DDL的长耗时。 通过上文的分析，可以看到DDL导致复制延迟的根因是MySQL现有架构要求必须在主库提交DDL后，备库才能应用。因此解决这个问题的直观想法就是让备库不用等待主库，而是和主库并行执行DDL。 DDL实时应用功能的核心，也正是如此。在主库开始执行DDL时，即通知备库开始执行DDL；备库在完成DDL的主要工作后，等待主库的执行结果；主库如果执行成功，则通知备库提交DDL，主库如果执行失败，则通知备库回滚DDL。最终如下图所示，DDL导致的复制延迟被减少为通知备库的所需一次网络传输耗时+DDL提交的耗时，此两步耗时极低，一般最高为十毫秒级。 下文用BRR（binlog realtime replication）来指代该功能。 实例版本要求如下，当版本不符合要求时，可以升级升级内核小版本或升级数据库版本。 MySQL 8.4 MySQL 8.0：内核小版本 ≥ 20250731。 需要开启实时传输功能。 支持的DDL语句类型与内核版本相关： 内核小版本 ≥ 20250731：支持 Alter Table。 内核小版本 ≥ 20251031：支持 Alter Table和 Optimize Table。 您可以同时在主库和备库分别设置实例参数来开启该功能。参数修改立即生效，无需重启实例。 主库参数： loose_binlog_realtime_apply_ddl_source_enabled = ON loose_binlog_realtime_ddl_time_limit = N （N为大于等于0的正整数，执行时长超过该值的DDL，才会使用BRR功能，该参数以毫秒为单位，默认值为1000） 备库参数： loose_binlog_realtime_apply_workers = N （N为大于等于1的正整数，此参数代表Brr Worker线程数） 本测试构造包含80000000行记录，大小23G的单表，然后对该表做重建表操作(alter table sbtest1 engine=innodb)。 优化效果如下图所示，主库在16:21:35和16:32:50 执行上述DDL。未开启BRR时，备库有持续277s的复制延迟，开启BRR时，无复制延迟。 该测试实例小版本为20251031。功能简介
背景介绍
RDS MySQL DDL实时应用
技术原理
支持版本
使用限制
使用方法
优化效果
