Aurora MySQL database engine updates 2021-05-25 (version 2.10.0) (Deprecation scheduled for April 3, 2023)

CVE-2021-23841

CVE-2021-3449

CVE-2020-28196

CVE-2020-14790

CVE-2020-14776

CVE-2020-14567

CVE-2020-14559

CVE-2020-14553

CVE-2020-14547

CVE-2020-14540

CVE-2020-14539

CVE-2018-3251

CVE-2018-3156

CVE-2018-3143

CVE-2016-5440

The db.t3.large instance class is now supported for Aurora MySQL.

Binary log replication:

Improved reader instance availability:

Improved the performance of the read ahead page reads requested by logical read ahead (LRA) technique. This was done by batching the multiple page reads in a single request sent to Aurora storage. As a result, the queries that use the LRA optimization execute up to 3x faster.

Zero-downtime restarts and patching:

Improvements for faster startup when the database has a large number of temporary indexes and tables created during a prior interrupted DDL activity.

Fixed multiple issues related to repeated restarts during the crash recovery of interrupted DDL operations, such as DROP TRIGGER, ALTER TABLE, and specifically ALTER TABLE that modifies the type of partitioning or number of partitions in a table.

Fixed an issue that could cause a server restart during Database Activity Streams (DAS) log processing.

Fixed an issue printing an error message while processing an ALTER query on system tables.

Fixed an issue where the query cache could return stale results on a reader instance.

Fixed an issue where some Aurora commit metrics were not being updated when the system variable innodb_flush_log_at_trx_commit was set to 0 or 2.

Fixed an issue where a query result stored in the query cache was not refreshed by multistatement transactions.

Fixed an issue that could cause the last-modified timestamp of binary log files to not be updated correctly. This could lead to binary log files being purged prematurely, before reaching the customer-configured retention period.

Fixed incorrect reported binlog file name and position from InnoDB after crash recovery.

Fixed an issue that could cause large transactions to generate incorrect binlog events if the binlog_checksum parameter was set to NONE.

Fixed an issue that caused a binlog replica to stop with an error if the replicated transaction contained a DDL statement and a large number of row changes.

Fixed an issue leading to a restart in a reader instance when dropping a table.

Fixed an issue that caused open source connectors to fail when attempting to consume a binlog file with a large transaction.

Fixed an issue that could lead to incorrect query results on the large geometry column after creating a spatial index on the table with the large geometry values.

The database now recreates the temporary tablespace during restart, which allows the associated storage space to be freed and reclaimed.

Fixed an issue that prevented performance_schema tables from being truncated on Aurora reader instances.

Fixed an issue that caused a binlog replica to stop with an HA_ERR_KEY_NOT_FOUND error.

Fixed an issue that caused the database to restart when running FLUSH TABLES WITH READ LOCK statement.

Fixed an issue that prevented the use of user-level lock functions on Aurora reader instances.

