ApsaraDB RDS:Use binlog cache free flush

Enable the feature

Run the following command to enable binlog cache free flush:

SET GLOBAL loose_binlog_cache_free_flush = on;

The change takes effect immediately. You do not need to restart the instance.

Verify the feature is active

SHOW GLOBAL VARIABLES LIKE 'loose_binlog_cache_free_flush';

Tune the threshold

The loose_binlog_cache_free_flush_limit_size parameter sets the minimum binary log data size that triggers the conversion. The default is 256 MB, meaning only transactions whose binary log data exceeds 256 MB use the free-flush path.

To apply the optimization to smaller transactions, lower the threshold:

SET GLOBAL loose_binlog_cache_free_flush_limit_size = <size-in-bytes>;

Disable the feature

SET GLOBAL loose_binlog_cache_free_flush = off;

Binary log cache

Each session gets its own binary log cache—a combination of in-memory space (bounded by binlog_cache_size) and temporary files on disk. When a transaction's events overflow the in-memory limit, they spill into a temporary file.

At commit time, the engine reads every event from the cache, updates the end position and checksum, and writes them to the binary log file under a write lock. The lock ensures events are written without interruption, but it blocks other transactions for the entire duration of the flush.

Impact of large-transaction binary log writes

When a transaction's binary log cache reaches dozens of GB, flushing it at commit time causes two problems:

• Write requests blocked: The write lock is held for the entire flush, preventing other transactions from writing.

• I/O exhaustion: The large sequential write consumes I/O resources and can make the instance unresponsive.

How binlog cache free flush resolves this

AliSQL optimizes the binary log caching mechanism so that temporary files in the cache can be converted directly into binary log files. Two changes make this possible:

• Reserved header space: When events are written to the temporary file, space is reserved at the beginning for binary log file headers. When the temporary file is converted to a binary log file, that reserved space is filled with the required headers—no separate write is needed.

• Precomputed end positions: Each event calculates its end position based on the size of the reserved space, so positions are already correct after conversion.

What the converted binary log file contains

When a large transaction commits, the reserved space at the beginning of the temporary file is filled with the following data before conversion:

Data	Description
File header	The 4-byte magic number [0xFE 'bin'] that identifies the file as a binary log file
Header events	The format description event and the previous global transaction identifier (GTID) event
Empty event	An ignorable-type event that fills any remaining reserved space
GTID event	The GTID of the committing transaction, generated at commit time

The rest of the file retains the transaction's original events: query events, table map events, row-based events, and XID events.