Aurora MySQL: Index DDL Flaw Invalidates Reader Buffer Pool

The Daangn DB team discovered an engine flaw while cleaning up unused indexes during Aurora MySQL operations. While the Writer operates normally, executing index-related DDL such as ALTER INDEX INVISIBLE on Reader nodes causes buffer pool pages to become invalidated as 'stale', leading to a surge in CPU and ReadIOPS.

Root Cause and Behavior Analysis

Aurora uses a storage-disaggregated architecture where Readers update pages via redo logs through their own buffer pools. Generally, metadata-only DDL that does not change the tablespace should preserve the cache. However, this flaw causes all pages of the affected table (including PRIMARY) on the Reader to be marked as stale even for index DDLs that do not change the tablespace, such as CREATE INDEX, DROP INDEX, RENAME INDEX, and ALTER INDEX INVISIBLE.

As a result, although the page count remains the same, the pages are treated as invalid, causing subsequent read requests to re-fetch data from storage and resulting in performance degradation. Since the Writer maintains a stale count of 0, this is a Reader-only issue.

Impact Scope and Mitigation

Investigation by AWS Technical Support confirmed that this is an engine flaw where broad invalidation was unintentionally applied during feature improvements introduced in Aurora MySQL 3.08.0. The fix is scheduled for the Aurora MySQL 3.14 release, and there are currently no plans to backport it to versions prior to 3.14.

The Daangn DB team is using LTS version 3.10.x and must wait for the upgrade to 3.14. Until then, they are applying operational principles that treat index DDL as 'operations that clear the Reader buffer pool,' executing them during low-traffic periods and batching multiple changes into a single ALTER statement to minimize the number of invalidations.