In a MySQL semi-synchronous replication environment, committing a large transaction often triggers a semi-synchronous timeout due to prolonged Binlog transmission. This downgrades semi-synchronous replication to asynchronous replication, which reduces data reliability. It also blocks subsequent transactions and causes performance fluctuations. To address this issue, RDS for MySQL introduces the real-time binlog transmission feature. This feature streams the Binlog of a large transaction to the replica instance while the transaction is still running. This reduces synchronization time at commit to milliseconds, ensuring high data reliability and stable service performance.
Feature overview
Background
Native MySQL uses a single channel to transmit Binlog between the primary and replica instances. When the Binlog for a large transaction occupies this channel, it blocks the Binlog transmission for all subsequent transactions. This causes a backlog of transactions waiting to commit on the primary instance, making the instance temporarily unwritable. To prevent extended service downtime, MySQL introduces the rpl_semi_sync_master_timeout parameter. If the replica instance fails to acknowledge the Binlog within the specified time, semi-synchronous replication degrades to asynchronous replication. Therefore, large transactions can cause two main issues:
Performance fluctuations: The instance becomes unwritable for several seconds, and many commit requests are logged as slow SQL queries.
Reduced reliability: The replication mode degrades, potentially leading to data loss in extreme cases.
Real-time binlog transmission
In the traditional model, the Binlog for a transaction is buffered in the Binlog Cache on the primary instance during execution. It is written to a Binlog file and sent to the replica instance only when the transaction commits. The real-time binlog transmission feature in RDS for MySQL optimizes this process. For any large transaction that exceeds a defined threshold, the feature continuously streams the generated Binlog Events from the Binlog Cache to the replica instance. The events are temporarily stored in a dedicated Relay Log Cache. When the transaction commits on the primary instance, only a final commit command is sent. The replica instance can then immediately write the cached data to its Relay Log file and return an acknowledgment. This streaming design reduces the Binlog transmission time at commit from seconds to milliseconds, effectively eliminating transmission bottlenecks.
Technical principle: The Relay Log Cache design
To temporarily store the streamed Binlog Events on the replica instance, RDS for MySQL creates a dedicated Relay Log Cache for each large transaction. Before writing data, the system reserves space at the head of the cache to later populate the Relay Log Event's header. This enables a quick conversion from the cache to the Relay Log file. The system intelligently handles cases where the reserved space is insufficient or excessive by either reverting to the original logic or padding with an Empty Event, ensuring the mechanism remains robust.
Applicability
This feature requires one of the following database versions:
MySQL 8.4
MySQL 8.0 with minor engine version 20250531 or later
Instructions
Enable this feature by setting the following global parameters on both the primary and replica instances. The parameter changes take effect immediately without requiring an instance restart.
To enable the feature:
On the primary instance:
loose_binlog_realtime_transmit_source_enabled=ONOn the replica instance:
loose_binlog_realtime_transmit_replica_enabled=ON
Core parameter:
loose_binlog_realtime_transmit_long_transaction_limit_sizePurpose: Specifies the size threshold for a transaction that triggers real-time transmission. When the Binlog generated by a transaction exceeds this size, the feature activates automatically.
Default value: 128 MB.
Benefits
We simulated a high-load scenario by running a 2 GB large transaction on an instance with semi-synchronous replication. The test results are shown in the following figure:
Before optimization (native MySQL): After committing the large transaction, the instance's Queries Per Second (QPS) drops to zero, indicating severe performance fluctuations. Subsequently, the system downgrades to asynchronous mode due to a semi-synchronous timeout. Although performance recovers, data reliability is compromised.
After optimization (RDS for MySQL): With real-time binlog transmission enabled, the instance's QPS remains stable even while committing the large transaction. This effectively prevents performance fluctuations and replication mode downgrades.
