ApsaraDB RDS:Best practices for RTO optimization in AliSQL

Optimization overview

AliSQL targets six stages of the crash recovery pipeline. Each optimization is independent. Together, they reduce total RTO across the full recovery sequence.

Massive table startup optimization

When an RDS instance contains a large number of tables—such as 1 million tables—tablespace checking during startup consumes significant time and memory. The instance must open and verify every tablespace file before it can serve traffic, which means startup time grows linearly with table count. AliSQL optimizes file scanning, data dictionary reading, and table object construction to reduce both startup time and memory usage.

Performance

Buffer pool initialization acceleration

The buffer pool is the core memory structure of InnoDB. When an instance starts after a crash, the buffer pool is empty—all data must be read from disk until the cache warms up. Initializing a large buffer pool takes additional time: memory must be allocated and management structures built. MySQL Community Edition supports parallel initialization, but concurrency bottlenecks in lock structures and global statistics updates limit its effectiveness. AliSQL eliminates these bottlenecks to significantly reduce initialization time.

Performance

Parallel redo log application

Redo logs are the write-ahead logging (WAL) mechanism MySQL uses to ensure data consistency. Redo log scanning and application are the most time-consuming steps in crash recovery. MySQL Community Edition processes them on a single thread using serialized application—recovering 4 GB of redo logs can take several minutes. AliSQL introduces a pipeline mechanism that parallelizes both scanning and application, dramatically improving throughput.

Performance

SHOW GLOBAL VARIABLES LIKE 'innodb_parallel_redo_threads';

Fast transaction recovery

After redo logs are applied, MySQL uses undo logs to recover table locks for active transactions. MySQL Community Edition scans all undo log records row by row to identify which tables each transaction holds locks on. For transactions with millions of records, this scan adds significant delay before the instance can accept connections. AliSQL extends the undo log record structure to enable fast locating and scanning, reducing recovery time to near zero even for large transactions.

Performance

SHOW GLOBAL VARIABLES LIKE 'innodb_trx_resurrect_table_lock_accelerate';

Asynchronous transaction rollback

MySQL uses internal XA transactions to keep binary logs and InnoDB consistent. During crash recovery, transactions in the prepared state—where InnoDB completed its prepare phase but the commit was not written to the binary log—must be rolled back. In MySQL Community Edition, this rollback is synchronous: the instance blocks until all rollbacks complete before accepting connections. For large transactions with millions of records, this significantly delays restart. AliSQL moves uncommitted transaction rollback to the background. The instance becomes available immediately after crash recovery, and rollback continues without blocking service.

Performance

Optimization of General Query Log recovery

In TABLE mode, the MySQL General Query Log records user operations in a CSV table. If this table is corrupted at startup, MySQL Community Edition performs a full table scan to locate and rebuild the corrupted data. For a 10 GB log table, this scan takes over four minutes and delays instance availability. AliSQL uses reverse scanning and file truncation to quickly locate and repair the corruption, reducing recovery time to near zero.

Performance

Other optimizations

AliSQL also optimizes the process of verifying data in the doublewrite buffer. Update the minor engine version to the latest version to get all available optimizations.