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 Amazon 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, Amazon Support is available on the community forums and through
Amazon Support
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
toROW
instead ofSTATEMENT
when executingLOAD 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
andbinlog_format
is set toSTATEMENT
.
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_conversionsserver 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.