Aurora MySQL database engine updates 2023-10-25 (version 3.05.0, compatible with MySQL 8.0.32)

Added support for saving data from an Aurora MySQL database cluster into text files in an Amazon S3 bucket encrypted with a KMS key (SSE-KMS). For more information, see Saving data from an Amazon Aurora MySQL DB cluster into text files in an Amazon S3 bucket.

Introduced a new global status variable aurora_tmz_version to denote the current version of the time zone (TZ) information used by the engine. The values follow the IANA time zone database version and are formatted as "YYYYsuffix", for example, 2022a and 2023c. For more information, see Aurora MySQL global status variables.

CVE-2022-37434

Fixed an issue where Aurora MySQL database instances using parallel query may experience a database restart when running a high number of concurrent parallel queries.

Fixed an issue with lock contention caused by an audit logging thread eventually leading to high CPU utilization and client application timeouts.

Fixed an issue which can cause the executed GTID set to be recovered incorrectly on a binary log (binlog) replica cluster with enhanced binlog enabled when any binlog source has gtid_mode set to ON or ON_PERMISSIVE. This issue may cause the replica cluster's writer instance to restart an additional time during recovery, or lead to incorrect results when querying the executed GTID set.

Fixed a memory management issue that can cause an Aurora MySQL database instance restart or a failover due to a decrease in freeable memory when enhanced binary log is enabled.

Fixed an issue which can cause a database instance restart when attempting to read a database page that belongs to a dropped table.

Fixed an issue which can cause the reader instance to restart when the writer instance grows the database volume to a multiple of 160GB.

Fixed an issue where an Aurora MySQL database instance with the enhanced binary log feature enabled might get stuck during the database instance startup as the binary log recovery process is being executed.

Fixed an issue where an Aurora MySQL database instance may experience multiple restarts during instance startup while large rollback segments are initialized.

Fixed an issue during zero downtime patching which causes an instance restart that leads to database connections being unexpectedly closed.

Fixed an issue which can cause a database instance restart due to a deadlatch when running SHOW STATUS and PURGE BINARY LOGS statements concurrently. The purge binary logs is a managed statement that is executed to honor the user configured binlog retention period.

Fixed an issue which can cause database cluster unavailability if the writer instance restarts while the database is creating or dropping triggers on internal system tables.

Fixed an issue which can cause a database instance restart due to a long semaphore wait when using the enhanced binlog feature on a cluster with an Aurora replica.

Fixed an issue which can cause a database instance to restart while executing a query which references an aggregate function.

Fixed an issue which, in rare conditions, can cause the database instance to restart when Aurora Serverless v2 incorrectly attempts to update the table cache while scaling.

Fixed an issue where unsupported index scan access methods were considered for common table expressions (CTE) while materializing intermediate temporary tables, which can lead to undesired behavior including database restarts or incorrect query results. We fixed this issue by avoiding the use of such unsupported index scan access methods on tables using the TempTable storage engine.

Fixed an issue which can cause database unavailability when enhanced binlog is enabled on an Aurora Serverless v2 database cluster running on Aurora MySQL 3.04.0.

Removed unused storage metadata before writing to Aurora storage when the enhanced binlog feature is enabled. This avoids certain scenarios when a database restart or failover may occur because of increased write latency due to increased bytes transmitted over the network.

With the addition of the malloc_stats and malloc_stats_totals tables in the performance_schema, three advanced system variables were added to control the behavior of Jemalloc, an internal memory allocator:

Fixed an issue where Aurora specific performance schema tables were not created upon an upgrade or migration.

Added a new system variable, aurora_use_vector_instructions. When this parameter is enabled, Aurora MySQL uses optimized vector processing instructions to improve performance on I/O heavy workloads. This setting is turned ON by default in Aurora MySQL 3.05 and higher. For more details, see Aurora MySQL configuration parameters.

Fixed an issue which can cause the NumBinaryLogFiles metrics on CloudWatch to display incorrect results when enhanced binlog is enabled.

The request timeout for Aurora MySQL Machine Learning operations to Amazon Sagemaker has been increased from 3 to 30 seconds. This helps resolve an issue where customers may see an increased number of retries or failures for requests to Amazon Sagemaker from Aurora MySQL Machine Learning when using larger batch sizes.

Added support for malloc_stats and malloc_stats_totals tables in the performance_schema database.

Updated the FROM keyword in the LOAD DATA FROM S3 command to be optional. For more information, see Loading data into an Amazon Aurora MySQL DB cluster from text files in an Amazon S3 bucket.

Added support for the parameter innodb_aurora_instant_alter_column_allowed, which controls whether the INSTANT algorithm can be used for ALTER COLUMN operations. For more information see Cluster-level parameters.

Fixed an issue which can prevent new client connections from being established to the database when write forwarding is enabled.

Fixed an issue which can cause the modification of the table_open_cache database parameter to not take effect until the database instance is restarted.

Fixed an issue which can cause duplicate key errors for AUTO_INCREMENT columns using descending indices after a snapshot restore, backtrack, or database clone operation.

Fixed an issue involving index scans where an inaccurate result might be returned when executing a SELECT query with the GROUP BY clause and the aurora_parallel_queryparameter turned ON.

Fixed an issue which may cause the depletion of available memory when executing queries against the INFORMATION_SCHEMA INNODB_TABLESPACES table.

Fixed an issue where the reader instance is unable to open a table, with ERROR 1146. This issue occurs when executing certain types of online Data Definition Language (DDL) while the INPLACE algorithm is being used on the writer instance.

Fixed an issue to avoid an instance restart during Aurora Serverless v2 scaling when the internal monitoring process erroneously submits duplicate scaling requests.

Fixed an issue which can cause a database restart when connected binary log (binlog) consumers are using duplicate binlog replication server IDs.

Introduced an in-memory relay log cache for Aurora MySQL managed binary log replicas. This improvement can help achieve up to a 40% increase in binary log replication throughput. This enhancement is enabled automatically when using single-threaded binary log replication or when using multi-threaded replication with GTID auto-positioning enabled.

Upgrading from MySQL 5.7 to MySQL 8.0 with a very large number of tables in a single database caused the server to consume excessive memory. It was found that, during the process of checking whether tables could be upgraded, we fetched all the data dictionary Table objects upfront, processing each and fetching its name, then performed Checking Version Compatibility on the list. Fetching all objects beforehand was not necessary in this case, and contributed greatly to memory consumption. To correct this problem, we now fetch one Table object at a time in such cases, performing any required checks, fetching its name, and releasing the object, before proceeding with the next one. (Bug #34526001)

Improved the performance of major version upgrades from Aurora MySQL version 2 to version 3 by executing tablespace checks in parallel using all available vCPUs on the database instance.

Fixed an issue which can cause higher CPU utilization due to background TLS certificate rotation. (Community Bug Fix #34284186)