MySQL uses logical replication to ensure data consistency between a primary and a standby instance. After a transaction is committed on the primary instance, its Binlog events are sent to the standby instance to be applied. In this architecture, long-running Data Definition Language (DDL) statements can cause significant replication latency on the standby instance. To address this issue, RDS MySQL introduces a real-time DDL application feature. This feature notifies the standby instance to begin executing a DDL statement concurrently with the primary instance. This parallel execution nearly eliminates DDL-related replication latency and ensures high availability for your instance.
Feature overview
Background
The latency in logical replication consists of two main parts: the transmission time of Binlog events and the transaction replay time on the standby instance. For a DDL operation, which generates only one Gtid_log_event and one Query_log_event, the amount of data transmitted is small. Therefore, the Binlog event transmission time is negligible. The primary cause of DDL replication latency is the long execution time of the DDL statement.
Real-time DDL application in RDS MySQL
The root cause of DDL-related replication latency is that MySQL's architecture requires a DDL statement to be committed on the primary instance before the standby instance can apply it. The most direct solution is to allow the standby instance to execute the DDL statement in parallel with the primary instance, rather than waiting for it.
This is the core principle of the real-time DDL application feature. When a DDL statement begins to execute on the primary instance, it immediately notifies the standby instance to start the same operation. The standby instance executes most of the DDL operation and then waits for the final result from the primary instance. If the operation succeeds on the primary instance, it signals the standby to commit; if it fails, it signals a rollback. As a result, the replication latency caused by the DDL is reduced to the time required for one network transmission plus the DDL commit time. These two steps are extremely fast, typically taking at most tens of milliseconds.
This feature is called Binlog Realtime Replication (BRR).
How it works
The primary instance creates a new type of event called a Brr binlog event and sends it to the standby instance by using the real-time transport feature. This event notifies the standby instance to execute the DDL, achieving concurrent execution on both instances. The Brr binlog event is not recorded in the Binlog or Relay Log, so it does not affect downstream systems that consume binlogs.
The standby instance creates a specified number of Brr worker threads to apply DDL statements in real time. These Brr worker threads operate independently of MySQL's original worker threads.
Supported versions
To use this feature, your instance must meet the following version requirements. If your instance does not meet the requirements, you can upgrade the minor engine version or upgrade the database major version.
MySQL 8.4
MySQL 8.0: minor engine version ≥ 20250731.
Limitations
The real-time transport feature must be enabled.
The supported DDL statement types depend on the minor engine version:
Minor engine version ≥ 20250731: supports Alter Table.
Minor engine version ≥ 20251031: supports Alter Table and Optimize Table.
Procedure
To enable this feature, configure instance parameters on both the primary and standby instances. The parameter changes take effect immediately without requiring an instance restart.
Primary instance parameters:
loose_binlog_realtime_apply_ddl_source_enabled = ONloose_binlog_realtime_ddl_time_limit = N(whereNis an integer greater than or equal to 0. The BRR feature is triggered for DDL statements with an execution time longer than this value. This parameter is measured in milliseconds, and the default value is 1000.)
Standby instance parameters:
loose_binlog_realtime_apply_workers = N(whereNis an integer greater than or equal to 1. This parameter specifies the number of Brr worker threads.)
Optimization results
This test uses a 23 GB table with 80,000,000 rows. A table rebuild operation (alter table sbtest1 engine=innodb) is then performed on this table.
The optimization results are shown in the figure below. The primary instance executed the DDL statement at 16:21:35 and 16:32:50. Without BRR enabled, the standby instance experienced a sustained replication latency of 277 s. With BRR enabled, replication latency was eliminated.
The minor engine version of the test instance was 20251031.
