Long-running DDL statements—such as ALTER TABLE on large tables—can stall a secondary database for hundreds of seconds while it waits for the primary to finish and commit. Binlog real-time replication (BRR) eliminates this delay by having the primary notify the secondary to start executing the DDL statement in parallel, rather than waiting for the commit signal. In benchmark tests on an 80-million-row, 23 GB table, the secondary experienced 277 seconds of replication delay without BRR and zero delay with BRR enabled.
How it works
MySQL uses logical replication: after a transaction commits on the primary database, the resulting binlog event is sent to the secondary for replay. For DDL statements, the binlog payload is small (one Gtid_log_event and one Query_log_event), so transmission time is negligible. The bottleneck is DDL execution time itself—the secondary cannot start until the primary commits.
BRR addresses this at the source. When the primary starts a DDL statement, it immediately sends a Brr binlog event—a new event type introduced by this feature—to the secondary via real-time transmission. The secondary starts executing the DDL in parallel using dedicated Brr Worker threads, which are independent of the standard MySQL Worker threads. Once the secondary completes the bulk of the DDL work, it waits for the outcome from the primary:
-
If the primary succeeds, it signals the secondary to commit.
-
If the primary fails, it signals the secondary to roll back.
The total replication delay is reduced to one network transmission to the secondary database plus the DDL commit time—typically tens of milliseconds.
The Brr binlog event is not written to the binlog or relay log, so it does not affect downstream systems that consume binary logs.
Prerequisites
Before enabling BRR, make sure:
-
The instance runs RDS for MySQL 8.0, minor engine version 20250731 or later. If needed, upgrade the minor engine version or upgrade the database version.
-
The real-time transmission feature is enabled on the instance.
Supported DDL statements
The DDL statements covered by BRR depend on your minor engine version:
| Minor engine version | Supported statements |
|---|---|
| 20250731 or later | ALTER TABLE |
| 20251031 or later | ALTER TABLE and OPTIMIZE TABLE |
Enable BRR
Set the following parameters on both the primary and secondary databases by setting instance parameters. Changes take effect immediately—no instance restart is required.
Primary database
| Parameter | Description | Default |
|---|---|---|
loose_binlog_realtime_apply_ddl_source_enabled |
Set to ON to enable BRR on the primary. |
— |
loose_binlog_realtime_ddl_time_limit |
BRR applies only to DDL statements whose execution time exceeds this threshold (in milliseconds). N is an integer greater than or equal to 0. | 1000 |
Secondary database
| Parameter | Description | Default |
|---|---|---|
loose_binlog_realtime_apply_workers |
Number of Brr Worker threads on the secondary. Must be an integer greater than or equal to 1. | — |
Benchmark results
The following test used a single table with 80,000,000 records (23 GB) and ran ALTER TABLE sbtest1 ENGINE=InnoDB to rebuild it. The primary executed the DDL at 16:21:35 and again at 16:32:50. The test instance used minor engine version 20251031.
| BRR enabled | Secondary replication delay |
|---|---|
| No | 277 seconds |
| Yes | 0 seconds |
