Aurora MySQL database engine updates 2026-08-27 (version 3.13.0, compatible with MySQL 8.0.45)

Version: 3.13.0

Aurora MySQL 3.13.0 is now generally available and is compatible with MySQL 8.0.45. For more information about the community changes, see MySQL 8.0 Release Notes on the MySQL website.

For details of the new features in Aurora MySQL version 3, see Aurora MySQL version 3 compatible with MySQL 8.0.

For differences between Aurora MySQL version 3 and Aurora MySQL version 2, see Comparison of Aurora MySQL version 2 and Aurora MySQL version 3.

For a comparison of Aurora MySQL version 3 and MySQL 8.0 Community Edition, see Comparison of Aurora MySQL version 3 and MySQL 8.0 Community Edition in the Amazon Aurora User Guide.

You can upgrade from any currently supported Aurora MySQL version 2 cluster to an Aurora MySQL version 3.13.0 cluster in one of three ways: perform an in-place upgrade using Zero Downtime Patching (ZDP), restore a snapshot, or initiate a managed blue/green upgrade using Amazon RDS Blue/Green Deployments.

For information about planning an upgrade to Aurora MySQL version 3, see Planning a major version upgrade for an Aurora MySQL cluster. For general upgrade information, see Upgrading Aurora MySQL DB clusters in the Amazon Aurora User Guide.

For troubleshooting information, see Troubleshooting for Aurora MySQL in-place upgrade in the Amazon Aurora User Guide.

If you have any questions or concerns, Support is available on the community forums and through Support. For more information, see Maintaining an Aurora DB cluster in the Amazon Aurora User Guide.

Improvements

Security fixes

This release includes fixes for the following high severity CVEs:

• CVE-2026-46863

This release includes fixes for the following medium severity CVEs:

• CVE-2026-21936

• CVE-2026-21937

• CVE-2026-21941

• CVE-2026-21948

• CVE-2026-21968

Availability improvements

• Fixed an issue which can cause a database instance restart when executing ALTER TABLE ... REORGANIZE PARTITION, DROP PARTITION, or ADD PARTITION while concurrent operations (such as performance schema queries, full-text search optimization or statistics collection) are accessing the same table.

• Fixed an issue which can cause a database instance restart when queries on performance_schema.data_lock_waits or performance_schema.data_locks run concurrently with ALTER TABLE ... REORGANIZE PARTITION on tables that have columns added using ALGORITHM=INSTANT.

• Fixed an issue which can cause the writer instance to restart while processing an ALTER TABLE ... REORGANIZE PARTITION SQL statement that changes sub-partition order.

• Fixed an issue where DDL operations on the writer instance could block or kill certain SQL statements on reader instances. Affected statements included write operations such as UPDATE or TRUNCATE on performance_schema tables, and write operations on temporary tables and JOIN operations.

• Fixed an issue where the database writer instance could restart unexpectedly during a global database switchover operation while cleaning up temporary tables after SQL statement processing. This restart could result in longer switchover completion time.

• Fixed an issue that could cause new database cluster creation to fail, requiring the cluster to be deleted and recreated.

• Fixed an issue in the out-of-memory (OOM) avoidance mechanism that could cause a database instance restart while attempting to recover memory under critical memory pressure.

• Fixed an issue which could cause the writer instance to repeatedly restart when the writer instance restarts while purging an undo record for a table with indexes on virtual columns.

• Fixed an issue which could cause read replicas to restart when the writer instance commits a large transaction with binlog enabled. This issue could also cause errors when reading the binlog file containing the large transaction.

• Fixed an issue where a delay in InnoDB buffer pool resizing during Aurora serverless scaling operations could cause the database instance to become unresponsive and restart.

• Fixed an issue where a reader instance could restart repeatedly after being restarted while the writer instance was performing a forceful purge of undo logs.

• Fixed an issue that could cause a writer DB instance to restart when a reader DB instance restarts while local or global write forwarding is enabled.

• Fixed an issue which can cause an unexpected database restart on reader instances when subqueries utilizing Parallel Query requests were not correctly closed on completion.

• Fixed an issue where a replica instance might restart when executing binary protocol prepared statements that are forwarded to the writer through write forwarding.

• Fixed an issue which can cause the writer instance to restart due to an internal timing conflict during highly concurrent write operations.

• Fixed an issue that could cause a database instance to restart when enhanced binlog is enabled.

• Fixed a bug that could make the replica briefly disconnect and reconnect to the writer, causing a temporary spike in replication lag (AuroraReplicaLag).

• Fixed an issue in the Aurora Storage Daemon that in rare cases could result in an unexpected database restart.

• Improved the performance of Aurora physical replication by applying changes from the writer instance on reader instances using multiple threads.

General improvements

• Fixed an issue where, with write forwarding enabled, a reader session with aurora_replica_read_consistency set to global could fail to read the latest committed changes.

• Fixed an issue which could cause engine restart when a spatial GIS query uses a Z-order spatial index on a column declared with an explicit SRID annotation.

• Fixed an issue where graceful reader disconnections could incorrectly increment Aborted_clients on the writer instance when write forwarding is enabled.

• Fixed an infrequent issue that could cause the database instance to restart when ongoing SQL statements read from temporary tables during buffer pool resize or page eviction operations.

• Fixed commit ordering on binlog replicas with Enhanced Binlog enabled to correctly honor the replica_preserve_commit_order setting. This ordering behavior did not affect data integrity or cause conflicts between transactions, as it applied only to the sequencing of non-dependent transactions.

• Fixed an issue which can cause query results to be returned in ascending order instead of the requested descending order when using ORDER BY DESC with a range comparison and LIMIT.

• Fixed a cluster availability issue that could occur during database server upgrades when DML operations on system tables referenced stale auto-increment values.

• Fixed an issue which could cause replication errors when processing binlog events larger than the aurora_in_memory_relaylog fixed cache size (128 MB).

• Fixed an issue where the reader reports ERROR 1146 (table not found) during certain online DDL operations on the writer when using the INPLACE algorithm.

• Fixed an issue which can cause delayed instance availability during zero-downtime patching (ZDP) or zero-downtime restart (ZDR) operations.

• Fixed an issue where in some cases connection state is not preserved following a zero-downtime upgrade, which could result in unexpected behavior.

• Fixed an issue where, during write forwarding, a reader instance restart could leave an orphan forwarding session on the writer instance, and killing that session could cause the writer to restart.

Upgrades and migrations

• Fixed an issue that could cause database cluster clone operations to take an extended time to complete.

Integration of MySQL Community Edition bug fixes

This release includes all community bug fixes up to and including 8.0.45. For more information, see MySQL bugs fixed by Aurora MySQL 3.x database engine updates.

• Fixed a regression introduced in MySQL 8.0.42 where inserting into a partitioned table using a prepared statement or stored procedure could fail with ERROR 1748 ("Found a row not matching the given partition set"). This occurred when the partition key column uses DEFAULT CURRENT_TIMESTAMP. Partition pruning at prepare time locked a partition based on the current timestamp, but on subsequent re-execution the timestamp could map to a different partition. Reference: MySQL upstream Bug#119784.