Aurora MySQL database engine updates 2020-11-09 (version 1.22.3) (Deprecated) - Amazon Aurora
ImprovementsIntegration of MySQL community edition bug fixes

Aurora MySQL database engine updates 2020-11-09 (version 1.22.3) (Deprecated)

Version: 1.22.3

Aurora MySQL 1.22.3 is generally available. Aurora MySQL 1.* versions are compatible with MySQL 5.6 and Aurora MySQL 2.* versions are compatible with MySQL 5.7.

This engine version is scheduled to be deprecated on February 28, 2023. For more information, see Preparing for Amazon Aurora MySQL-Compatible Edition version 1 end of life.

Currently supported Aurora MySQL releases are 1.19.5, 1.19.6, 1.22.*, 1.23.*, 2.04.*, 2.07.*, 2.08.*, 2.09.*, 2.10.*, 3.01.* and 3.02.*.

To create a cluster with an older version of Aurora MySQL, specify the engine version through the RDS Console, the AWS CLI, or the Amazon RDS API.

Note

This version is designated as a long-term support (LTS) release. For more information, see Aurora MySQL long-term support (LTS) releases in the Amazon Aurora User Guide.

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

Improvements

Security fixes:

Fixes and other enhancements to fine-tune handling in a managed environment. Additional CVE fixes below:

Incompatible changes:

This version introduces a permission change that affects the behavior of the mysqldump command. Users must have the PROCESS privilege to access the INFORMATION_SCHEMA.FILES table. To run the mysqldump command without any changes, grant the PROCESS privilege to the database user that the mysqldump command connects to. You can also run the mysqldump command with the --no-tablespaces option. With that option, the mysqldump output doesn't include any CREATE LOGFILE GROUP or CREATE TABLESPACE statements. In that case, the mysqldump command doesn't access the INFORMATION_SCHEMA.FILES table, and you don't need to grant the PROCESS permission.

Availability improvements:

  • Fixed issues that might cause server restarts during recovery of a DDL statement that was not committed.

  • Fixed race conditions in the lock manager that can cause a server restart.

  • Fixed an issue that might cause the monitoring agent to restart the server during recovery of a large transaction

General improvements:

  • Changed the behavior to map MIXED binlog_format to ROW instead of STATEMENT when executing LOAD DATA FROM INFILE | S3.

  • Fixed an issue where a binlog replica connected to an Aurora MySQL binlog primary might show incomplete data when the primary executed LOAD DATA FROM S3 and binlog_format is set to STATEMENT.

Integration of MySQL community edition bug fixes

  • Bug #26654685: A corrupt index ID encountered during a foreign key check raised an assertion

  • Bug #15831300: By default, when promoting integers from a smaller type on the master to a larger type on the slave (for example, from a SMALLINT column on the master to a BIGINT column on the slave), the promoted values are treated as though they are signed. Now in such cases it is possible to modify or override this behavior using one or both of ALL_SIGNED, ALL_UNSIGNED in the set of values specified for the slave_type_conversions server system variable. For more information, see Row-based replication: attribute promotion and demotion, as well as the description of the variable.

  • Bug #17449901: With foreign_key_checks=0, InnoDB permitted an index required by a foreign key constraint to be dropped, placing the table into an inconsistent and causing the foreign key check that occurs at table load to fail. InnoDB now prevents dropping an index required by a foreign key constraint, even with foreign_key_checks=0. The foreign key constraint must be removed before dropping the foreign key index.

  • BUG #20768847: An ALTER TABLE ... DROP INDEX operation on a table with foreign key dependencies raised an assertion.