Aurora MySQL database engine updates 2025-05-14 (version 3.09.0, compatible with MySQL 8.0.40)

Optimized minor version upgrade performance through parallel processing of Performance Schema updates, reducing upgrade duration when Performance Schema modifications are required.

Enhanced Aurora MySQL global databases to allow secondary reader instances to complete startup and serve read requests during unplanned events (hardware failures, network disruptions). Previously, secondary reader instances could not restart during such events. For more information, see Cross-Region resiliency for Global Database secondary clusters in the Amazon Aurora User Guide.

Reduced writer downtime during Aurora MySQL Global Database cross-region switchovers to typically under one minute, minimizing downtime during planned regional switches.

CVE-2024-11053

CVE-2024-37371

CVE-2024-7264

CVE-2024-21193

CVE-2024-21194

CVE-2024-21196

CVE-2024-21197

CVE-2024-21198

CVE-2024-21199

CVE-2024-21201

CVE-2024-21203

CVE-2024-21207

CVE-2024-21212

CVE-2024-21213

CVE-2024-21218

CVE-2024-21219

CVE-2024-21230

CVE-2024-21236

CVE-2024-21238

CVE-2024-21239

CVE-2024-21241

CVE-2025-21494

CVE-2025-21504

CVE-2025-21525

CVE-2025-21534

CVE-2025-21536

Fixed an issue where multi-statement queries forwarded from reader to writer instances could hang when innodb_flush_log_at_trx_commit is set to 0 on the writer and non-zero on the reader, preventing potential write forwarding failures.

Fixed a deadlock issue with Enhanced Binlog enabled that could cause database reboots when running SHOW BINARY LOGS concurrent with either committing transactions to BLACKHOLE engines or executing XA PREPARE statements, preventing potential stuck writes and instance availability issues.

Fixed race conditions in write forwarding that could cause Aurora writer instance restarts by preventing new requests from being accepted before previous requests are fully completed, improving the stability of write forwarding operations.

Fixed an issue on the replica where a network interruption may not correctly re-establish connection with the writer causing replication to be stuck and potential instance restarts.

Aurora MySQL Out of Memory (OOM) response now implements phased buffer pool resizing that gradually reduces memory usage based on system memory state (LOW/RESERVED) when enabled through aurora_oom_response DB parameter, providing better memory management during memory pressure situations.

Improved the Binlog file recovery time during database restarts by optimizing the recovery process to take constant time regardless of Binlog file size. Previously, in some cases, recovery time would be proportional to the size of the last Binlog file.

Fixed an issue that could cause unexpected MySQL server restarts when executing concurrent InnoDB table truncation operations while querying performance_schema.data_lock_waits.

Fixed an issue that can cause a database instance to restart when committing large binlog events during low storage conditions.

Fixed an issue where buffer pool resize operations triggered during Out of Memory (OOM) avoidance could become unresponsive during high-workload scenarios, leading to a possible database restart.

Fixed an issue that can cause a database restart loop when creating a trigger. The issue can also occur when a new Binlog or a Relaylog file is added or these files rotate.

Fixed an issue that could cause Aurora reader instance restarts when using write forwarding with multi-statement or implicit commit queries.

Fixed an issue where ALTER TABLE ... REBUILD / OPTIMIZE TABLE operations could consume excessive memory by allocating innodb_ddl_buffer_size bytes per DDL thread instead of dividing the buffer size among threads, preventing potential memory over utilization during DDL operations.

Changed the default value for aurora_oom_response, on all DB instance classes that have more than 4 GiB of memory, from print to print,decline,kill_connect. For more information, see Amazon Aurora MySQL out-of-memory issues in the Amazon Aurora User Guide.

The following privileges have been added to the rds_superuser_role: FLUSH_OPTIMIZER_COSTS, FLUSH_STATUS, FLUSH_TABLES, FLUSH_USER_RESOURCES. For information about the rds_superuser_role, see the Amazon Master User Accounts with Amazon Aurora documentation. For more information on these dynamic privileges, please see the MySQL documentation.

Fast insert optimization is no longer enabled starting this Aurora MySQL version. For more information, see Amazon Aurora MySQL performance enhancements in the Amazon Aurora User Guide.

Fixed an issue with an incorrect breach of the max_user_connections threshold, resulting in connection errors for some users. This occurs in some edge cases, such as when connections are created and killed almost immediately.

Fixed an audit logging issue that caused high CPU utilization, leading to an unresponsive database server instance.

Fixed a memory management issue when using XA transactions, preventing possible instance restarts when Enhanced Binlog is enabled.

Fixed an issue where query performance would degrade when the optimizer made incorrect cost estimations due to the Bufferpool Index Statistics being updated incorrectly post database server restart.

Fixed an issue that prevented customers from turning off local write-forwarding functionality because of a stuck worker thread.

Fixed an issue that caused the SHOW BINARY LOGS command to take longer to execute on a cluster where Enhanced Binlog is enabled or was previously enabled. This issue could also cause increased commit latency if multiple SHOW BINARY LOGS commands were running concurrently.

Fixed an issue where Zero Downtime Patching (ZDP) could be unsuccessful while attempting to preserve connection, belonging to a user which had been dropped. More information on the DROP USER command, and its affect on active connections can be found in the MySQL documentation.

While large transactions were being received and applied, and a request to stop the replication channel was made using STOP REPLICA, MySQL did not do so properly, and subsequently did not process any channel commands. In addition, the server shutdown process did not complete gracefully, and required either the MySQL process to be killed or the host system to be restarted. (Bug #115966, Bug #37008345)