Interleaved transactions could sometimes deadlock the replica applier when the transaction isolation level was set to REPEATABLE READ. (Bug #25040331)

When a stored procedure contained a statement referring to a view which in turn referred to another view, the procedure could not be invoked successfully more than once. (Bug #87858, Bug #26864199)

For queries with many OR conditions, the optimizer now is more memory-efficient and less likely to exceed the memory limit imposed by the range_optimizer_max_mem_size system variable. In addition, the default value for that variable has been raised from 1,536,000 to 8,388,608. (Bug #79450, Bug #22283790)

Replication: In the next_event() function, which is called by a replica's SQL thread to read the next event from the relay log, the SQL thread did not release the relaylog.log_lock it acquired when it ran into an error (for example, due to a closed relay log), causing all other threads waiting to acquire a lock on the relay log to hang. With this fix, the lock is released before the SQL thread leaves the function under the situation. (Bug #21697821)

Fixing a memory corruption for ALTER TABLE with virtual column. (Bug #24961167; Bug #24960450)

Replication: Multithreaded replicas could not be configured with small queue sizes using slave_pending_jobs_size_max if they ever needed to process transactions larger than that size. Any packet larger than slave_pending_jobs_size_max was rejected with the error ER_MTS_EVENT_BIGGER_PENDING_JOBS_SIZE_MAX, even if the packet was smaller than the limit set by slave_max_allowed_packet. With this fix, slave_pending_jobs_size_max becomes a soft limit rather than a hard limit. If the size of a packet exceeds slave_pending_jobs_size_max but is less than slave_max_allowed_packet, the transaction is held until all the replica workers have empty queues, and then processed. All subsequent transactions are held until the large transaction has been completed. The queue size for replica workers can therefore be limited while still allowing occasional larger transactions. (Bug #21280753, Bug #77406)

Replication: When using a multithreaded replica, applier errors displayed worker ID data that was inconsistent with data externalized in Performance Schema replication tables. (Bug #25231367)

Replication: On a GTID-based replication replica running with -gtid-mode=ON, -log-bin=OFF, and using -slave-skip-errors, when an error was encountered that should be ignored Exec_Master_Log_Pos was not being correctly updated, causing Exec_Master_Log_Pos to loose synchrony with Read_master_log_pos. If a GTID_NEXT was not specified, the replica would never update its GTID state when rolling back from a single statement transaction. The Exec_Master_Log_Pos would not be updated because even though the transaction was finished, its GTID state would show otherwise. The fix removes the restraint of updating the GTID state when a transaction is rolled back only if GTID_NEXT is specified. (Bug #22268777)

Replication: A partially failed statement was not correctly consuming an auto-generated or specified GTID when binary logging was disabled. The fix ensures that a partially failed DROP TABLE, a partially failed DROP USER, or a partially failed DROP VIEW consume respectively the relevant GTID and save it into @@GLOBAL.GTID_EXECUTED and mysql.gtid_executed table when binary logging is disabled. (Bug #21686749)

Replication: Replicas running MySQL 5.7 could not connect to a MySQL 5.5 source due to an error retrieving the server_uuid, which is not part of MySQL 5.5. This was caused by changes in the method of retrieving the server_uuid. (Bug #22748612)

Replication: The GTID transaction skipping mechanism that silently skips a GTID transaction that was previously executed did not work properly for XA transactions. (Bug #25041920)

">XA ROLLBACK statements that failed because an incorrect transaction ID was given, could be recorded in the binary log with the correct transaction ID, and could therefore be actioned by replication replicas. A check is now made for the error situation before binary logging takes place, and failed XA ROLLBACK statements are not logged. (Bug #26618925)

Replication: If a replica was set up using a CHANGE MASTER TO statement that did not specify the source log file name and source log position, then shut down before START SLAVE was issued, then restarted with the option -relay-log-recovery set, replication did not start. This happened because the receiver thread had not been started before relay log recovery was attempted, so no log rotation event was available in the relay log to provide the source log file name and source log position. In this situation, the replica now skips relay log recovery and logs a warning, then proceeds to start replication. (Bug #28996606, Bug #93397)

Replication: In row-based replication, a message that incorrectly displayed field lengths was returned when replicating from a table with a utf8mb3 column to a table of the same definition where the column was defined with a utf8mb4 character set. (Bug #25135304, Bug #83918)

Replication: When a RESET SLAVE statement was issued on a replication replica with GTIDs in use, the existing relay log files were purged, but the replacement new relay log file was generated before the set of received GTIDs for the channel had been cleared. The former GTID set was therefore written to the new relay log file as the PREVIOUS_GTIDS event, causing a fatal error in replication stating that the replica had more GTIDs than the source, even though the gtid_executed set for both servers was empty. Now, when RESET SLAVE is issued, the set of received GTIDs is cleared before the new relay log file is generated, so that this situation does not occur. (Bug #27411175)

Replication: With GTIDs in use for replication, transactions including statements that caused a parsing error (ER_PARSE_ERROR) could not be skipped manually by the recommended method of injecting an empty or replacement transaction with the same GTID. This action should result in the replica identifying the GTID as already used, and therefore skipping the unwanted transaction that shared its GTID. However, in the case of a parsing error, because the statement was parsed before the GTID was checked to see if it needed to be skipped, the replication applier thread stopped due to the parsing error, even though the intention was for the transaction to be skipped anyway. With this fix, the replication applier thread now ignores parsing errors if the transaction concerned needs to be skipped because the GTID was already used. Note that this behavior change does not apply in the case of workloads consisting of binary log output produced by mysqlbinlog. In that situation, there would be a risk that a transaction with a parsing error that immediately follows a skipped transaction would also be silently skipped, when it ought to raise an error. (Bug #27638268)

Replication: Enable the SQL thread to GTID skip a partial transaction. (Bug #25800025)

Replication: When a negative or fractional timeout parameter was supplied to WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS(), the server behaved in unexpected ways. With this fix:

Replication: If the WAIT_FOR_EXECUTED_GTID_SET() function was used with a timeout value including a fractional part (for example, 1.5), an error in the casting logic meant that the timeout was rounded down to the nearest whole second, and to zero for values less than 1 second (for example, 0.1). The casting logic has now been corrected so that the timeout value is applied as originally specified with no rounding. Thanks to Dirkjan Bussink for the contribution. (Bug #29324564, Bug #94247)

With GTIDs enabled, XA COMMIT on a disconnected XA transaction within a multiple-statement transaction raised an assertion. (Bug #22173903)

Replication: An assertion was raised in debug builds if an XA ROLLBACK statement was issued for an unknown transaction identifier when the gtid_next value had been set manually. The server now does not attempt to update the GTID state if an XA ROLLBACK statement fails with an error. (Bug #27928837, Bug #90640)

Fix wrong sorting order issue when multiple CASE functions are used in ORDER BY clause (Bug#22810883).

Some queries that used ordering could access an uninitialized column during optimization and cause a server exit. (Bug #27389294)

Asynchronous key prefetch (AKP). For more information, see Optimizing Aurora indexed join queries with asynchronous key prefetch in the Amazon Aurora User Guide.

Hash joins. For more information, see Optimizing large Aurora MySQL join queries with hash joins in the Amazon Aurora User Guide.

Native functions for synchronously invoking Amazon Lambda functions. For more information, see Invoking a Lambda function with an Aurora MySQL native function in the Amazon Aurora User Guide.

Scan batching. For more information, see Aurora MySQL database engine updates 2017-12-11 (version 1.16) (Deprecated).

Migrating data from MySQL using an Amazon S3 bucket. For more information, see Migrating data from MySQL by using an Amazon S3 bucket in the Amazon Aurora User Guide.

Group replication plugin

Increased page size

InnoDB buffer pool loading at startup

InnoDB full-text parser plugin

Multisource replication

Online buffer pool resizing

Password validation plugin

Query rewrite plugins

Replication filtering

The CREATE TABLESPACE SQL statement