Under high write load, every transaction commit triggers a sequential binary log write — parsing cache events, assigning Checksum and log_pos values, and generating global transaction identifier (GTID) events one at a time. This sequential bottleneck limits write throughput on busy instances. AliSQL's Binlog Parallel Flush optimization moves these operations into a parallel pipeline, improving write performance by 10–30% compared with native MySQL. You can enable or disable the feature with a single parameter change — no restart required.
Prerequisites
Before you begin, ensure that:
Your instance runs MySQL 8.0 with minor engine version 20230930 or later
The
sync_binlogparameter is not set to 1
To check the minor engine version, log in to the ApsaraDB RDS console and go to the Basic Information page. In the Configuration Information section, check whether the Upgrade Minor Engine Version button is displayed. If it is, click it to view or update the version. If it is not, your instance is already on the latest minor engine version. For details, see Update the minor engine version.
How it works
In standard MySQL, each transaction commit requires a sequential write to the binary log. Before writing, the system parses all binary log cache events, assigns values to the Checksum and log_pos parameters, and generates GTID events. Because only one transaction is processed at a time, this becomes a significant bottleneck under high write load.
AliSQL addresses this by introducing a binary log buffer and running these operations in parallel across multiple threads.
Binary log buffer
Multiple threads write binary log events to a shared binary log buffer in parallel. A backend thread then flushes the buffer to binary log files. This shifts the sequential operations — assigning Checksum and log_pos values and generating GTID events — into a parallel pipeline, reducing the time spent on each commit.
Group commit
The optimization preserves group commit semantics. The system allocates GTIDs and binary log buffers for a group of transactions sequentially, writes their binary log events to the buffers in parallel, then commits the entire group after the redo log is stored and the backend thread flushes the buffers to binary log files.
Binary log persistence
A backend thread persists binary log files at regular intervals. The default flush interval is once per second.
Enable Binlog Parallel Flush
Set the loose_binlog_parallel_flush parameter to enable or disable the feature.
| Parameter | Type | Valid values | Restart required |
|---|---|---|---|
loose_binlog_parallel_flush | Global system variable | on, off | No |
The change takes effect immediately.
Performance data
The following results are from Sysbench oltp_update_non_index tests on ApsaraDB RDS for MySQL 8.0 (minor engine version 20230930), using a high-performance parameter template (sync_binlog = 1000, innodb_flush_log_at_trx_commit = 2). The test dataset contains 100 tables with 100,000 rows each.
| CPU and memory | Storage type | Storage capacity |
|---|---|---|
| 16 cores, 32 GB | ESSD PL1 | 1,000 GB |
| 16 cores, 32 GB | SSD | 1,000 GB |
| 64 cores, 128 GB | ESSD PL1 | 1,000 GB |
| 64 cores, 128 GB | SSD | 1,000 GB |
Compared with native MySQL Normal Flush, Binlog Parallel Flush significantly improves the write performance of an RDS instance. The maximum improvement can reach 10% to 30%.