# Database engine updates for Amazon Aurora MySQL version 1 (Deprecated)
The following are Amazon Aurora version 1 database engine updates:
+ [Aurora MySQL database engine updates 2021-09-30 (version 1.23.4) (Deprecated)](AuroraMySQL.Updates.1234.md)
+ [Aurora MySQL database engine updates 2021-06-28 (version 1.23.3) (Deprecated)](AuroraMySQL.Updates.1233.md)
+ [Aurora MySQL database engine updates 2021-03-18 (version 1.23.2) (Deprecated)](AuroraMySQL.Updates.1232.md)
+ [Aurora MySQL database engine updates 2020-11-24 (version 1.23.1) (Deprecated)](AuroraMySQL.Updates.1231.md)
+ [Aurora MySQL database engine updates 2020-09-02 (version 1.23.0) (Deprecated)](AuroraMySQL.Updates.1230.md)
+ [Aurora MySQL database engine updates 2021-06-03 (version 1.22.5) (Deprecated)](AuroraMySQL.Updates.1225.md)
+ [Aurora MySQL database engine updates 2021-03-04 (version 1.22.4) (Deprecated)](AuroraMySQL.Updates.1224.md)
+ [Aurora MySQL database engine updates 2020-11-09 (version 1.22.3) (Deprecated)](AuroraMySQL.Updates.1223.md)
+ [Aurora MySQL database engine updates 2020-03-05 (version 1.22.2) (Deprecated)](AuroraMySQL.Updates.1222.md)
+ [Aurora MySQL database engine updates 2019-12-23 (version 1.22.1) (Deprecated)](AuroraMySQL.Updates.1221.md)
+ [Aurora MySQL database engine updates 2019-11-25 (version 1.22.0) (Deprecated)](AuroraMySQL.Updates.1220.md)
+ [Aurora MySQL database engine updates 2019-11-25 (version 1.21.0) (Deprecated)](AuroraMySQL.Updates.1210.md)
+ [Aurora MySQL database engine updates 2020-03-05 (version 1.20.1) (Deprecated)](AuroraMySQL.Updates.1201.md)
+ [Aurora MySQL database engine updates 2019-11-11 (version 1.20.0) (Deprecated)](AuroraMySQL.Updates.1200.md)
+ [Aurora MySQL database engine updates 2020-03-05 (version 1.19.6) (Deprecated)](AuroraMySQL.Updates.1196.md)
+ [Aurora MySQL database engine updates 2019-09-19 (version 1.19.5) (Deprecated)](AuroraMySQL.Updates.1195.md)
+ [Aurora MySQL database engine updates 2019-06-05 (version 1.19.2) (Deprecated)](AuroraMySQL.Updates.1192.md)
+ [Aurora MySQL database engine updates 2019-05-09 (version 1.19.1) (Deprecated)](AuroraMySQL.Updates.1191.md)
+ [Aurora MySQL database engine updates 2019-02-07 (version 1.19.0) (Deprecated)](AuroraMySQL.Updates.1190.md)
+ [Aurora MySQL database engine updates 2018-09-20 (version 1.18.0) (Deprecated)](AuroraMySQL.Updates.1180.md)
+ [Aurora MySQL database engine updates 2020-03-05 (version 1.17.9) (Deprecated)](AuroraMySQL.Updates.1179.md)
+ [Aurora MySQL database engine updates 2019-01-17 (version 1.17.8) (Deprecated)](AuroraMySQL.Updates.1178.md)
+ [Aurora MySQL database engine updates 2018-10-08 (version 1.17.7) (Deprecated)](AuroraMySQL.Updates.1177.md)
+ [Aurora MySQL database engine updates 2018-09-06 (version 1.17.6) (Deprecated)](AuroraMySQL.Updates.1176.md)
+ [Aurora MySQL database engine updates 2018-08-14 (version 1.17.5) (Deprecated)](AuroraMySQL.Updates.1175.md)
+ [Aurora MySQL database engine updates 2018-08-07 (version 1.17.4) (Deprecated)](AuroraMySQL.Updates.1174.md)
+ [Aurora MySQL database engine updates 2018-06-05 (version 1.17.3) (Deprecated)](AuroraMySQL.Updates.1173.md)
+ [Aurora MySQL database engine updates 2018-04-27 (version 1.17.2) (Deprecated)](AuroraMySQL.Updates.1172.md)
+ [Aurora MySQL database engine updates 2018-03-23 (version 1.17.1) (Deprecated)](AuroraMySQL.Updates.1171.md)
+ [Aurora MySQL database engine updates 2018-03-13 (version 1.17) (Deprecated)](AuroraMySQL.Updates.117.md)
+ [Aurora MySQL database engine updates 2017-12-11 (version 1.16) (Deprecated)](AuroraMySQL.Updates.20171211.md)
+ [Aurora MySQL database engine updates 2017-11-20 (version 1.15.1) (Deprecated)](AuroraMySQL.Updates.20171120.md)
+ [Aurora MySQL database engine updates 2017-10-24 (version 1.15) (Deprecated)](AuroraMySQL.Updates.20171024.md)
+ [Aurora MySQL database engine updates: 2018-03-13 (version 1.14.4) (Deprecated)](AuroraMySQL.Updates.1144.md)
+ [Aurora MySQL database engine updates: 2017-09-22 (version 1.14.1) (Deprecated)](AuroraMySQL.Updates.20170922.md)
+ [Aurora MySQL database engine updates: 2017-08-07 (version 1.14) (Deprecated)](AuroraMySQL.Updates.20170807.md)
+ [Aurora MySQL database engine updates: 2017-05-15 (version 1.13) (Deprecated)](AuroraMySQL.Updates.20170515.md)
+ [Aurora MySQL database engine updates: 2017-04-05 (version 1.12) (Deprecated)](AuroraMySQL.Updates.20170405.md)
+ [Aurora MySQL database engine updates: 2017-02-23 (version 1.11) (Deprecated)](AuroraMySQL.Updates.20170223.md)
+ [Aurora MySQL database engine updates: 2017-01-12 (version 1.10.1) (Deprecated)](AuroraMySQL.Updates.20170112.md)
+ [Aurora MySQL database engine updates: 2016-12-14 (version 1.10) (Deprecated)](AuroraMySQL.Updates.20161214.md)
+ [Aurora MySQL database engine updates: 2016-11-10 (versions 1.9.0, 1.9.1) (Deprecated)](AuroraMySQL.Updates.20161110.md)
+ [Aurora MySQL database engine updates: 2016-10-26 (version 1.8.1) (Deprecated)](AuroraMySQL.Updates.20161026.md)
+ [Aurora MySQL database engine updates: 2016-10-18 (version 1.8) (Deprecated)](AuroraMySQL.Updates.20161018.md)
+ [Aurora MySQL database engine updates: 2016-09-20 (version 1.7.1) (Deprecated)](AuroraMySQL.Updates.20160920.md)
+ [Aurora MySQL database engine updates: 2016-08-30 (version 1.7.0) (Deprecated)](AuroraMySQL.Updates.20160830.md)
+ [Aurora MySQL database engine updates: 2016-06-01 (version 1.6.5) (Deprecated)](AuroraMySQL.Updates.20160601.md)
+ [Aurora MySQL database engine updates: 2016-04-06 (version 1.6) (Deprecated)](AuroraMySQL.Updates.20160406.md)
+ [Aurora MySQL database engine updates: 2016-01-11 (version 1.5) (Deprecated)](AuroraMySQL.Updates.20160111.md)
+ [Aurora MySQL database engine updates: 2015-12-03 (version 1.4) (Deprecated)](AuroraMySQL.Updates.20151203.md)
+ [Aurora MySQL database engine updates: 2015-10-16 (versions 1.2, 1.3) (Deprecated)](AuroraMySQL.Updates.20151016.md)
+ [Aurora MySQL database engine updates: 2015-08-24 (version 1.1) (Deprecated)](AuroraMySQL.Updates.20150824.md)
# Aurora MySQL database engine updates 2021-09-30 (version 1.23.4) (Deprecated)
**Version:** 1.23.4
Aurora MySQL 1.23.4 is generally available. Aurora MySQL 2.\$1 versions are compatible with MySQL 5.7 and Aurora MySQL 1.\$1 versions are compatible with MySQL 5.6.
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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).
Currently supported Aurora MySQL releases are 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 and 3.02.\$1.
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.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
## Improvements
**General improvements:**
+ Fixed an issue that can cause high CPU consumption on the reader instances due to excessive logging of informational messages in internal diagnostic log files.
**High-priority fixes:**
+ [CVE-2021-2307](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-2307)
+ [CVE-2021-2226](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-2226)
+ [CVE-2021-2160](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-2160)
+ [CVE-2021-2154](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-2154)
+ [CVE-2021-2060](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-2060)
+ [CVE-2021-2032](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-2032)
+ [CVE-2021-2001](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-2001)
# Aurora MySQL database engine updates 2021-06-28 (version 1.23.3) (Deprecated)
**Version:** 1.23.3
Aurora MySQL 1.23.3 is generally available. Aurora MySQL 1.\$1 versions are compatible with MySQL 5.6 and Aurora MySQL 2.\$1 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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).
Currently supported Aurora MySQL releases are 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 and 3.02.\$1.
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.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
## Improvements
General stability and availability enhancements.
**Security fixes:**
+ [CVE-2021-23841](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-23841)
+ [CVE-2021-3449](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3449)
+ [CVE-2020-28196](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28196)
# Aurora MySQL database engine updates 2021-03-18 (version 1.23.2) (Deprecated)
**Version:** 1.23.2
Aurora MySQL 1.23.2 is generally available. Aurora MySQL 1.\$1 versions are compatible with MySQL 5.6 and Aurora MySQL 2.\$1 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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).
Currently supported Aurora MySQL releases are 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 and 3.02.\$1.
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 currently not available in the following regions: AWS GovCloud (US-East) [us-gov-east-1], AWS GovCloud (US-West) [us-gov-west-1]. There will be a separate announcement once it is made available.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
## Improvements
**High priority fixes:**
+ [CVE-2020-14867](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14867)
+ [CVE-2020-14812](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14812)
+ [CVE-2020-14769](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14769)
+ [CVE-2020-14765](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14765)
+ [CVE-2020-14793](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14793)
+ [CVE-2020-14672](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14672)
+ [CVE-2020-1971](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1971)
+ [CVE-2018-3143](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3143)
**Availability improvements:**
+ Fixed an issue in the dynamic cluster storage resizing feature that could cause reader DB instances to restart.
+ Fixed a failover issue due to a race condition in `RESET QUERY CACHE` statement.
+ Fixed a crash in a nested stored procedure call with query cache.
+ Fixed an issue to prevent repeated restart of `mysqld` when recovering from an incomplete truncation of partitioned or sub-partitioned tables.
+ Fixed an issue that could cause migration from on-prem or RDS for MySQL to Aurora MySQL to not succeed.
+ Fixed a rare race condition where the database can restart during the scaling of the storage volume.
+ Fixed an issue in the lock manager where a race condition can cause a lock to be shared by two transactions, causing the database to restart.
+ Fixed an issue related to transaction lock memory management with long-running write transactions resulting in a database restart.
+ Fixed a race condition in the lock manager that resulted in a database restart or failover during transaction rollback.
+ Fixed an issue during upgrade from 5.6 to 5.7 when the table had Fast Online DDL enabled in lab mode in 5.6.
+ Fixed multiple issues where the engine might restart during zero-downtime patching while checking for a quiesced point in database activity for patching.
+ Fixed multiple issues related to repeated restarts due to 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.
+ Updated the default value of `table_open_cache` on 16XL and 24XL instances to avoid repeated restarts and high CPU utilization on large instances classes (R4/R5-16XL, R5-12XL, R5-24XL). This impacted 1.21.x and 1.22.x releases.
+ Fixed an issue that caused a binlog replica to stop with an `HA_ERR_KEY_NOT_FOUND` error.
## Integration of MySQL community edition bug fixes
+ *Replication*: While a `SHOW BINLOG EVENTS` statement was executing, any parallel transaction was blocked. The fix ensures that the `SHOW BINLOG EVENTS` process now only acquires a lock for the duration of calculating the file's end position, therefore parallel transactions are not blocked for long durations. (Bug \$176618, Bug \$120928790)
# Aurora MySQL database engine updates 2020-11-24 (version 1.23.1) (Deprecated)
**Version:** 1.23.1
Aurora MySQL 1.23.1 is generally available. Aurora MySQL 1.\$1 versions are compatible with MySQL 5.6 and Aurora MySQL 2.\$1 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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).
Currently supported Aurora MySQL releases are 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 and 3.02.\$1.
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.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) 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:
+ [CVE-2020-14559](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14559)
+ [CVE-2020-14539](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14539)
**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 an issue that causes an Aurora reader instance in a global database secondary cluster running 1.23.0 to restart repeatedly.
+ Fixed an issue where a global database secondary Region's replicas might restart when upgraded to release 1.23.0 while the primary Region writer was on an older release version.
+ Fixed a memory leak in dynamic resizing feature, introduced in Aurora MySQL 1.23.0.
+ Fixed an issue that might cause server restart during execution of a query using the parallel query feature.
+ Fixed an issue that might cause a client session to hang when the database engine encounters an error while reading from or writing to the network.
# Aurora MySQL database engine updates 2020-09-02 (version 1.23.0) (Deprecated)
**Version:** 1.23.0
Aurora MySQL 1.23.0 is generally available. Aurora MySQL 1.\$1 versions are compatible with MySQL 5.6 and Aurora MySQL 2.\$1 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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).
Currently supported Aurora MySQL releases are 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 and 3.02.\$1.
You can restore the snapshot of an Aurora MySQL 1.\$1 database into Aurora MySQL 1.23.0.
**Important**
The improvements to Aurora storage in this version limit the available upgrade paths from Aurora MySQL 1.23 to Aurora MySQL 2.\$1. When you upgrade an Aurora MySQL 1.23 cluster to 2.\$1, you must upgrade to Aurora MySQL 2.09.0 or later.
To create a cluster with an older version of Aurora MySQL, please specify the engine version through the RDS Console, the AWS CLI, or the Amazon RDS API.
**Note**
This version is currently not available in the following regions: AWS GovCloud (US-East) [us-gov-east-1], AWS GovCloud (US-West) [us-gov-west-1]. There will be a separate announcement once it is made available.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
## Improvements
**New features:**
+ You can now turn parallel query on or off for an existing cluster by changing the value of the DB cluster parameter `aurora_parallel_query`. You don't need to use the `parallelquery` setting for the `--engine-mode` parameter when creating the cluster.
Parallel query is now expanded to be available in all regions where Aurora MySQL is available.
There are a number of other functionality enhancements and changes to the procedures for upgrading and enabling parallel query in an Aurora cluster. For more information, see [ Working with parallel query for Amazon Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-mysql-parallel-query.html) in the *Amazon Aurora User Guide*.
+ With this release, you can create Amazon Aurora MySQL database instances with up to 128 tebibytes (TiB) of storage. The new storage limit is an increase from the prior 64 TiB. The 128 TiB storage size supports larger databases. This capability is not supported on small instances sizes (db.t2 or db.t3). A single tablespace cannot grow beyond 64 TiB due to [InnoDB limitations with 16 KB page size](https://dev.mysql.com/doc/refman/5.7/en/innodb-limits.html).
Aurora alerts you when the cluster volume size is near 128 TiB, so that you can take action prior to hitting the size limit. The alerts appear in the mysql log and RDS Events in the AWS Management Console.
+ Improved binary log (binlog) processing to reduce crash recovery time and commit time latency when very large transactions are involved.
+ Aurora dynamically resizes your cluster storage space. With dynamic resizing, the storage space for your Aurora DB cluster automatically decreases when you remove data from the DB cluster. For more information, see [ Storage scaling](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Managing.Performance.html#Aurora.Managing.Performance.StorageScaling) in the *Amazon Aurora User Guide*.
**Note**
The dynamic resizing feature is being deployed in phases to the AWS Regions where Aurora is available. Depending on the Region where your cluster is, this feature might not be available yet. For more information, see [the What's New announcement](https://aws.amazon.com/about-aws/whats-new/2020/10/amazon-aurora-enables-dynamic-resizing-database-storage-space/).
**High priority fixes:**
+ [CVE-2019-2911](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2911)
+ [CVE-2019-2537](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2537)
+ [CVE-2018-2787](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2787)
+ [CVE-2018-2784](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2784)
+ [CVE-2018-2645](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2645)
+ [CVE-2018-2640](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2640)
**Availability improvements:**
+ Fixed an issue in the lock manager where a race condition can cause a lock to be shared by two transactions, causing the database to restart.
+ Fixed an issue related to transaction lock memory management with long-running write transactions resulting in a database restart.
+ Fixed a race condition in the lock manager that resulted in a database restart or failover during transaction rollback.
+ Fixed an issue during upgrade from 5.6 to 5.7 when the `innodb_file_format` changed on a table that had Fast DDL enabled.
+ Fixed multiple issues where the engine might restart during zero-downtime patching while checking for a quiesced point in database activity for patching.
+ Fixed an issue related to DDL recovery that impacts restart of the DB instance while recovering an interrupted `DROP TRIGGER` operation.
+ Fixed a bug that might cause unavailability of the database if a crash occurs during the execution of certain partitioning operations. Specifically, an interrupted `ALTER TABLE` operation that modifies the type of partitioning or the number of partitions in a table.
+ Fix default value of `table_open_cache` on 16XL and 24XL instances which could cause repeated failovers and high CPU utilization on large instances classes (R4/R5-16XL, R5-12XL, R5-24XL). This impacted 1.21.x and 1.22.x.
**Global databases:**
+ Populate missing data in the MySQL `INFORMATION_SCHEMA.REPLICA_HOST_STATUS` view on primary and secondary AWS Regions in an Aurora global database.
+ Fixed unexpected query failures that could occur in a Global DB secondary Region due to garbage collection of UNDO records in the primary Region, after temporary network connectivity issues between the primary and secondary Regions.
**Parallel query:**
+ Fixed an issue where parallel query might cause a long-running query to return an empty result.
+ Fixed an issue where a query on a small table on the Aurora read replica might take more than one second.
+ Fixed an issue that might cause a restart when a parallel query and a DML statement are executing concurrently under a heavy workload.
**General improvements:**
+ Fixed an issue where queries using spatial index might return partial results if spatial index was created on tables with already existing large spatial values.
+ Increased maximum allowable length for audit system variables `server_audit_incl_users` and `server_audit_excl_users` from 1024 bytes to 2000 bytes.
+ Fixed an issue where a binlog replica connected to an Aurora MySQL binlog primary might show incomplete data when the Aurora MySQL binlog primary loads data from S3 under `statement` `binlog_format`.
+ Comply with community behavior to map `mixed` binlog\$1format to `row` instead of `statement` for loading data.
+ Fixed an issue causing binlog replication to stop working when the user closes the connection and the session is using temporary tables.
+ Improved response time of a query involving MyISAM temporary tables.
+ Fix permission issue when binlog worker runs a native lambda function.
+ Fixed an issue on Aurora read replicas when trying to query or rotate the slow log or general log.
+ Fixed an issue that broke logical replication when the `binlog_checksum` parameter is set to different values on the master and the replica.
+ Fixed an issue where the read replica might transiently see partial results of a recently committed transaction on the writer.
+ Include transaction info of the rolled-back transaction in `show engine innodb status` when a deadlock is resolved.
## Integration of MySQL community edition bug fixes
+ Binlog events with `ALTER TABLE ADD COLUMN ALGORITHM=QUICK` will be rewritten as `ALGORITHM=DEFAULT` to be compatible with the community edition.
+ BUG \$122350047: IF CLIENT KILLED AFTER ROLLBACK TO SAVEPOINT PREVIOUS STMTS COMMITTED
+ Bug \$129915479: RUNNING COM\$1REGISTER\$1SLAVE WITHOUT COM\$1BINLOG\$1DUMP CAN RESULTS IN SERVER EXIT
+ Bug \$130441969: BUG \$129723340: MYSQL SERVER CRASH AFTER SQL QUERY WITH DATA ?AST
+ Bug \$130628268: OUT OF MEMORY CRASH
+ Bug \$127081349: UNEXPECTED BEHAVIOUR WHEN DELETE WITH SPATIAL FUNCTION
+ Bug \$127230859: UNEXPECTED BEHAVIOUR WHILE HANDLING INVALID POLYGON"
+ Bug \$127081349: UNEXPECTED BEHAVIOUR WHEN DELETE WITH SPATIAL"
+ Bug \$126935001: ALTER TABLE AUTO\$1INCREMENT TRIES TO READ INDEX FROM DISCARDED TABLESPACE
+ Bug \$129770705: SERVER CRASHED WHILE EXECUTING SELECT WITH SPECIFIC WHERE CLAUSE
+ Bug \$127659490: SELECT USING DYNAMIC RANGE AND INDEX MERGE USE TOO MUCH MEMORY(OOM)
+ Bug \$124786290: REPLICATION BREAKS AFTER BUG \$174145 HAPPENS IN MASTER
+ Bug \$127703912: EXCESSIVE MEMORY USAGE WITH MANY PREPARE
+ Bug \$120527363: TRUNCATE TEMPORARY TABLE CRASH: \$1DICT\$1TF2\$1FLAG\$1IS\$1SET(TABLE, DICT\$1TF2\$1TEMPORARY)
+ Bug\$123103937 PS\$1TRUNCATE\$1ALL\$1TABLES() DOES NOT WORK IN SUPER\$1READ\$1ONLY MODE
+ Bug \$125053286: USE VIEW WITH CONDITION IN PROCEDURE CAUSES INCORRECT BEHAVIOR (fixed in 5.6.36)
+ Bug \$125586773: INCORRECT BEHAVIOR FOR CREATE TABLE SELECT IN A LOOP IN SP (fixed in 5.6.39)
+ Bug \$127407480: AUTOMATIC\$1SP\$1PRIVILEGES REQUIRES NEED THE INSERT PRIVILEGES FOR MYSQL.USER TABLE
+ Bug \$126997096: `relay_log_space` value is not updated in a synchronized manner so that its value is sometimes much higher than the actual disk space used by relay logs.
+ Bug\$115831300 SLAVE\$1TYPE\$1CONVERSIONS=ALL\$1NON\$1LOSSY NOT WORKING AS EXPECTED
+ SSL Bug backport Bug \$117087862, Bug \$120551271
+ Bug \$116894092: PERFORMANCE REGRESSION IN 5.6.6\$1 FOR INSERT INTO ... SELECT ... FROM (fixed in 5.6.15).
+ Port a bug fix related to `SLAVE_TYPE_CONVERSIONS`.
# Aurora MySQL database engine updates 2021-06-03 (version 1.22.5) (Deprecated)
**Version:** 1.22.5
Aurora MySQL 1.22.5 is generally available. Aurora MySQL 1.\$1 versions are compatible with MySQL 5.6 and Aurora MySQL 2.\$1 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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).
Currently supported Aurora MySQL releases are 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 and 3.02.\$1.
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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Versions.html#AuroraMySQL.Updates.LTS) 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](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
## Improvements
**Availability improvements:**
+ Resolved an issue that could cause the database to stall, and subsequently restart or fail over due to a concurrency conflict between internal cleanup threads.
+ Resolved an issue that could cause the cluster to become unavailable if the database restarted while holding XA transactions in prepared state, and then restarted again before those transactions were committed or rolled back. Prior to this fix, you can address the issue by restoring the cluster to a point in time before the first restart.
+ Resolved an issue that could cause the InnoDB purge to become blocked if the database restarts while processing a DDL statement. As a result, the InnoDB history list length would grow and the cluster storage volume would keep growing until it fills up, making the database unavailable. Prior to this fix, you can mitigate the issue by restarting the database again to unblock purge.
# Aurora MySQL database engine updates 2021-03-04 (version 1.22.4) (Deprecated)
**Version:** 1.22.4
Aurora MySQL 1.22.4 is generally available. Aurora MySQL 1.\$1 versions are compatible with MySQL 5.6 and Aurora MySQL 2.\$1 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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).
Currently supported Aurora MySQL releases are 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 and 3.02.\$1.
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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Versions.html#AuroraMySQL.Updates.LTS) 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](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) 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:
+ [CVE-2020-14867](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14867)
+ [CVE-2020-14812](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14812)
+ [CVE-2020-14793](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14793)
+ [CVE-2020-14769](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14769)
+ [CVE-2020-14765](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14765)
+ [CVE-2020-14672](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14672)
+ [CVE-2020-1971](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1971)
**Availability improvements:**
+ Fixed an issue that could trigger a database restart or failover during a `kill session` command. If you encounter this issue, contact AWS support to enable this fix on your instance.
+ Improved binary logging to reduce crash recovery time and commit latency when large transactions are involved.
+ Fixed an issue that caused a binlog replica to stop with an `HA_ERR_KEY_NOT_FOUND` error.
# 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.\$1 versions are compatible with MySQL 5.6 and Aurora MySQL 2.\$1 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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).
Currently supported Aurora MySQL releases are 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 and 3.02.\$1.
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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Versions.html#AuroraMySQL.Updates.LTS) 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](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) 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:
+ [CVE-2020-14559](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14559)
+ [CVE-2020-14539](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14539)
+ [CVE-2020-2579](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-2579)
+ [CVE-2020-2812](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-2812)
+ [CVE-2020-2780](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-2780)
+ [CVE-2020-2763](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-2763)
**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 \$126654685: A corrupt index ID encountered during a foreign key check raised an assertion
+ Bug \$115831300: By default, when promoting integers from a smaller type on the master to a larger type on the slave (for example, from a [SMALLINT](https://dev.mysql.com/doc/refman/5.6/en/integer-types.html) column on the master to a [BIGINT](https://dev.mysql.com/doc/refman/5.6/en/integer-types.html) 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\$1type\$1conversions](https://dev.mysql.com/doc/refman/5.6/en/replication-options-replica.html#sysvar_slave_type_conversions) server system variable. For more information, see [Row-based replication: attribute promotion and demotion](https://dev.mysql.com/doc/refman/5.6/en/replication-features-differing-tables.html#replication-features-attribute-promotion), as well as the description of the variable.
+ Bug \$117449901: 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\$1key\$1checks=0. The foreign key constraint must be removed before dropping the foreign key index.
+ BUG \$120768847: An [ALTER TABLE ... DROP INDEX](https://dev.mysql.com/doc/refman/5.7/en/alter-table.html) operation on a table with foreign key dependencies raised an assertion.
# Aurora MySQL database engine updates 2020-03-05 (version 1.22.2) (Deprecated)
**Version:** 1.22.2
Aurora MySQL 1.22.2 is generally available. Aurora MySQL 1.\$1 versions are compatible with MySQL 5.6 and Aurora MySQL 2.\$1 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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).
Currently supported Aurora MySQL releases are 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 and 3.02.\$1.
To create a cluster with an older version of Aurora MySQL, please specify the engine version through the RDS Console, the AWS CLI, or the Amazon RDS API.
**Note**
This version is currently not available in the following regions: AWS GovCloud (US-East) [us-gov-east-1], AWS GovCloud (US-West) [us-gov-west-1]. There will be a separate announcement once it is made available.
This version is designated as a long-term support (LTS) release. For more information, see [ Aurora MySQL long-term support (LTS) releases](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Versions.html#AuroraMySQL.Updates.LTS) 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](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
## Improvements
**High priority fixes:**
+ Fixed an issue of intermittent connection failures after certificate rotation.
+ Fixed an issue that caused cloning to take longer on some database clusters with high write loads.
+ Fixed an issue that broke logical replication when the `binlog_checksum` parameter is set to different values on the master and the replica.
+ Fixed an issue where slow log and general log may not properly rotate on read replicas.
+ Fixed an issue with ANSI Read Committed Isolation Level behavior.
# Aurora MySQL database engine updates 2019-12-23 (version 1.22.1) (Deprecated)
**Version:** 1.22.1
Aurora MySQL 1.22.1 is generally available. Aurora MySQL 1.\$1 versions are compatible with MySQL 5.6 and Aurora MySQL 2.\$1 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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).
Currently supported Aurora MySQL releases are 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 and 3.02.\$1.
To create a cluster with an older version of Aurora MySQL, please specify the engine version through the AWS Management Console, the AWS CLI or the RDS API. You have the option to upgrade existing Aurora MySQL 1.\$1 database clusters to Aurora MySQL 1.22.1.
**Note**
This version is currently not available in the following AWS Regions: AWS GovCloud (US-East) [us-gov-east-1], AWS GovCloud (US-West) [us-gov-west-1], China (Ningxia) [cn-northwest-1], Asia Pacific (Hong Kong) [ap-east-1], and Middle East (Bahrain) [me-south-1. There will be a separate announcement once it is made available.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
**Note**
The procedure to upgrade your DB cluster has changed. For more information, see [ Upgrading the minor version or patch level of an Aurora MySQL DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html) in the *Amazon Aurora User Guide*.
## Improvements
**Critical fixes:**
+ Fixed issues that prevented engine recovery involving table locks and temporary tables.
+ Improved the stability of binary log when temporary tables are used.
**High priority fixes:**
+ Fixed a slow memory leak in Aurora specific database tracing and logging sub-system that lowers the freeable memory.
# Aurora MySQL database engine updates 2019-11-25 (version 1.22.0) (Deprecated)
**Version:** 1.22.0
Aurora MySQL 1.22.0 is generally available. Aurora MySQL 1.\$1 versions are compatible with MySQL 5.6 and Aurora MySQL 2.\$1 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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).
Currently supported Aurora MySQL releases are 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 and 3.02.\$1.
To create a cluster with an older version of Aurora MySQL, please specify the engine version through the AWS Management Console, the AWS CLI or the RDS API. You have the option to upgrade existing Aurora MySQL 1.\$1 database clusters to Aurora MySQL 1.22.0.
**Note**
This version is currently not available in the following AWS Regions: AWS GovCloud (US-East) [us-gov-east-1], AWS GovCloud (US-West) [us-gov-west-1], China (Ningxia) [cn-northwest-1], Asia Pacific (Hong Kong) [ap-east-1], Middle East (Bahrain) [me-south-1], and South America (São Paulo) [sa-east-1]. There will be a separate announcement once it is made available.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
**Note**
The procedure to upgrade your DB cluster has changed. For more information, see [ Upgrading the minor version or patch level of an Aurora MySQL DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html) in the *Amazon Aurora User Guide*.
## Improvements
**New features:**
+ Aurora MySQL clusters now support the instance types r5.8xlarge, r5.16xlarge and r5.24xlarge.
+ Binlog has new enhancements for improved commit time latency when very large transactions are involved.
+ Aurora MySQL now has a mechanism to minimize the time window during which events of a large transaction are written to binlog on commit. This effectively prevents lengthy offline recovery incurred when database crashes occur during that time window. This feature also fixes the issue where a large transaction blocks small transactions on binlog commit. This feature is off by default and can be enabled by the service team if needed for your workload. When enabled, it will be triggered when a transaction size is > 500MB.
+ Added support for the ANSI `READ COMMITTED` isolation level on the read replicas. This isolation level enables long-running queries on the read replica to execute without impacting the high throughput of writes on the writer node. For more information, see [Aurora MySQL isolation levels](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.html#AuroraMySQL.Reference.IsolationLevels).
+ Global Databases now allow adding secondary read-only replica regions for database clusters deployed in these AWS Regions: regions: US East (N. Virginia) [us-east-1], US East (Ohio) [us-east-2], US West (N. California) [us-west-1], US West (Oregon) [us-west-2], Europe (Ireland) [eu-west-1], Europe (London) [eu-west-2], Europe (Paris) [eu-west-3], Asia Pacific (Tokyo) [ap-northeast-1], Asia Pacific (Seoul) [ap-northeast-2], Asia Pacific (Singapore) [ap-southeast-1], Asia Pacific (Sydney) [ap-southeast-2], Canada (Central) [ca-central-1], Europe (Frankfurt) [eu-central-1], and Asia Pacific (Mumbai) [ap-south-1].
+ The hot row contention feature is now generally available and does not require the Aurora lab mode setting to be ON. This feature substantially improves throughput for workloads with many transactions contending for rows on the same page.
+ This version has updated timezone files to support the latest Brazil timezone update for new clusters.
**Critical fixes:**
+ [CVE-2019-2922](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2922)
+ [CVE-2019-2923](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2923)
+ [CVE-2019-2924](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2924)
+ [CVE-2019-2910](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2910)
**High priority fixes:**
+ [CVE-2019-2805](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2805)
+ [CVE-2019-2730](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2730)
+ [CVE-2019-2740](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2740)
+ [CVE-2018-3064](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3064)
+ [CVE-2018-3058](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3058)
+ [CVE-2017-3653](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3653)
+ [CVE-2017-3464](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3464)
+ [CVE-2017-3244](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3244)
+ [CVE-2016-5612](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5612)
+ [CVE-2016-5439](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5439)
+ [CVE-2016-0606](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0606)
+ [CVE-2015-4904](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4904)
+ [CVE-2015-4879](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4879)
+ [CVE-2015-4864](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4864)
+ [CVE-2015-4830](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4830)
+ [CVE-2015-4826](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4826)
+ [CVE-2015-2620](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-2620)
+ [CVE-2015-0382](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0382)
+ [CVE-2015-0381](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0381)
+ [CVE-2014-6555](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6555)
+ [CVE-2014-4258](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4258)
+ [CVE-2014-4260](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4260)
+ [CVE-2014-2444](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2444)
+ [CVE-2014-2436](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2436)
+ [CVE-2013-5881](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5881)
+ [CVE-2014-0393](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0393)
+ [CVE-2013-5908](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5908)
+ [CVE-2013-5807](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5807)
+ [CVE-2013-3806](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3806)
+ [CVE-2013-3811](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3811)
+ [CVE-2013-3804](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3804)
+ [CVE-2013-3807](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3807)
+ [CVE-2013-2378](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2378)
+ [CVE-2013-2375](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2375)
+ [CVE-2013-1523](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1523)
+ [CVE-2013-2381](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2381)
+ [CVE-2012-5615](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-5615)
+ [CVE-2014-6489](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6489)
+ Fixed an issue in the DDL recovery component that resulted in prolonged database downtime. Clusters that become unavailable after executing `TRUNCATE TABLE` query on a table with an `AUTO_INCREMENT` column should be updated.
+ Fixed an issue in the DDL recovery component that resulted in prolonged database downtime. Clusters that become unavailable after executing `DROP TABLE` query on multiple tables in parallel should be updated.
**General stability fixes:**
+ Fixed an issue that caused read replicas to restart during a long-running transaction. Customers who encounter replica restarts that coincide with an accelerated drop in freeable memory should consider upgrading to this version.
+ Fixed an issue that incorrectly reported `ERROR 1836` when a nested query is executed against a temporary table on the read replica.
+ Fixed a parallel query abort error on an Aurora reader instance while a heavy write workload is running on the Aurora writer instance.
+ Fixed an issue that causes a database configured as a Binlog Master to restart while a heavy write workload is running.
+ Fixed an issue of prolonged unavailability while restarting the engine. This addresses an issue in the buffer pool initialization. This issue occurs rarely but can potentially impact any supported release.
+ Fixed an issue that generated inconsistent data in the `information_schema.replica_host_status` table.
+ Fixed a race condition between the parallel query and the standard execution paths that caused the Reader nodes to restart intermittently.
+ Improved stability of the database when the number of number of client connections exceeds the `max_connections` parameter value.
+ Improved stability of the reader instances by blocking unsupported DDL and `LOAD FROM S3` queries.
## Integration of MySQL community edition bug fixes
+ Bug\$116346241 - SERVER CRASH IN ITEM\$1PARAM::QUERY\$1VAL\$1STR
+ Bug\$117733850 - NAME\$1CONST() CRASH IN ITEM\$1NAME\$1CONST::ITEM\$1NAME\$1CONST()
+ Bug \$120989615 - INNODB AUTO\$1INCREMENT PRODUCES SAME VALUE TWICE
+ Bug \$120181776 - ACCESS CONTROL DOESN'T MATCH MOST SPECIFIC HOST WHEN IT CONTAINS WILDCARD
+ Bug \$127326796 - MYSQL CRASH WITH INNODB ASSERTION FAILURE IN FILE PARS0PARS.CC
+ Bug \$120590013 - IF YOU HAVE A FULLTEXT INDEX AND DROP IT YOU CAN NO LONGER PERFORM ONLINE DDL
# Aurora MySQL database engine updates 2019-11-25 (version 1.21.0) (Deprecated)
**Version:** 1.21.0
Aurora MySQL 1.21.0 is generally available. Aurora MySQL 1.\$1 versions are compatible with MySQL 5.6 and Aurora MySQL 2.\$1 versions are compatible with MySQL 5.7.
Currently supported Aurora MySQL releases are 1.14.\$1, 1.15.\$1, 1.16.\$1, 1.17.\$1, 1.18.\$1, 1.19.\$1, 1.20.\$1, 1.21.\$1, 1.22.\$1, 2.01.\$1, 2.02.\$1, 2.03.\$1, 2.04.\$1, 2.05.\$1, 2.06.\$1 and 2.07.\$1. To create a cluster with an older version of Aurora MySQL, please specify the engine version through the AWS Management Console, the AWS CLI or the RDS API. You have the option to upgrade existing Aurora MySQL 1.\$1 database clusters to Aurora MySQL 1.21.0.
**Note**
This version is currently not available in the following AWS Regions: AWS GovCloud (US-East) [us-gov-east-1], AWS GovCloud (US-West) [us-gov-west-1], China (Ningxia) [cn-northwest-1], Asia Pacific (Hong Kong) [ap-east-1], Europe (Stockholm) [eu-north-1], and Middle East (Bahrain) [me-south-1]. There will be a separate announcement once it is made available.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
**Note**
The procedure to upgrade your DB cluster has changed. For more information, see [ Upgrading the minor version or patch level of an Aurora MySQL DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html) in the *Amazon Aurora User Guide*.
## Improvements
**Critical fixes:**
+ [CVE-2018-0734](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0734)
+ [CVE-2019-2534](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2534)
+ [CVE-2018-2612](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2612)
+ [CVE-2017-3599](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3599)
+ [CVE-2018-2562](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2562)
+ [CVE-2017-3329](https://nvd.nist.gov/vuln/detail/CVE-2017-3329)
+ [CVE-2018-2696](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2696)
+ [CVE-2015-4737](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4737)
**High priority fixes:**
+ Customers with database size close to 64 tebibytes (TiB) are strongly advised to upgrade to this version to avoid downtime due to stability bugs affecting volumes close to the Aurora storage limit.
**General stability fixes:**
+ Fixed a parallel query abort error on Aurora reader instances while a heavy write workload is running on the Aurora writer instance.
+ Fixed an issue on Aurora reader instances that reduced free memory during long-running transactions while there is a heavy transaction commit traffic on the writer instance.
+ The value of the parameter `aurora_disable_hash_join` is now persisted after database restart or host replacement.
+ Fixed an issue related to the Full Text Search cache that caused the Aurora instance to run out of memory. Customers using Full Text Search should upgrade.
+ Improved stability of the database when the hash join feature is enabled and the instance is low on memory. Customers using hash join should upgrade.
+ Fixed an issue in the query cache where the "Too many connections" error could cause a reboot.
+ Fixed the free memory calculation on T2 instances to include swap memory space to prevent unnecessary reboots.
## Integration of MySQL community edition bug fixes
+ Bug \$119929406: HANDLE\$1FATAL\$1SIGNAL (SIG=11) IN \$1\$1MEMMOVE\$1SSSE3\$1BACK FROM STRING::COPY
+ Bug \$117059925: For [UNION](https://dev.mysql.com/doc/refman/5.6/en/union.html) statements, the rows-examined value was calculated incorrectly. This was manifested as too-large values for the `ROWS_EXAMINED` column of Performance Schema statement tables (such as [events\$1statements\$1current](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-events-statements-current-table.html)).
+ Bug \$111827369: Some queries with `SELECT ... FROM DUAL` nested subqueries raised an assertion.
+ Bug \$116311231: Incorrect results were returned if a query contained a subquery in an `IN` clause that contained an [XOR](https://dev.mysql.com/doc/refman/5.6/en/logical-operators.html#operator_xor) operation in the `WHERE` clause.
# Aurora MySQL database engine updates 2020-03-05 (version 1.20.1) (Deprecated)
**Version:** 1.20.1
Aurora MySQL 1.20.1 is generally available. Aurora MySQL 1.\$1 versions are compatible with MySQL 5.6 and Aurora MySQL 2.\$1 versions are compatible with MySQL 5.7.
Currently supported Aurora MySQL releases are 1.14.\$1, 1.15.\$1, 1.16.\$1, 1.17.\$1, 1.18.\$1, 1.19.\$1, 1.20.\$1, 1.21.\$1, 1.22.\$1, 2.01.\$1, 2.02.\$1, 2.03.\$1, 2.04.\$1, 2.05.\$1, 2.06.\$1 and 2.07.\$1. You can restore the snapshot of an Aurora MySQL 1.\$1 database into Aurora MySQL 1.20.1.
To create a cluster with an older version of Aurora MySQL, please specify the engine version through the RDS Console, the AWS CLI, or the Amazon RDS API.
**Note**
This version is currently not available in the following regions: AWS GovCloud (US-East) [us-gov-east-1], AWS GovCloud (US-West) [us-gov-west-1]. There will be a separate announcement once it is made available.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
## Improvements
**High priority fixes:**
+ Fixed an issue of intermittent connection failures after certificate rotation.
+ Fixed an issue related to connection close concurrency that would result in a failover under heavy workload.
**General stability fixes:**
+ Fixed a crash during execution of a complex query involving multi-table joins and aggregation that uses intermediate tables internally.
# Aurora MySQL database engine updates 2019-11-11 (version 1.20.0) (Deprecated)
**Version:** 1.20.0
Aurora MySQL 1.20.0 is generally available. Aurora MySQL 1.\$1 versions are compatible with MySQL 5.6 and Aurora MySQL 2.\$1 versions are compatible with MySQL 5.7.
Currently supported Aurora MySQL releases are 1.14.\$1, 1.15.\$1, 1.16.\$1, 1.17.\$1, 1.18.\$1, 1.19.\$1, 1.20.\$1, 2.01.\$1, 2.02.\$1, 2.03.\$1 and 2.04.\$1. To create a cluster with an older version of Aurora MySQL, please specify the engine version through the AWS Management Console, the AWS CLI or the RDS API. You have the option to upgrade existing Aurora MySQL 1.\$1 database clusters, up to 1.19.5, to Aurora MySQL 1.20.0.
**Note**
This version is currently not available in the following AWS Regions: AWS GovCloud (US-East) [us-gov-east-1], AWS GovCloud (US-West) [us-gov-west-1], China (Ningxia) [cn-northwest-1], Asia Pacific (Hong Kong) [ap-east-1], Europe (Stockholm) [eu-north-1], and Middle East (Bahrain) [me-south-1]. There will be a separate announcement once it is made available.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
**Note**
The procedure to upgrade your DB cluster has changed. For more information, see [ Upgrading the minor version or patch level of an Aurora MySQL DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html) in the *Amazon Aurora User Guide*.
## Improvements
**Critical fixes:**
+ [CVE-2018-0734](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-0734)
+ [CVE-2019-2534](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-2534)
+ [CVE-2018-2612](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2612)
+ [CVE-2017-3599](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3599)
+ [CVE-2018-2562](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2562)
+ [CVE-2017-3329](https://nvd.nist.gov/vuln/detail/CVE-2017-3329)
+ [CVE-2018-2696](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2696)
+ [CVE-2015-4737](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4737)
**High priority fixes:**
+ Customers with database size close to 64 tebibytes (TiB) are strongly advised to upgrade to this version to avoid downtime due to stability bugs affecting volumes close to the Aurora storage limit.
**General stability fixes:**
+ Fixed a parallel query abort error on Aurora reader instances while a heavy write workload is running on the Aurora writer instance.
+ Fixed an issue on Aurora reader instances that reduced free memory during long-running transactions while there is a heavy transaction commit traffic on the writer instance.
+ The value of the parameter `aurora_disable_hash_join` is now persisted after database restart or host replacement.
+ Fixed an issue related to the Full Text Search cache that caused the Aurora instance to run out of memory. Customers using Full Text Search should upgrade.
+ Improved stability of the database when the hash join feature is enabled and the instance is low on memory. Customers using hash join should upgrade.
+ Fixed an issue in the query cache where the "Too many connections" error could cause a reboot.
+ Fixed the free memory calculation on T2 instances to include swap memory space to prevent unnecessary reboots.
## Integration of MySQL community edition bug fixes
+ Bug \$119929406: HANDLE\$1FATAL\$1SIGNAL (SIG=11) IN \$1\$1MEMMOVE\$1SSSE3\$1BACK FROM STRING::COPY
+ Bug \$117059925: For [UNION](https://dev.mysql.com/doc/refman/5.6/en/union.html) statements, the rows-examined value was calculated incorrectly. This was manifested as too-large values for the `ROWS_EXAMINED` column of Performance Schema statement tables (such as [events\$1statements\$1current](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-events-statements-current-table.html)).
+ Bug \$111827369: Some queries with `SELECT ... FROM DUAL` nested subqueries raised an assertion.
+ Bug \$116311231: Incorrect results were returned if a query contained a subquery in an `IN` clause that contained an [XOR](https://dev.mysql.com/doc/refman/5.6/en/logical-operators.html#operator_xor) operation in the `WHERE` clause.
# Aurora MySQL database engine updates 2020-03-05 (version 1.19.6) (Deprecated)
**Version:** 1.19.6
Aurora MySQL 1.19.6 is generally available. Aurora MySQL 1.\$1 versions are compatible with MySQL 5.6 and Aurora MySQL 2.\$1 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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).
Currently supported Aurora MySQL releases are 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 and 3.02.\$1.
You can restore the snapshot of an Aurora MySQL 1.\$1 database into Aurora MySQL 1.19.6.
To create a cluster with an older version of Aurora MySQL, please specify the engine version through the RDS Console, the AWS CLI, or the Amazon RDS API.
**Note**
This version is currently not available in the following regions: AWS GovCloud (US-East) [us-gov-east-1], AWS GovCloud (US-West) [us-gov-west-1]. There will be a separate announcement once it is made available.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
## Improvements
**High priority fixes:**
+ Fixed an issue of intermittent connection failures after certificate rotation.
# Aurora MySQL database engine updates 2019-09-19 (version 1.19.5) (Deprecated)
**Version:** 1.19.5
Aurora MySQL 1.19.5 is generally available. Aurora MySQL 1.\$1 versions are compatible with MySQL 5.6 and Aurora MySQL 2.\$1 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](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.MySQL56.EOL.html).
Currently supported Aurora MySQL releases are 1.19.5, 1.19.6, 1.22.\$1, 1.23.\$1, 2.04.\$1, 2.07.\$1, 2.08.\$1, 2.09.\$1, 2.10.\$1, 3.01.\$1 and 3.02.\$1.
You have the option to upgrade existing database clusters to Aurora MySQL 1.19.5. You can restore snapshots of Aurora MySQL 1.14.\$1, 1.15.\$1, 1.16.\$1, 1.17.\$1, 1.18.\$1, 1.19.1, and 1.19.2 into Aurora MySQL 1.19.5.
To use an older version of Aurora MySQL, you can create new database clusters by specifying the engine version through the AWS Management Console, the AWS CLI, or the RDS API.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
**Note**
This version is currently not available in the following AWS Regions: Europe (London) [eu-west-2], AWS GovCloud (US-East) [us-gov-east-1], AWS GovCloud (US-West) [us-gov-west-1], China (Ningxia) [cn-northwest-1], and Asia Pacific (Hong Kong) [ap-east-1]. There will be a separate announcement once it is made available.
**Note**
The procedure to upgrade your DB cluster has changed. For more information, see [ Upgrading the minor version or patch level of an Aurora MySQL DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html) in the *Amazon Aurora User Guide*.
## Improvements
+ Fixed an issue on Aurora reader instances that reduced free memory during long-running transactions while there is a heavy transaction commit traffic on the writer instance.
+ Fixed a parallel query abort error on Aurora reader instances while a heavy write workload is running on the Aurora writer instance.
+ The value of the parameter `aurora_disable_hash_join` is now persisted after database restart or host replacement.
+ Fixed an issue related to the Full Text Search cache that caused the Aurora instance to run out of memory.
+ Improved stability of the database when the volume size is close to the 64 tebibyte (TiB) volume limit by reserving 160 GB of space for the recovery workflow to complete without a failover.
+ Improved stability of the database when the hash join feature is enabled and the instance is low on memory.
+ Fixed the free memory calculation to include swap memory space on T2 instances that caused them to reboot prematurely.
+ Fixed an issue in the query cache where the "Too many connections" error could cause a reboot.
## Integration of MySQL community edition bug fixes
+ [CVE-2018-2696](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-2696)
+ [CVE-2015-4737](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-4737)
+ Bug \$119929406: HANDLE\$1FATAL\$1SIGNAL (SIG=11) IN \$1\$1MEMMOVE\$1SSSE3\$1BACK FROM STRING::COPY
+ Bug \$117059925: For [UNION](https://dev.mysql.com/doc/refman/5.6/en/union.html) statements, the rows-examined value was calculated incorrectly. This was manifested as too-large values for the `ROWS_EXAMINED` column of Performance Schema statement tables (such as [events\$1statements\$1current](https://dev.mysql.com/doc/refman/8.0/en/performance-schema-events-statements-current-table.html)).
+ Bug \$111827369: Some queries with `SELECT ... FROM DUAL` nested subqueries raised an assertion.
+ Bug \$116311231: Incorrect results were returned if a query contained a subquery in an `IN` clause that contained an [XOR](https://dev.mysql.com/doc/refman/5.6/en/logical-operators.html#operator_xor) operation in the `WHERE` clause.
# Aurora MySQL database engine updates 2019-06-05 (version 1.19.2) (Deprecated)
**Version:** 1.19.2
Aurora MySQL 1.19.2 is generally available. All new Aurora MySQL database clusters with MySQL 5.6 compatibility, including those restored from snapshots, can be created with 1.17.8, 1.19.0, 1.19.1, or 1.19.2. You have the option, but are not required, to upgrade existing database clusters to Aurora MySQL 1.19.2. To use an older version, you can create new database clusters in Aurora MySQL 1.14.4, Aurora MySQL 1.15.1, Aurora MySQL 1.16, Aurora MySQL 1.17.8, or Aurora MySQL 1.18. You can do so using the AWS CLI or the Amazon RDS API and specifying the engine version.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
**Note**
This version is currently not available in the AWS GovCloud (US-West) [us-gov-west-1], Europe (Stockholm) [eu-north-1], China (Ningxia) [cn-northwest-1], and Asia Pacific (Hong Kong) [ap-east-1] AWS Regions. There will be a separate announcement once it is made available.
**Note**
The procedure to upgrade your DB cluster has changed. For more information, see [ Upgrading the minor version or patch level of an Aurora MySQL DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html) in the *Amazon Aurora User Guide*.
## Improvements
+ Fixed an issue that could cause failures when loading data into Aurora from Amazon S3.
+ Fixed an issue that could cause failures when uploading data from Aurora to Amazon S3.
+ Fixed an issue that created zombie sessions left in a killed state.
+ Fixed an issue that caused aborted connections when handling an error in network protocol management.
+ Fixed an issue that could cause a crash when dealing with partitioned tables.
+ Fixed an issue related to binlog replication of trigger creation.
# Aurora MySQL database engine updates 2019-05-09 (version 1.19.1) (Deprecated)
**Version:** 1.19.1
Aurora MySQL 1.19.1 is generally available. All new Aurora MySQL database clusters with MySQL 5.6 compatibility, including those restored from snapshots, can be created with 1.17.8, 1.19.0, or 1.19.1. You have the option, but are not required, to upgrade existing database clusters to Aurora MySQL 1.19.1. To use an older version, you can create new database clusters in Aurora MySQL 1.14.4, Aurora MySQL 1.15.1, Aurora MySQL 1.16, Aurora MySQL 1.17.8, or Aurora MySQL 1.18. You can do so using the AWS CLI or the Amazon RDS API and specifying the engine version.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
**Note**
This version is currently not available in the AWS GovCloud (US-West) [us-gov-west-1] and China (Beijing) [cn-north-1] regions. There will be a separate announcement once it is made available.
**Note**
The procedure to upgrade your DB cluster has changed. For more information, see [ Upgrading the minor version or patch level of an Aurora MySQL DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html) in the *Amazon Aurora User Guide*.
## Improvements
+ Fixed a bug in binlog replication that can cause an issue on Aurora instances configured as binlog worker.
+ Fixed an error in handling certain kinds of `ALTER TABLE` commands.
+ Fixed an issue with aborted connections because of an error in network protocol management.
# Aurora MySQL database engine updates 2019-02-07 (version 1.19.0) (Deprecated)
**Version:** 1.19.0
Aurora MySQL 1.19.0 is generally available. All new Aurora MySQL database clusters with MySQL 5.6 compatibility, including those restored from snapshots, can be created with 1.17.8 or 1.19.0. You have the option, but are not required, to upgrade existing database clusters to Aurora MySQL 1.19.0. To use an older version, you can create new database clusters in Aurora MySQL 1.14.4, Aurora MySQL 1.15.1, Aurora MySQL 1.16, Aurora MySQL 1.17.8, or Aurora MySQL 1.18.0. You can do so using the AWS CLI or the Amazon RDS API and specifying the engine version.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
**Note**
This version is currently not available in the AWS GovCloud (US-West) [us-gov-west-1] and China (Beijing) [cn-north-1] regions. There will be a separate announcement once it is made available.
**Note**
The procedure to upgrade your DB cluster has changed. For more information, see [ Upgrading the minor version or patch level of an Aurora MySQL DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html) in the *Amazon Aurora User Guide*.
## Features
+ **Aurora Version Selector** - Starting with Aurora MySQL 1.19.0, you can choose from among multiple versions of MySQL 5.6 compatible Aurora on the Amazon RDS console. For more information, see [ Checking or specifying Aurora MySQL engine versions through AWS](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Versions.html#AuroraMySQL.Updates.EngineVersions) in the *Amazon Aurora User Guide*.
## Improvements
+ Fixed a stability issue related to the `CHECK TABLE` query on an Aurora Replica.
+ Introduced a new global user variable `aurora_disable_hash_join` to disable Hash Join.
+ Fixed a stability issue when generating the output row during multiple table hash join.
+ Fixed an issue that returned a wrong result because of a plan change during Hash Join applicability check.
+ Zero Downtime Patching is supported with long running transactions. This enhancement will come into effect when upgrading from version 1.19 to a higher one.
+ Zero Downtime Patching is now supported when binlog is enabled. This enhancement will come into effect when upgrading from version 1.19 to a higher one.
+ Fixed an issue that caused a spike in CPU utilization on the Aurora Replica unrelated to the workload.
+ Fixed a race condition in the lock manager that resulted in a database restart.
+ Fixed a race condition in the lock manager component to improve stability of Aurora instances.
+ Improved stability of the deadlock detector inside the lock manager component.
+ `INSERT` operation on a table is prohibited if InnoDB detects that the index is corrupted.
+ Fixed a stability issue in Fast DDL.
+ Improved Aurora stability by reducing the memory consumption in scan batching for single-row subquery.
+ Fixed a stability issue that occurred after a foreign key was dropped while the system variable `foreign_key_checks` is set to 0.
+ Fixed an issue in the Out Of Memory Avoidance feature that erroneously overrode changes to the `table_definition_cache` value made by the user.
+ Fixed stability issues in the Out Of Memory Avoidance feature.
+ Fixed an issue that set `query_time` and `lock_time` in `slow_query_log` to garbage values.
+ Fixed a parallel query stability issue triggered by improper handling of string collation internally.
+ Fixed a parallel query stability issue triggered by a secondary index search.
+ Fixed a parallel query stability issue triggered by a multi-table update.
## Integration of MySQL community edition bug fixes
+ BUG \$132917: DETECT ORPHAN TEMP-POOL FILES, AND HANDLE GRACEFULLY
+ BUG \$163144 CREATE TABLE IF NOT EXISTS METADATA LOCK IS TOO RESTRICTIVE
# Aurora MySQL database engine updates 2018-09-20 (version 1.18.0) (Deprecated)
**Version:** 1.18.0
Aurora MySQL 1.18.0 is generally available. All new Aurora MySQL parallel query clusters with MySQL 5.6 compatibility, including those restored from snapshots, will be created in Aurora MySQL 1.18.0. You have the option, but are not required, to upgrade existing parallel query clusters to Aurora MySQL 1.18.0. You can create new DB clusters in Aurora MySQL 1.14.4, Aurora MySQL 1.15.1, Aurora MySQL 1.16, or Aurora MySQL 1.17.6. You can do so using the AWS CLI or the Amazon RDS API and specifying the engine version.
With version 1.18.0 of Aurora MySQL, we are using a cluster patching model where all nodes in an Aurora DB cluster are patched at the same time.
**Important**
Aurora MySQL 1.18.0 only applies to Aurora parallel query clusters. If you upgrade a provisioned 5.6.10a cluster, the resulting version is 1.17.8. If you upgrade a parallel query 5.6.10a cluster, the resulting version is 1.18.0.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
## Features
+ **Parallel Query** is available with this release, for new clusters and restored snapshots. Aurora MySQL parallel query is an optimization that parallelizes some of the I/O and computation involved in processing data-intensive queries. The work that is parallelized includes retrieving rows from storage, extracting column values, and determining which rows match the conditions in the `WHERE` clause and join clauses. This data-intensive work is delegated (in database optimization terms, pushed down) to multiple nodes in the Aurora distributed storage layer. Without parallel query, each query brings all the scanned data to a single node within the Aurora MySQL cluster (the head node) and performs all the query processing there.
+ When the parallel query feature is enabled, the Aurora MySQL engine automatically determines when queries can benefit, without requiring SQL changes such as hints or table attributes.
For more information, see [ Working with parallel query for Amazon Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-mysql-parallel-query.html) in the *Amazon Aurora User Guide*.
+ **OOM Avoidance:** This feature monitors the system memory and tracks memory consumed by various components of the database. Once the system runs low on memory, it performs a list of actions to release memory from various tracked components in an attempt to save the database from running into Out of Memory (OOM) and thereby avoiding a database restart. This best-effort feature is enabled by default for t2 instances and can be enabled on other instance classes via a new instance parameter named `aurora_oom_response`. The instance parameter takes a string of comma separated actions that an instance should take when its memory is low. Valid actions include "print", "tune", "decline", "kill\$1query" or any combination of these. Any empty string means there should be no actions taken and effectively renders the feature to be disabled. Note that the default actions for the feature is "print, tune". Usage examples:
+ "print" – Only prints the queries taking high amount of memory.
+ "tune" – Tunes the internal table caches to release some memory back to the system.
+ "decline" – Declines new queries once the instance is low on memory.
+ "kill\$1query" – Kills the queries in descending order of memory consumption until the instance memory surfaces above the low threshold. Data definition language (DDL) statements are not killed.
+ "print, tune" – Performs actions described for both "print" and "tune".
+ "tune, decline, kill\$1query" – Performs the actions described for "tune", "decline", and "kill\$1query".
For information about handling out-of-memory conditions and other troubleshooting advice, see [Amazon Aurora MySQL out of memory issues](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-mysql-troubleshooting-workload.html#AuroraMySQLOOM) in the *Amazon Aurora User Guide*.
# Aurora MySQL database engine updates 2020-03-05 (version 1.17.9) (Deprecated)
**Version:** 1.17.9
Aurora MySQL 1.17.9 is generally available. Aurora MySQL 1.\$1 versions are compatible with MySQL 5.6 and Aurora MySQL 2.\$1 versions are compatible with MySQL 5.7.
Currently supported Aurora MySQL releases are 1.14.\$1, 1.15.\$1, 1.16.\$1, 1.17.\$1, 1.18.\$1, 1.19.\$1, 1.20.\$1, 1.21.\$1, 1.22.\$1, 2.01.\$1, 2.02.\$1, 2.03.\$1, 2.04.\$1, 2.05.\$1, 2.06.\$1 and 2.07.\$1. You can restore the snapshot of an Aurora MySQL 1.\$1 database into Aurora MySQL 1.17.9.
To create a cluster with an older version of Aurora MySQL, please specify the engine version through the RDS Console, the AWS CLI, or the Amazon RDS API.
**Note**
This version is currently not available in the following regions: AWS GovCloud (US-East) [us-gov-east-1], AWS GovCloud (US-West) [us-gov-west-1]. There will be a separate announcement once it is made available.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
## Improvements
**High priority fixes:**
+ Fixed an issue of intermittent connection failures after certificate rotation.
# Aurora MySQL database engine updates 2019-01-17 (version 1.17.8) (Deprecated)
**Version:** 1.17.8
Aurora MySQL 1.17.8 is generally available. All new Aurora MySQL database clusters with MySQL 5.6 compatibility, including those restored from snapshots, will be created in Aurora MySQL 1.17.8. You have the option, but are not required, to upgrade existing database clusters to Aurora MySQL 1.17.8. To use an older version, you can create new database clusters in Aurora MySQL 1.14.4, 1.15.1, 1.16, or 1.17.7. You can do so using the AWS CLI or the Amazon RDS API and specifying the engine version.
With version 1.17.8 of Aurora MySQL, we are using a cluster patching model where all nodes in an Aurora DB cluster are patched at the same time.
**Note**
This version is currently not available in the AWS GovCloud (US-West) [us-gov-west-1] and China (Beijing) [cn-north-1] regions. There will be a separate announcement once it is made available.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
## Improvements
+ Fixed a performance issue that increased the CPU utilization on an Aurora Replica after a restart.
+ Fixed a stability issue for `SELECT` queries that used hash join.
## Integration of MySQL community edition bug fixes
+ BUG \$113418638: CREATE TABLE IF NOT EXISTS METADATA LOCK IS TOO RESTRICTIVE
# Aurora MySQL database engine updates 2018-10-08 (version 1.17.7) (Deprecated)
**Version:** 1.17.7
Aurora MySQL 1.17.7 is generally available. All new Aurora MySQL database clusters with MySQL 5.6 compatibility, including those restored from snapshots, will be created in Aurora MySQL 1.17.7. You have the option, but are not required, to upgrade existing database clusters to Aurora MySQL 1.17.7. To use an older version, you can create new database clusters in Aurora MySQL 1.14.4, 1.15.1, 1.16, or 1.17.6. You can do so using the AWS CLI or the Amazon RDS API and specifying the engine version.
With version 1.17.7 of Aurora MySQL, we are using a cluster patching model where all nodes in an Aurora DB cluster are patched at the same time.
**Note**
This version is currently not available in the AWS GovCloud (US-West) [us-gov-west-1] and China (Beijing) [cn-north-1] regions. There will be a separate announcement once it is made available.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
## Improvements
+ The InnoDB status variable `innodb_buffer_pool_size` has been made publicly visible for the customers to modify.
+ Fixed a stability issue on the Aurora cluster that occurred during failovers.
+ Improved cluster availability by fixing a DDL recovery issue that occurred after an unsuccessful `TRUNCATE` operation.
+ Fixed a stability issue related to the `mysql.innodb_table_stats` table update, triggered by DDL operations.
+ Fixed Aurora Replica stability issues triggered during query cache invalidation after a DDL operation.
+ Fixed a stability issue triggered by invalid memory access during periodic dictionary cache eviction in the background.
## Integration of MySQL community edition bug fixes
+ Bug \$116208542: Drop index on a foreign key column leads to missing table.
+ Bug \$176349: memory leak in add\$1derived\$1key().
+ Bug \$116862316: For partitioned tables, queries could return different results depending on whether Index Merge was used.
+ Bug \$117588348: Queries using the index\$1merge optimization (see [Index merge optimization](https://dev.mysql.com/doc/refman/5.6/en/index-merge-optimization.html)) could return invalid results when run against tables that were partitioned by HASH.
# Aurora MySQL database engine updates 2018-09-06 (version 1.17.6) (Deprecated)
**Version:** 1.17.6
Aurora MySQL 1.17.6 is generally available. All new Aurora MySQL database clusters with MySQL 5.6 compatibility, including those restored from snapshots, will be created in Aurora MySQL 1.17.6. You have the option, but are not required, to upgrade existing database clusters to Aurora MySQL 1.17.6. To use an older version, you can create new database clusters in Aurora MySQL 1.14.4, 1.15.1, 1.16, or 1.17.5. You can do so using the AWS CLI or the Amazon RDS API and specifying the engine version.
With version 1.17.6 of Aurora MySQL, we are using a cluster patching model where all nodes in an Aurora DB cluster are patched at the same time.
**Note**
This version is currently not available in the AWS GovCloud (US-West) [us-gov-west-1] and China (Beijing) [cn-north-1] regions. There will be a separate announcement once it is made available.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
## Improvements
+ Fixed a stability issue on the Aurora Reader for `SELECT` queries while the Aurora Writer is performing DDL operations on the same table.
+ Fixed a stability issue caused by the creation and deletion of DDL logs for temporary tables that use Heap/Memory engine.
+ Fixed a stability issue on the binlog worker when DDL statements are being replicated while the connection to the Binlog Master is unstable.
+ Fixed a stability issue encountered while writing to the slow query log.
+ Fixed an issue with the replica status table that exposed incorrect Aurora Reader lag information.
## Integration of MySQL community edition bug fixes
+ For an [ALTER TABLE](https://dev.mysql.com/doc/refman/5.6/en/alter-table.html) statement that renamed or changed the default value of a [BINARY](https://dev.mysql.com/doc/refman/5.6/en/binary-varbinary.html) column, the alteration was done using a table copy and not in place. (Bug \$167141, Bug \$114735373, Bug \$169580, Bug \$117024290)
+ An outer join between a regular table and a derived table that is implicitly groups could cause a server exit. (Bug \$116177639)
# Aurora MySQL database engine updates 2018-08-14 (version 1.17.5) (Deprecated)
**Version:** 1.17.5
Aurora MySQL 1.17.5 is generally available. All new Aurora MySQL database clusters with MySQL 5.6 compatibility, including those restored from snapshots, will be created in Aurora MySQL 1.17.5. You have the option, but are not required, to upgrade existing database clusters to Aurora MySQL 1.17.5. To use an older version, you can create new database clusters in Aurora MySQL 1.14.4, 1.15.1, 1.16, or 1.17.4. You can do so using the AWS CLI or the Amazon RDS API and specifying the engine version.
With version 1.17.5 of Aurora MySQL, we are using a cluster patching model where all nodes in an Aurora DB cluster are patched at the same time.
**Note**
This version is currently not available in the AWS GovCloud (US-West) [us-gov-west-1] and China (Beijing) [cn-north-1] regions. There will be a separate announcement once it is made available.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
## Improvements
+ Fixed an issue where an Aurora Writer might experience a restart after an Aurora cluster is patched using the Zero-Downtime Patching feature.
# Aurora MySQL database engine updates 2018-08-07 (version 1.17.4) (Deprecated)
**Version:** 1.17.4
Aurora MySQL 1.17.4 is generally available. All new Aurora MySQL database clusters with MySQL 5.6 compatibility, including those restored from snapshots, will be created in Aurora MySQL 1.17.4. You have the option, but are not required, to upgrade existing database clusters to Aurora MySQL 1.17.4. To use an older version, you can create new database clusters in Aurora MySQL 1.14.4, 1.15.1, 1.16, or 1.17.3. You can do so using the AWS CLI or the Amazon RDS API and specifying the engine version.
With version 1.17.4 of Aurora MySQL, we are using a cluster patching model where all nodes in an Aurora DB cluster are patched at the same time.
**Note**
This version is currently not available in the AWS GovCloud (US-West) [us-gov-west-1] and China (Beijing) [cn-north-1] regions. There will be a separate announcement once it is made available.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
## Improvements
+ Replication improvements:
+ Reduced network traffic by not transmitting binlog records to cluster replicas. This improvement is enabled by default.
+ Reduced network traffic by compressing replication messages. This improvement is enabled by default for 8xlarge and 16xlarge instance classes. Such large instances can sustain a heavy volume of write traffic that results in substantial network traffic for replication messages.
+ Fixes to the replica query cache.
+ Fixed an issue where `ORDER BY LOWER(col_name)` could produce incorrect ordering while using the `utf8_bin` collation.
+ Fixed an issue where DDL statements (especially `TRUNCATE TABLE`) could cause problems on Aurora replicas, including instability or missing tables.
+ Fixed an issue where sockets are left in a half-open state when storage nodes are restarted.
+ The following new DB cluster parameters are available:
+ `aurora_enable_zdr` – Allow connections opened on an Aurora Replica to stay active on replica restart.
+ `aurora_enable_replica_log_compression` – Enable compression of replication payloads to improve network bandwidth utilization between the master and Aurora Replicas.
+ `aurora_enable_repl_bin_log_filtering` – Enable filtering of replication records that are unusable by Aurora Replicas on the master.
# Aurora MySQL database engine updates 2018-06-05 (version 1.17.3) (Deprecated)
**Version:** 1.17.3
Aurora MySQL 1.17.3 is generally available. All new Aurora MySQL database clusters with MySQL 5.6 compatibility, including those restored from snapshots, will be created in Aurora MySQL 1.17.3. You have the option, but are not required, to upgrade existing database clusters to Aurora MySQL 1.17.3. You can create new database clusters in Aurora MySQL 1.14.4, Aurora MySQL 1.15.1, or Aurora MySQL 1.16. You can do so using the AWS CLI or the Amazon RDS API and specifying the engine version.
With version 1.17.3 of Aurora MySQL, we are using a cluster patching model where all nodes in an Aurora DB cluster are patched at the same time.
**Note**
This version is currently not available in the AWS GovCloud (US-West) [us-gov-west-1] and China (Beijing) [cn-north-1] regions. There will be a separate announcement once it is made available.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
## Improvements
+ Fixed an issue where an Aurora Replica can restart when using optimistic cursor restores while reading records.
+ Fixed an issue where an Aurora Writer restarts when trying to kill a MySQL session (kill "**") with performance schema enabled.
+ Fixed an issue where an Aurora Writer restarts when computing a threshold for garbage collection.
+ Fixed an issue where an Aurora Writer can occasionally restart when tracking Aurora Replica progress in log application.
+ Fixed an issue with the Query Cache when auto-commit is off and that could potentially cause stale reads.
# Aurora MySQL database engine updates 2018-04-27 (version 1.17.2) (Deprecated)
**Version:** 1.17.2
Aurora MySQL 1.17.2 is generally available. All new Aurora MySQL database clusters with MySQL 5.6 compatibility, including those restored from snapshots, will be created in Aurora MySQL 1.17.2. You have the option, but are not required, to upgrade existing database clusters to Aurora MySQL 1.17.2. You can create new database clusters in Aurora MySQL 1.14.4, Aurora MySQL 1.15.1, or Aurora MySQL 1.16. You can do so using the AWS CLI or the Amazon RDS API and specifying the engine version.
With version 1.17.2 of Aurora MySQL, we are using a cluster patching model where all nodes in an Aurora DB cluster are patched at the same time.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
## Improvements
+ Fixed an issue which was causing restarts during certain DDL partition operations.
+ Fixed an issue which was causing support for invocation of AWS Lambda functions via native Aurora MySQL functions to be disabled.
+ Fixed an issue with cache invalidation which was causing restarts on Aurora Replicas.
+ Fixed an issue in lock manager which was causing restarts.
# Aurora MySQL database engine updates 2018-03-23 (version 1.17.1) (Deprecated)
**Version:** 1.17.1
Aurora MySQL 1.17.1 is generally available. All new database clusters, including those restored from snapshots, will be created in Aurora MySQL 1.17.1. You have the option, but are not required, to upgrade existing database clusters to Aurora MySQL 1.17.1. You can create new DB clusters in Aurora MySQL 1.15.1, Aurora MySQL 1.16, or Aurora MySQL 1.17. You can do so using the AWS CLI or the Amazon RDS API and specifying the engine version.
With version 1.17.1 of Aurora MySQL, we are using a cluster patching model where all nodes in an Aurora DB cluster are patched at the same time. This release fixes some known engine issues as well as regressions.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
**Note**
There is an issue in the latest version of the Aurora MySQL engine. After upgrading to 1.17.1, the engine version is reported incorrectly as `1.17`. If you upgraded to 1.17.1, you can confirm the upgrade by checking the **Maintenance** column for the DB cluster in the AWS Management Console. If it displays `none`, then the engine is upgraded to 1.17.1.
## Improvements
+ Fixed an issue in binary log recovery that resulted in longer recovery times for situations with large binary log index files which can happen if binary logs rotate very often.
+ Fixed an issue in the query optimizer that generated an inefficient query plan for partitioned tables.
+ Fixed an issue in the query optimizer due to which a range query resulted in a restart of the database engine.
# Aurora MySQL database engine updates 2018-03-13 (version 1.17) (Deprecated)
**Version:** 1.17
Aurora MySQL 1.17 is generally available. Aurora MySQL 1.x versions are only compatible with MySQL 5.6, and not MySQL 5.7. All new 5.6-compatible database clusters, including those restored from snapshots, will be created in Aurora 1.17. You have the option, but are not required, to upgrade existing database clusters to Aurora 1.17. You can create new DB clusters in Aurora 1.14.1, Aurora 1.15.1, or Aurora 1.16. You can do so using the AWS CLI or the Amazon RDS API and specifying the engine version.
With version 1.17 of Aurora, we are using a cluster patching model where all nodes in an Aurora DB cluster are patched at the same time. We support zero-downtime patching, which works on a best-effort basis to preserve client connections through the patching process. For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) 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](https://aws.amazon.com/support).
## Zero-downtime patching
The zero-downtime patching (ZDP) feature attempts, on a *best-effort* basis, to preserve client connections through an engine patch. For more information about ZDP, see [ Using zero-downtime patching](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html#AuroraMySQL.Updates.ZDP) in the *Amazon Aurora User Guide*.
## New features
+ Aurora MySQL now supports lock compression, which optimizes the lock manager's memory usage. Starting in version 1.17, you can use this feature without enabling lab mode.
## Improvements
+ Fixed an issue predominantly seen on instances with fewer cores where a single core might have 100% CPU utilization even when the database is idle.
+ Improved the performance of fetching binary logs from Aurora clusters.
+ Fixed an issue where Aurora Replicas attempt to write table statistics to persistent storage, and crash.
+ Fixed an issue where query cache did not work as expected on Aurora Replicas.
+ Fixed a race condition in lock manager that resulted in an engine restart.
+ Fixed an issue where locks taken by read-only, auto-commit transactions resulted in an engine restart.
+ Fixed an issue where some queries are not written to the audit logs.
+ Fixed an issue with recovery of certain partition maintenance operations on failover.
## Integration of MySQL bug fixes
+ LAST\$1INSERT\$1ID is replicated incorrectly if replication filters are used (Bug \$169861)
+ Query returns different results depending on whether INDEX\$1MERGE setting (Bug \$116862316)
+ Query proc re-execute of stored routine, inefficient query plan (Bug \$116346367)
+ INNODB FTS : Assert in FTS\$1CACHE\$1APPEND\$1DELETED\$1DOC\$1IDS (BUG \$118079671)
+ Assert RBT\$1EMPTY(INDEX\$1CACHE->WORDS) in ALTER TABLE CHANGE COLUMN (BUG \$117536995)
+ INNODB fulltext search doesn't find records when savepoints are involved (BUG \$170333, BUG \$117458835)
# Aurora MySQL database engine updates 2017-12-11 (version 1.16) (Deprecated)
**Version:** 1.16
Aurora MySQL 1.16 is generally available. All new database clusters, including those restored from snapshots, will be created in Aurora 1.16. You have the option, but are not required, to upgrade existing database clusters to Aurora 1.16. You can create new DB clusters in Aurora 1.14.1 or Aurora 1.15.1. You can do so using the AWS CLI or the Amazon RDS API and specifying the engine version.
With version 1.16 of Aurora, we are using a cluster patching model where all nodes in an Aurora DB cluster are patched at the same time. We are enabling zero-downtime patching, which works on a best-effort basis to preserve client connections through the patching process. For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) 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](https://aws.amazon.com/support).
## Zero-downtime patching
The zero-downtime patching (ZDP) feature attempts, on a *best-effort* basis, to preserve client connections through an engine patch. For more information about ZDP, see [ Using zero-downtime patching](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html#AuroraMySQL.Updates.ZDP) in the *Amazon Aurora User Guide*.
## New features
+ Aurora MySQL now supports synchronous AWS Lambda invocations via the native function `lambda_sync()`. Also available is native function `lambda_async()`, which can be used as an alternative to the existing stored procedure for asynchronous Lambda invocation. For more information, see [ Invoking a Lambda function from an Amazon Aurora MySQL DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.Lambda.html) in the *Amazon Aurora User Guide*.
+ Aurora MySQL now supports hash joins to speed up equijoin queries. Aurora's cost-based optimizer can automatically decide when to use hash joins; you can also force their use in a query plan. For more information, see [ Optimizing large Aurora MySQL join queries with hash joins](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.BestPractices.html#Aurora.BestPractices.HashJoin) in the *Amazon Aurora User Guide*.
+ Aurora MySQL now supports scan batching to speed up in-memory scan-oriented queries significantly. The feature boosts the performance of table full scans, index full scans, and index range scans by batch processing.
## Improvements
+ Fixed an issue where read replicas crashed when running queries on tables that have just been dropped on the master.
+ Fixed an issue where restarting the writer on a database cluster with a very large number of `FULLTEXT` indexes results in longer than expected recovery.
+ Fixed an issue where flushing binary logs causes `LOST_EVENTS` incidents in binlog events.
+ Fixed stability issues with the scheduler when performance schema is enabled.
+ Fixed an issue where a subquery that uses temporary tables could return partial results.
## Integration of MySQL bug fixes
None
# Aurora MySQL database engine updates 2017-11-20 (version 1.15.1) (Deprecated)
**Version:** 1.15.1
Aurora MySQL 1.15.1 is generally available. All new database clusters, including those restored from snapshots, will be created in Aurora 1.15.1. You have the option, but are not required, to upgrade existing DB clusters to Aurora 1.15.1. You can create new DB clusters in Aurora 1.14.1. You can do so using the AWS CLI or the Amazon RDS API and specifying the engine version.
With version 1.15.1 of Aurora, we are using a cluster patching model where all nodes in an Aurora DB cluster are patched at the same time. We are enabling zero-downtime patching, which works on a best-effort basis to preserve client connections through the patching process. For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) 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](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
## Zero-downtime patching
The zero-downtime patching (ZDP) feature attempts, on a *best-effort* basis, to preserve client connections through an engine patch. For more information about ZDP, see [ Using zero-downtime patching](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html#AuroraMySQL.Updates.ZDP) in the *Amazon Aurora User Guide*.
## Improvements
+ Fixed an issue in the adaptive segment selector for a read request that would cause it to choose the same segment twice causing a spike in read latency under certain conditions.
+ Fixed an issue that stems from an optimization in Aurora MySQL for the thread scheduler. This problem manifests itself into what are spurious errors while writing to the slow log, while the associated queries themselves perform fine.
+ Fixed an issue with stability of read replicas on large (> 5 TB) volumes.
+ Fixed an issue where worker thread count increases continuously due to a bogus outstanding connection count.
+ Fixed an issue with table locks that caused long semaphore waits during insert workloads.
+ Reverted the following MySQL bug fixes included in Aurora MySQL 1.15:
+ MySQL instance stalling "doing SYNC index" (Bug \$173816)
+ Assert RBT\$1EMPTY(INDEX\$1CACHE->WORDS) in ALTER TABLE CHANGE COLUMN (Bug \$117536995)
+ InnoDB Fulltext search doesn't find records when savepoints are involved (Bug \$170333)
## Integration of MySQL bug fixes
None
# Aurora MySQL database engine updates 2017-10-24 (version 1.15) (Deprecated)
**Version:** 1.15
Aurora MySQL 1.15 is generally available. All new database clusters, including those restored from snapshots, will be created in Aurora 1.15. You have the option, but are not required, to upgrade existing DB clusters to Aurora 1.15. You can create new DB clusters in Aurora 1.14.1. You can do so using the AWS CLI or the Amazon RDS API and specifying the engine version.
With version 1.15 of Aurora, we are using a cluster patching model where all nodes in an Aurora DB cluster are patched at the same time. Updates require a database restart, so you will experience 20 to 30 seconds of downtime, after which you can resume using your DB cluster or clusters. If your DB clusters are currently running Aurora 1.14 or Aurora 1.14.1, the zero-downtime patching feature in Aurora MySQL might allow client connections to your Aurora MySQL primary instance to persist through the upgrade, depending on your workload.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
## Zero-downtime patching
The zero-downtime patching (ZDP) feature attempts, on a *best-effort* basis, to preserve client connections through an engine patch. For more information about ZDP, see [ Using zero-downtime patching](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html#AuroraMySQL.Updates.ZDP) in the *Amazon Aurora User Guide*.
## New features
+ **Asynchronous Key Prefetch** – Asynchronous key prefetch (AKP) is a feature targeted to improve the performance of non-cached index joins, by prefetching keys in memory ahead of when they are needed. The primary use case targeted by AKP is an index join between a small outer and large inner table, where the index is highly selective on the larger table. Also, when the Multi-Range Read (MRR) interface is enabled, AKP will be leveraged for a secondary to primary index lookup. Smaller instances which have memory constraints might in some cases be able to leverage AKP, given the right key cardinality. For more information, see [ Optimizing Aurora indexed join queries with asynchronous key prefetch](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.BestPractices.html#Aurora.BestPractices.AKP) in the *Amazon Aurora User Guide*.
+ **Fast DDL** – We have extended the feature that was released in [Aurora 1.13](AuroraMySQL.Updates.20170515.md) to operations that include default values. With this extension, Fast DDL is applicable for operations that add a nullable column at the end of a table, with or without default values. The feature remains under Aurora lab mode. For more information, see [ Altering tables in Amazon Aurora using fast DDL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.FastDDL.html) in the *Amazon Aurora User Guide*.
## Improvements
+ Fixed a calculation error during optimization of WITHIN/CONTAINS spatial queries which previously resulted in an empty result set.
+ Fixed `SHOW VARIABLE` command to show the updated `innodb_buffer_pool_size` parameter value whenever it is changed in the parameter group.
+ Improved stability of primary instance during bulk insert into a table altered using Fast DDL when adaptive hash indexing is disabled and the record to be inserted is the first record of a page.
+ Improved stability of Aurora when the user attempts to set **server\$1audit\$1events** DB cluster parameter value to **default**.
+ Fixed an issue in which a database character set change for an ALTER TABLE statement that ran on the Aurora primary instance was not being replicated on the Aurora Replicas until they were restarted.
+ Improved stability by fixing a race condition on the primary instance which previously allowed it to register an Aurora Replica even if the primary instance had closed its own volume.
+ Improved performance of the primary instance during index creation on a large table by changing the locking protocol to enable concurrent data manipulation language (DML) statements during index build.
+ Fixed InnoDB metadata inconsistency during ALTER TABLE RENAME query which improved stability. Example: When columns of table t1(c1, c2) are renamed cyclically to t1(c2,c3) within the same ALTER statement.
+ Improved stability of Aurora Replicas for the scenario where an Aurora Replica has no active workload and the primary instance is unresponsive.
+ Improved availability of Aurora Replicas for a scenario in which the Aurora Replica holds an explicit lock on a table and blocks the replication thread from applying any DDL changes received from the primary instance.
+ Improved stability of the primary instance when a foreign key and a column are being added to a table from two separate sessions at the same time and Fast DDL has been enabled.
+ Improved stability of the purge thread on the primary instance during a heavy write workload by blocking truncate of undo records until they have been purged.
+ Improved stability by fixing the lock release order during commit process of transactions which drop tables.
+ Fixed a defect for Aurora Replicas in which the DB instance could not complete startup and complained that port 3306 was already in use.
+ Fixed a race condition in which a SELECT query run on certain information\$1schema tables (innodb\$1trx, innodb\$1lock, innodb\$1lock\$1waits) increased cluster instability.
## Integration of MySQL bug fixes
+ CREATE USER accepts plugin and password hash, but ignores the password hash (Bug \$178033)
+ The partitioning engine adds fields to the read bit set to be able to return entries sorted from a partitioned index. This leads to the join buffer will try to read unneeded fields. Fixed by not adding all partitioning fields to the read\$1set,but instead only sort on the already set prefix fields in the read\$1set. Added a DBUG\$1ASSERT that if doing key\$1cmp, at least the first field must be read (Bug \$116367691).
+ MySQL instance stalling "doing SYNC index" (Bug \$173816)
+ Assert RBT\$1EMPTY(INDEX\$1CACHE->WORDS) in ALTER TABLE CHANGE COLUMN (Bug \$117536995)
+ InnoDB Fulltext search doesn't find records when savepoints are involved (Bug \$170333)
# Aurora MySQL database engine updates: 2018-03-13 (version 1.14.4) (Deprecated)
**Version:** 1.14.4
Aurora MySQL 1.14.4 is generally available. You can create new DB clusters in Aurora 1.14.4, using the AWS CLI or the Amazon RDS API and specifying the engine version. You have the option, but are not required, to upgrade existing 1.14.x DB clusters to Aurora 1.14.4.
With version 1.14.4 of Aurora, we are using a cluster-patching model where all nodes in an Aurora DB cluster are patched at the same time. We support zero-downtime patching, which works on a best-effort basis to preserve client connections through the patching process. For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) 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](https://aws.amazon.com/support). For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
## Zero-downtime patching
The zero-downtime patching (ZDP) feature attempts, on a *best-effort* basis, to preserve client connections through an engine patch. For more information about ZDP, see [ Using zero-downtime patching](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html#AuroraMySQL.Updates.ZDP) in the *Amazon Aurora User Guide*.
## New features
+ Aurora MySQL now supports db.r4 instance classes.
## Improvements
+ Fixed an issue where `LOST_EVENTS` were generated when writing large binlog events.
## Integration of MySQL bug fixes
+ Ignorable events don't work and are not tested (Bug \$174683)
+ NEW->OLD ASSERT FAILURE 'GTID\$1MODE > 0' (Bug \$120436436)
# Aurora MySQL database engine updates: 2017-09-22 (version 1.14.1) (Deprecated)
**Version:** 1.14.1
Aurora MySQL 1.14.1 is generally available. All new database clusters, including those restored from snapshots, will be created in Aurora MySQL 1.14.1. Aurora MySQL 1.14.1 is also a mandatory upgrade for existing Aurora MySQL DB clusters. For more information, see [Announcement: Extension to mandatory upgrade schedule for Amazon Aurora](https://forums.aws.amazon.com/ann.jspa?annID=4983) on the AWS Developer Forums website.
With version 1.14.1 of Aurora MySQL, we are using a cluster patching model where all nodes in an Aurora MySQL DB cluster are patched at the same time. Updates require a database restart, so you will experience 20 to 30 seconds of downtime, after which you can resume using your DB cluster or clusters. If your DB clusters are currently running version 1.13 or greater, the zero-downtime patching feature in Aurora MySQL might allow client connections to your Aurora MySQL primary instance to persist through the upgrade, depending on your workload.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support).
## Improvements
+ Fixed race conditions associated with inserts and purge to improve the stability of the Fast DDL feature, which remains in Aurora MySQL lab mode.
# Aurora MySQL database engine updates: 2017-08-07 (version 1.14) (Deprecated)
**Version:** 1.14
Aurora MySQL 1.14 is generally available. All new database clusters, including those restored from snapshots, will be created in Aurora MySQL 1.14. Aurora MySQL 1.14 is also a mandatory upgrade for existing Aurora MySQL DB clusters. We will send a separate announcement with the timeline for deprecating earlier versions of Aurora MySQL.
With version 1.14 of Aurora MySQL, we are using a cluster patching model where all nodes in an Aurora DB cluster are patched at the same time. Updates require a database restart, so you will experience 20 to 30 seconds of downtime, after which you can resume using your DB cluster or clusters. If your DB clusters are currently running version 1.13, Aurora's zero-downtime patching feature may allow client connections to your Aurora primary instance to persist through the upgrade, depending on your workload.
If you have any questions or concerns, AWS Support is available on the community forums and through [AWS Support](https://aws.amazon.com/support).
## Zero-downtime patching
The zero-downtime patching (ZDP) feature attempts, on a *best-effort* basis, to preserve client connections through an engine patch. For more information about ZDP, see [ Using zero-downtime patching](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html#AuroraMySQL.Updates.ZDP) in the *Amazon Aurora User Guide*.
## Improvements
+ Fixed an incorrect "record not found" error when a record is found in the secondary index but not in the primary index.
+ Fixed a stability issue that can occur due to a defensive assertion (added in 1.12) that was too strong in the case when an individual write spans over 32 pages. Such a situation can occur, for instance, with large BLOB values.
+ Fixed a stability issue because of inconsistencies between the tablespace cache and the dictionary cache.
+ Fixed an issue in which an Aurora Replica becomes unresponsive after it has exceeded the maximum number of attempts to connect to the primary instance. An Aurora Replica now restarts if the period of inactivity is more than the heartbeat time period used for health check by the primary instance.
+ Fixed a livelock that can occur under very high concurrency when one connection tries to acquire an exclusive meta data lock (MDL) while issuing a command, such as `ALTER TABLE`.
+ Fixed a stability issue in an Aurora Read Replica in the presence of logical/parallel read ahead.
+ Improved `LOAD FROM S3` in two ways:
1. Better handling of Amazon S3 timeout errors by using the SDK retry in addition to the existing retry.
1. Performance optimization when loading very big files or large numbers of files by caching and reusing client state.
+ Fixed the following stability issues with Fast DDL for `ALTER TABLE` operations:
1. When the `ALTER TABLE` statement has multiple `ADD COLUMN` commands and the column names are not in ascending order.
1. When the name string of the column to be updated and its corresponding name string, fetched from the internal system table, differs by a null terminating character (/0).
1. Under certain B-tree split operations.
1. When the table has a variable length primary key.
+ Fixed a stability issue with Aurora Replicas when it takes too long to make its Full Text Search (FTS) index cache consistent with that of the primary instance. This can happen if a large portion of the newly created FTS index entries on the primary instance have not yet been flushed to disk.
+ Fixed a stability issue that can happen during index creation.
+ New infrastructure that tracks memory consumption per connection and associated telemetry that will be used for building out Out-Of-Memory (OOM) avoidance strategies.
+ Fixed an issue where `ANALYZE TABLE` was incorrectly allowed on Aurora Replicas. This has now been blocked.
+ Fixed a stability issue caused by a rare deadlock as a result of a race condition between logical read-ahead and purge.
## Integration of MySQL bug fixes
+ A full-text search combined with derived tables (subqueries in the `FROM` clause) caused a server exit. Now, if a full-text operation depends on a derived table, the server produces an error indicating that a full-text search cannot be done on a materialized table. (Bug \$168751, Bug \$116539903)
# Aurora MySQL database engine updates: 2017-05-15 (version 1.13) (Deprecated)
**Version:** 1.13
**Note**
We enabled a new feature - SELECT INTO OUTFILE S3 - in Aurora MySQL version 1.13 after the initial release, and have updated the release notes to reflect that change.
Aurora MySQL 1.13 is generally available. All new database clusters, including those restored from snapshots, will be created in Aurora MySQL 1.13. You have the option, but are not required, to upgrade existing database clusters to Aurora MySQL 1.13. With version 1.13 of Aurora, we are using a cluster patching model where all nodes in an Aurora DB cluster are patched at the same time. We are enabling zero-downtime patching, which works on a best-effort basis to preserve client connections through the patching process. For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
## Zero-downtime patching
The zero-downtime patching (ZDP) feature attempts, on a *best-effort* basis, to preserve client connections through an engine patch. For more information about ZDP, see [ Using zero-downtime patching](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html#AuroraMySQL.Updates.ZDP) in the *Amazon Aurora User Guide*.
## New features:
+ **SELECT INTO OUTFILE S3** – Aurora MySQL now allows you to upload the results of a query to one or more files in an Amazon S3 bucket. For more information, see [ Saving data from an Amazon Aurora MySQL DB cluster into text files in an Amazon S3 bucket](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.SaveIntoS3.html) in the *Amazon Aurora User Guide*.
## Improvements:
+ Implemented truncation of CSV format log files at engine startup to avoid long recovery time. The `general_log_backup`, `general_log`, `slow_log_backup`, and `slow_log` tables now don't survive a database restart.
+ Fixed an issue where migration of a database named **test** would fail.
+ Improved stability in the lock manager's garbage collector by reusing the correct lock segments.
+ Improved stability of the lock manager by removing invalid assertions during deadlock detection algorithm.
+ Re-enabled asynchronous replication, and fixed an associated issue which caused incorrect replica lag to be reported under no-load or read-only workload. The replication pipeline improvements that were introduced in version 1.10. These improvements were introduced in order to apply log stream updates to the buffer cache of an Aurora Replica. which helps to improve read performance and stability on Aurora Replicas.
+ Fixed an issue where autocommit=OFF leads to scheduled events being blocked and long transactions being held open until the server reboots.
+ Fixed an issue where general, audit, and slow query logs could not log queries handled by asynchronous commit.
+ Improved the performance of the logical read ahead (LRA) feature by up to 2.5 times. This was done by allowing pre-fetches to continue across intermediate pages in a B-tree.
+ Added parameter validation for audit variables to trim unnecessary spaces.
+ Fixed a regression, introduced in Aurora MySQL version 1.11, in which queries can return incorrect results when using the SQL\$1CALC\$1FOUND\$1ROWS option and invoking the FOUND\$1ROWS() function.
+ Fixed a stability issue when the Metadata Lock list was incorrectly formed.
+ Improved stability when sql\$1mode is set to PAD\$1CHAR\$1TO\$1FULL\$1LENGTH and the command `SHOW FUNCTION STATUS WHERE Db='string'` is executed.
+ Fixed a rare case when instances would not come up after Aurora version upgrade because of a false volume consistency check.
+ Fixed the performance issue, introduced in Aurora MySQL version 1.12, where the performance of the Aurora writer was reduced when users have a large number of tables.
+ Improved stability issue when the Aurora writer is configured as a binlog worker and the number of connections approaches 16,000.
+ Fixed a rare issue where an Aurora Replica could restart when a connection gets blocked waiting for Metadata Lock when running DDL on the Aurora master.
## Integration of MySQL bug fixes
+ With an empty InnoDB table, it's not possible to decrease the auto\$1increment value using an ALTER TABLE statement, even when the table is empty. (Bug \$169882)
+ MATCH() ... AGAINST queries that use a long string as an argument for AGAINST() could result in an error when run on an InnoDB table with a full-text search index. (Bug \$117640261)
+ Handling of SQL\$1CALC\$1FOUND\$1ROWS in combination with ORDER BY and LIMIT could lead to incorrect results for FOUND\$1ROWS(). (Bug \$168458, Bug \$1 16383173)
+ ALTER TABLE does not allow to change nullability of the column if foreign key exists. (Bug \$177591)
# Aurora MySQL database engine updates: 2017-04-05 (version 1.12) (Deprecated)
**Version:** 1.12
Aurora MySQL 1.12 is now the preferred version for the creation of new DB clusters, including restores from snapshots.
This is not a mandatory upgrade for existing clusters. You will have the option to upgrade existing clusters to version 1.12 after we complete the fleet-wide patch to 1.11 (see Aurora 1.11 [release notes](AuroraMySQL.Updates.20170223.md) and corresponding [forum announcement](https://forums.aws.amazon.com/ann.jspa?annID=4444)). With version 1.12 of Aurora, we are using a cluster patching model where all nodes in an Aurora DB cluster are patched at the same time. For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
## New features
+ **Fast DDL** – Aurora MySQL now allows you to execute an ALTER TABLE *tbl\$1name* ADD COLUMN *col\$1name* *column\$1definition* operation nearly instantaneously. The operation completes without requiring the table to be copied and without materially impacting other DML statements. Since it does not consume temporary storage for a table copy, it makes DDL statements practical even for large tables on small instance classes. Fast DDL is currently only supported for adding a nullable column, without a default value, at the end of a table. This feature is currently available in Aurora lab mode. For more information, see [ Altering tables in Amazon Aurora using fast DDL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.FastDDL.html) in the *Amazon Aurora User Guide*.
+ **Show volume status** – We have added a new monitoring command, SHOW VOLUME STATUS, to display the number of nodes and disks in a volume. For more information, see [ Displaying volume status for an Aurora MySQL DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.VolumeStatus.html) in the *Amazon Aurora User Guide*.
## Improvements
+ Implemented changes to lock compression to further reduce memory allocated per lock object. This improvement is available in lab mode.
+ Fixed an issue where the `trx_active_transactions` metric decrements rapidly even when the database is idle.
+ Fixed an invalid error message regarding fault injection query syntax when simulating failure in disks and nodes.
+ Fixed multiple issues related to race conditions and dead latches in the lock manager.
+ Fixed an issue causing a buffer overflow in the query optimizer.
+ Fixed a stability issue in Aurora read replicas when the underlying storage nodes experience low available memory.
+ Fixed an issue where idle connections persisted past the `wait_timeout` parameter setting.
+ Fixed an issue where `query_cache_size` returns an unexpected value after reboot of the instance.
+ Fixed a performance issue that is the result of a diagnostic thread probing the network too often in the event that writes are not progressing to storage.
## Integration of MySQL bug fixes
+ Reloading a table that was evicted while empty caused an AUTO\$1INCREMENT value to be reset. (Bug \$121454472, Bug \$177743)
+ An index record was not found on rollback due to inconsistencies in the purge\$1node\$1t structure. The inconsistency resulted in warnings and error messages such as "error in sec index entry update", "unable to purge a record", and "tried to purge sec index entry not marked for deletion". (Bug \$119138298, Bug \$170214, Bug \$121126772, Bug \$121065746)
+ Wrong stack size calculation for qsort operation leads to stack overflow. (Bug \$173979)
+ Record not found in an index upon rollback. (Bug \$170214, Bug \$172419)
+ ALTER TABLE add column TIMESTAMP on update CURRENT\$1TIMESTAMP inserts ZERO-datas (Bug \$117392)
# Aurora MySQL database engine updates: 2017-02-23 (version 1.11) (Deprecated)
**Version:** 1.11
We will patch all Aurora MySQL DB clusters with the latest version over a short period following the release. DB clusters are patched using the legacy procedure with a downtime of about 5-30 seconds.
Patching occurs during the system maintenance window that you have specified for each of your database instances. You can view or change this window using the AWS Management Console. For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
Alternatively, you can apply the patch immediately in the AWS Management Console by choosing a DB cluster, choosing **Cluster Actions**, and then choosing **Upgrade Now**.
With version 1.11 of Aurora MySQL, we are using a cluster patching model where all nodes in an Aurora DB cluster are patched at the same time.
## New features
+ **MANIFEST option for LOAD DATA FROM S3** – LOAD DATA FROM S3 was released in version 1.8. The options for this command have been expanded, and you can now specify a list of files to be loaded into an Aurora DB cluster from Amazon S3 by using a manifest file. This makes it easy to load data from specific files in one or more locations, as opposed to loading data from a single file by using the FILE option or loading data from multiple files that have the same location and prefix by using the PREFIX option. The manifest file format is the same as that used by Amazon Redshift. For more information about using LOAD DATA FROM S3 with the MANIFEST option, see [ Using a manifest to specify data files to load](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.LoadFromS3.html#AuroraMySQL.Integrating.LoadFromS3.Manifest) in the *Amazon Aurora User Guide*.
+ **Spatial indexing enabled by default** – This feature was released in lab mode in version 1.10, and is now turned on by default. Spatial indexing improves query performance on large datasets for queries that use spatial data. For more information about using spatial indexing, see [ Amazon Aurora MySQL and spatial data](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMySQL.Overview.html#Aurora.AuroraMySQL.Spatial) in the *Amazon Aurora User Guide*.
+ **Advanced Auditing timing change** – This feature was released in version 1.10.1 to provide a high-performance facility for auditing database activity. In this release, the precision of audit log timestamps has been changed from one second to one microsecond. The more accurate timestamps allow you to better understand when an audit event happened. For more information about audit, see [ Using Advanced Auditing with an Amazon Aurora MySQL DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Auditing.html) in the *Amazon Aurora User Guide*.
## Improvements
+ Modified the `thread_handling` parameter to prevent you from setting it to anything other than **multiple-connections-per-thread**, which is the only supported model with Aurora's thread pool.
+ Fixed an issue caused when you set either the `buffer_pool_size` or the `query_cache_size` parameter to be larger than the DB cluster's total memory. In this circumstance, Aurora sets the modified parameter to the default value, so the DB cluster can start up and not crash.
+ Fixed an issue in the query cache where a transaction gets stale read results if the table is invalidated in another transaction.
+ Fixed an issue where binlog files marked for deletion are removed after a small delay rather than right away.
+ Fixed an issue where a database created with the name **tmp** is treated as a system database stored on ephemeral storage and not persisted to Aurora distributed storage.
+ Modified the behavior of SHOW TABLES to exclude certain internal system tables. This change helps avoid an unnecessary failover caused by mysqldump locking all files listed in SHOW TABLES, which in turn prevents writes on the internal system table, causing the failover.
+ Fixed an issue where an Aurora Replica incorrectly restarts when creating a temporary table from a query that invokes a function whose argument is a column of an InnoDB table.
+ Fixed an issue related to a metadata lock conflict in an Aurora Replica node that causes the Aurora Replica to fall behind the primary DB cluster and eventually get restarted.
+ Fixed a dead latch in the replication pipeline in reader nodes, which causes an Aurora Replica to fall behind and eventually get restarted.
+ Fixed an issue where an Aurora Replica lags too much with encrypted volumes larger than 1 terabyte (TB).
+ Improved Aurora Replica dead latch detection by using an improved way to read the system clock time.
+ Fixed an issue where an Aurora Replica can restart twice instead of once following de-registration by the writer.
+ Fixed a slow query performance issue on Aurora Replicas that occurs when transient statistics cause statistics discrepancy on non-unique index columns.
+ Fixed an issue where an Aurora Replica can crash when a DDL statement is replicated on the Aurora Replica at the same time that the Aurora Replica is processing a related query.
+ Changed the replication pipeline improvements that were introduced in version 1.10 from enabled by default to disabled by default. These improvements were introduced in order to apply log stream updates to the buffer cache of an Aurora Replica, and although this feature helps to improve read performance and stability on Aurora Replicas, it increases replica lag in certain workloads.
+ Fixed an issue where the simultaneous occurrence of an ongoing DDL statement and pending Parallel Read Ahead on the same table causes an assertion failure during the commit phase of the DDL transaction.
+ Enhanced the general log and slow query log to survive DB cluster restart.
+ Fixed an out-of-memory issue for certain long running queries by reducing memory consumption in the ACL module.
+ Fixed a restart issue that occurs when a table has non-spatial indexes, there are spatial predicates in the query, the planner chooses to use a non-spatial index, and the planner incorrectly pushes the spatial condition down to the index.
+ Fixed an issue where the DB cluster restarts when there is a delete, update, or purge of very large geospatial objects that are stored externally (like LOBs).
+ Fixed an issue where fault simulation using ALTER SYSTEM SIMULATE ... FOR INTERVAL isn't working properly.
+ Fixed a stability issue caused by an invalid assertion on an incorrect invariant in the lock manager.
+ Disabled the following two improvements to InnoDB Full-Text Search that were introduced in version 1.10 because they introduce stability issues for some demanding workloads:
+ Updating the cache only after a read request to an Aurora Replica in order to improve full-text search index cache replication speed.
+ Offloading the cache sync task to a separate thread as soon as the cache size crosses 10% of the total size, in order to avoid MySQL queries stalling for too long during FTS cache sync to disk. (Bugs \$122516559, \$173816).
## Integration of MySQL bug fixes
+ Running ALTER table DROP foreign key simultaneously with another DROP operation causes the table to disappear. (Bug \$116095573)
+ Some INFORMATION\$1SCHEMA queries that used ORDER BY did not use a filesort optimization as they did previously. (Bug \$116423536)
+ FOUND\$1ROWS () returns the wrong count of rows on a table. (Bug \$168458)
+ The server fails instead of giving an error when too many temp tables are open. (Bug \$118948649)
# Aurora MySQL database engine updates: 2017-01-12 (version 1.10.1) (Deprecated)
**Version:** 1.10.1
Version 1.10.1 of Aurora MySQL is an opt-in version and is not used to patch your database instances. It is available for creating new Aurora instances and for upgrading existing instances. You can apply the patch by choosing a cluster in the [Amazon RDS console](https://console.aws.amazon.com/rds/), choosing **Cluster Actions**, and then choosing **Upgrade Now**. Patching requires a database restart with downtime typically lasting 5-30 seconds, after which you can resume using your DB clusters. This patch is using a cluster patching model where all nodes in an Aurora cluster are patched at the same time.
## New features
+ **Advanced Auditing** – Aurora MySQL provides a high-performance Advanced Auditing feature, which you can use to audit database activity. For more information about enabling and using Advanced Auditing, see [ Using Advanced Auditing with an Aurora MySQL DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Auditing.html) in the *Amazon Aurora User Guide*.
## Improvements
+ Fixed an issue with spatial indexing when creating a column and adding an index on it in the same statement.
+ Fixed an issue where spatial statistics aren't persisted across DB cluster restart.
# Aurora MySQL database engine updates: 2016-12-14 (version 1.10) (Deprecated)
**Version:** 1.10
## New features
+ **Zero downtime patch** – This feature allows a DB instance to be patched without any downtime. That is, database upgrades are performed without disconnecting client applications, or rebooting the database. This approach increases the availability of your Aurora DB clusters during the maintenance window. Note that temporary data like that in the performance schema is reset during the upgrade process. This feature applies to service-delivered patches during a maintenance window as well as user-initiated patches.
When a patch is initiated, the service ensures there are no open locks, transactions or temporary tables, and then waits for a suitable window during which the database can be patched and restarted. Application sessions are preserved, although there is a drop in throughput while the patch is in progress (for approximately 5 seconds). If no suitable window can be found, then patching defaults to the standard patching behavior.
Zero downtime patching takes place on a best-effort basis, subject to certain limitations as described following:
+ This feature is currently applicable for patching single-node DB clusters or writer instances in multi-node DB clusters.
+ SSL connections are not supported in conjunction with this feature. If there are active SSL connections, Amazon Aurora MySQL won't perform a zero downtime patch, and instead will retry periodically to see if the SSL connections have terminated. If they have, zero downtime patching proceeds. If the SSL connections persist after more than a couple seconds, standard patching with downtime proceeds.
+ The feature is available in Aurora release 1.10 and beyond. Going forward, we will identify any releases or patches that can't be applied by using zero downtime patching.
+ This feature is not applicable if replication based on binary logging is active.
+ **Spatial indexing ** – Spatial indexing improves query performance on large datasets for queries that use spatial data. For more information about using spatial indexing, see [ Amazon Aurora MySQL and spatial data](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMySQL.Overview.html#Aurora.AuroraMySQL.Spatial) in the *Amazon Aurora User Guide*.
This feature is disabled by default and can be activated by enabling Aurora lab mode. For information, see [ Amazon Aurora MySQL lab mode](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.LabMode.html) in the *Amazon Aurora User Guide*.
+ **Replication pipeline improvements** – Aurora MySQL now uses an improved mechanism to apply log stream updates to the buffer cache of an Aurora Replica. This feature improves the read performance and stability on Aurora Replicas when there is a heavy write load on the master as well as a significant read load on the Replica. This feature is enabled by default.
+ **Throughput improvement for workloads with cached reads** – Aurora MySQL now uses a latch-free concurrent algorithm to implement read views, which leads to better throughput for read queries served by the buffer cache. As a result of this and other improvements, Amazon Aurora MySQL can achieve throughput of up to 625K reads per second compared to 164K reads per second by MySQL 5.7 for a SysBench SELECT-only workload.
+ **Throughput improvement for workloads with hot row contention** – Aurora MySQL uses a new lock release algorithm that improves performance, particularly when there is hot page contention (that is, many transactions contending for the rows on the same page). In tests with the TPC-C benchmark, this can result in up to16x throughput improvement in transactions per minute relative to MySQL 5.7. This feature is disabled by default and can be activated by enabling Aurora lab mode. For information, see [ Amazon Aurora MySQL lab mode](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.LabMode.html) in the *Amazon Aurora User Guide*.
## Improvements
+ Full-text search index cache replication speed has been improved by updating the cache only after a read request to an Aurora Replica. This approach avoids any reads from disk by the replication thread.
+ Fixed an issue where dictionary cache invalidation does not work on an Aurora Replica for tables that have a special character in the database name or table name.
+ Fixed a `STUCK IO` issue during data migration for distributed storage nodes when storage heat management is enabled.
+ Fixed an issue in the lock manager where an assertion check fails for the transaction lock wait thread when preparing to rollback or commit a transaction.
+ Fixed an issue when opening a corrupted dictionary table by correctly updating the reference count to the dictionary table entries.
+ Fixed a bug where the DB cluster minimum read point can be held by slow Aurora Replicas.
+ Fixed a potential memory leak in the query cache.
+ Fixed a bug where an Aurora Replica places a row-level lock on a table when a query is used in an `IF` statement of a stored procedure.
## Integration of MySQL bug fixes
+ UNION of derived tables returns wrong results with '1=0/false'-clauses. (Bug \$169471)
+ Server crashes in ITEM\$1FUNC\$1GROUP\$1CONCAT::FIX\$1FIELDS on 2nd execution of stored procedure. (Bug \$120755389)
+ Avoid MySQL queries from stalling for too long during FTS cache sync to disk by offloading the cache sync task to a separate thread, as soon as the cache size crosses 10% of the total size. (Bug \$122516559, \$173816)
# Aurora MySQL database engine updates: 2016-11-10 (versions 1.9.0, 1.9.1) (Deprecated)
**Version:** 1.9.0, 1.9.1
## New features
+ **Improved index build** – The implementation for building secondary indexes now operates by building the index in a bottom-up fashion, which eliminates unnecessary page splits. This can reduce the time needed to create an index or rebuild a table by up to 75% (based on an `db.r3.8xlarge` DB instance class). This feature was in lab mode in Aurora MySQL version 1.7 and is enabled by default in Aurora version 1.9 and later. For information, see [ Amazon Aurora MySQL lab mode](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.LabMode.html) in the *Amazon Aurora User Guide*.
+ **Lock compression (lab mode)** – This implementation significantly reduces the amount of memory that lock manager consumes by up to 66%. Lock manager can acquire more row locks without encountering an out-of-memory exception. This feature is disabled by default and can be activated by enabling Aurora lab mode. For information, see [ Amazon Aurora MySQL lab mode](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.LabMode.html) in the *Amazon Aurora User Guide*.
+ **Performance schema** – Aurora MySQL now includes support for performance schema with minimal impact on performance. In our testing using SysBench, enabling performance schema could degrade MySQL performance by up to 60%.
SysBench testing of an Aurora DB cluster showed an impact on performance that is 4x less than MySQL. Running the `db.r3.8xlarge` DB instance class resulted in 100K SQL writes/sec and over 550K SQL reads/sec, even with performance schema enabled.
+ **Hot row contention improvement** – This feature reduces CPU utilization and increases throughput when a small number of hot rows are accessed by a large number of connections. This feature also eliminates ` error 188` when there is hot row contention.
+ **Improved out-of-memory handling** – When non-essential, locking SQL statements are executed and the reserved memory pool is breached, Aurora forces rollback of those SQL statements. This feature frees memory and prevents engine crashes due to out-of-memory exceptions.
+ **Smart read selector** – This implementation improves read latency by choosing the optimal storage segment among different segments for every read, resulting in improved read throughput. SysBench testing has shown up to a 27% performance increase for write workloads .
## Improvements
+ Fixed an issue where an Aurora Replica encounters a shared lock during engine start up.
+ Fixed a potential crash on an Aurora Replica when the read view pointer in the purge system is NULL.
# Aurora MySQL database engine updates: 2016-10-26 (version 1.8.1) (Deprecated)
**Version:** 1.8.1
## Improvements
+ Fixed an issue where bulk inserts that use triggers that invoke AWS Lambda procedures fail.
+ Fixed an issue where catalog migration fails when autocommit is off globally.
+ Resolved a connection failure to Aurora when using SSL and improved Diffie-Hellman group to deal with LogJam attacks.
## Integration of MySQL bug fixes
+ OpenSSL changed the Diffie-Hellman key length parameters due to the LogJam issue. (Bug \$118367167)
# Aurora MySQL database engine updates: 2016-10-18 (version 1.8) (Deprecated)
**Version:** 1.8
## New features
+ **AWS Lambda integration** – You can now asynchronously invoke an AWS Lambda function from an Aurora DB cluster using the `mysql.lambda_async` procedure. For more information, see [ Invoking a Lambda function from an Amazon Aurora MySQL DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.Lambda.html) in the *Amazon Aurora User Guide*.
+ **Load data from Amazon S3** – You can now load text or XML files from an Amazon S3 bucket into your Aurora DB cluster using the `LOAD DATA FROM S3` or `LOAD XML FROM S3` commands. For more information, see [ Loading data into an Amazon Aurora MySQL DB cluster from text files in an Amazon S3 bucket](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.LoadFromS3.html) in the *Amazon Aurora User Guide*.
+ **Catalog migration** – Aurora now persists catalog metadata in the cluster volume to support versioning. This enables seamless catalog migration across versions and restores.
+ **Cluster-level maintenance and patching** – Aurora now manages maintenance updates for an entire DB cluster. For more information, see [ Maintaining an Amazon Aurora DB cluster](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html) in the *Amazon Aurora User Guide*.
## Improvements
+ Fixed an issue where an Aurora Replica crashes when not granting a metadata lock to an inflight DDL table.
+ Allowed Aurora Replicas to modify non-InnoDB tables to facilitate rotation of the slow and general log CSV files where `log_output=TABLE`.
+ Fixed a lag when updating statistics from the primary instance to an Aurora Replica. Without this fix, the statistics of the Aurora Replica can get out of sync with the statistics of the primary instance and result in a different (and possibly under-performing) query plan on an Aurora Replica.
+ Fixed a race condition that ensures that an Aurora Replica does not acquire locks.
+ Fixed a rare scenario where an Aurora Replica that registers or de-registers with the primary instance could fail.
+ Fixed a race condition that could lead to a deadlock on `db.r3.large` instances when opening or closing a volume.
+ Fixed an out-of-memory issue that can occur due to a combination of a large write workload and failures in the Aurora Distributed Storage service.
+ Fixed an issue with high CPU consumption because of the purge thread spinning in the presence of a long-running transaction.
+ Fixed an issue when running information schema queries to get information about locks under heavy load.
+ Fixed an issue with a diagnostics process that could in rare cases cause Aurora writes to storage nodes to stall and restart/fail-over.
+ Fixed a condition where a successfully created table might be deleted during crash recovery if the crash occurred while a `CREATE TABLE [if not exists]` statement was being handled.
+ Fixed a case where the log rotation procedure is broken when the general log and slow log are not stored on disk using catalog mitigation.
+ Fixed a crash when a user creates a temporary table within a user defined function, and then uses the user defined function in the select list of the query.
+ Fixed a crash that occurred when replaying GTID events. GTID is not supported by Aurora MySQL.
## Integration of MySQL bug fixes:
+ When dropping all indexes on a column with multiple indexes, InnoDB failed to block a DROP INDEX operation when a foreign key constraint requires an index. (Bug \$116896810)
+ Solve add foreign key constraint crash. (Bug \$116413976)
+ Fixed a crash when fetching a cursor in a stored procedure, and analyzing or flushing the table at the same time. (Bug \$1 18158639)
+ Fixed an auto-increment bug when a user alters a table to change the AUTO\$1INCREMENT value to less than the maximum auto-increment column value. (Bug \$1 16310273)
# Aurora MySQL database engine updates: 2016-09-20 (version 1.7.1) (Deprecated)
**Version:** 1.7.1
## Improvements
+ Fixes an issue where an Aurora Replica crashes if the InnoDB full-text search cache is full.
+ Fixes an issue where the database engine crashes if a worker thread in the thread pool waits for itself.
+ Fixes an issue where an Aurora Replica crashes if a metadata lock on a table causes a deadlock.
+ Fixes an issue where the database engine crashes due to a race condition between two worker threads in the thread pool.
+ Fixes an issue where an unnecessary failover occurs under heavy load if the monitoring agent doesn't detect the advancement of write operations to the distributed storage subsystem.
# Aurora MySQL database engine updates: 2016-08-30 (version 1.7.0) (Deprecated)
**Version:** 1.7.0
## New features
+ **NUMA aware scheduler** – The task scheduler for the Aurora MySQL engine is now Non-Uniform Memory Access (NUMA) aware. This minimizes cross-CPU socket contention resulting in improved performance throughput for the `db.r3.8xlarge` DB instance class.
+ **Parallel read-ahead operates asynchronously in the background** – Parallel read-ahead has been revised to improve performance by using a dedicated thread to reduce thread contention.
+ **Improved index build (lab mode)** – The implementation for building secondary indexes now operates by building the index in a bottom-up fashion, which eliminates unnecessary page splits. This can reduce the time needed to create an index or rebuild a table. This feature is disabled by default and can be activated by enabling Aurora lab mode. For information, see [ Amazon Aurora MySQL lab mode](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.LabMode.html) in the *Amazon Aurora User Guide*.
## Improvements
+ Fixed an issue where establishing a connection was taking a long time if there was a surge in the number of connections requested for an instance.
+ Fixed an issue where a crash occurred if ALTER TABLE was run on a partitioned table that did not use InnoDB.
+ Fixed an issue where heavy write workload can cause a failover.
+ Fixed an erroneous assertion that caused a failure if RENAME TABLE was run on a partitioned table.
+ Improved stability when rolling back a transaction during insert-heavy workload.
+ Fixed an issue where full-text search indexes were not viable on an Aurora Replica.
## Integration of MySQL bug fixes
+ Improve scalability by partitioning LOCK\$1grant lock. (Port WL \$18355)
+ Opening cursor on SELECT in stored procedure causes segfault. (Port Bug \$116499751)
+ MySQL gives the wrong result with some special usage. (Bug \$111751794)
+ Crash in GET\$1SEL\$1ARG\$1FOR\$1KEYPART – caused by patch for bug \$111751794. (Bug \$116208709)
+ Wrong results for a simple query with GROUP BY. (Bug \$117909656)
+ Extra rows on semijoin query with range predicates. (Bug \$116221623)
+ Adding an ORDER BY clause following an IN subquery could cause duplicate rows to be returned. (Bug \$116308085)
+ Crash with explain for a query with loose scan for GROUP BY, MyISAM. (Bug \$116222245)
+ Loose index scan with quoted int predicate returns random data. (Bug \$116394084)
+ If the optimizer was using a loose index scan, the server could exit while attempting to create a temporary table. (Bug \$116436567)
+ COUNT(DISTINCT) should not count NULL values, but they were counted when the optimizer used loose index scan. (Bug \$117222452)
+ If a query had both MIN()/MAX() and aggregate\$1function(DISTINCT) (for example, SUM(DISTINCT)) and was executed using loose index scan, the result values of MIN()/MAX() were set improperly. (Bug \$117217128)
# Aurora MySQL database engine updates: 2016-06-01 (version 1.6.5) (Deprecated)
**Version:** 1.6.5
## New features
+ **Efficient storage of Binary Logs** – Efficient storage of binary logs is now enabled by default for all Aurora MySQL DB clusters, and is not configurable. Efficient storage of binary logs was introduced in the April 2016 update. For more information, see [Aurora MySQL database engine updates: 2016-04-06 (version 1.6) (Deprecated)](AuroraMySQL.Updates.20160406.md).
## Improvements
+ Improved stability for Aurora Replicas when the primary instance is encountering a heavy workload.
+ Improved stability for Aurora Replicas when running queries on partitioned tables and tables with special characters in the table name.
+ Fixed connection issues when using secure connections.
## Integration of MySQL bug fixes
+ SLAVE CAN'T CONTINUE REPLICATION AFTER MASTER'S CRASH RECOVERY (Port Bug \$117632285)
# Aurora MySQL database engine updates: 2016-04-06 (version 1.6) (Deprecated)
**Version:** 1.6
This update includes the following improvements:
## New features
+ **Parallel read-ahead** – Parallel read-ahead is now enabled by default for all Aurora MySQL DB clusters, and is not configurable. Parallel read-ahead was introduced in the December 2015 update. For more information, see [Aurora MySQL database engine updates: 2015-12-03 (version 1.4) (Deprecated)](AuroraMySQL.Updates.20151203.md).
In addition to enabling parallel read-ahead by default, this release includes the following improvements to parallel read-ahead:
+ Improved logic so that parallel read-ahead is less aggressive, which is beneficial when your DB cluster encounters many parallel workloads.
+ Improved stability on smaller tables.
+ **Efficient storage of Binary Logs (lab mode)** – MySQL binary log files are now stored more efficiently in Aurora MySQL. The new storage implementation enables binary log files to be deleted much earlier and improves system performance for an instance in an Aurora MySQL DB cluster that is a binary log replication master.
To enable efficient storage of binary logs, set the `aurora_lab_mode` parameter to `1` in the parameter group for your primary instance or Aurora Replica. The `aurora_lab_mode` parameter is an instance-level parameter that is in the `default.aurora5.6` parameter group by default. For information on modifying a DB parameter group, see [ Modifying parameters in a DB parameter group](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_WorkingWithParamGroups.html#USER_WorkingWithParamGroups.Modifying) in the *Amazon Aurora User Guide*. For information on parameter groups and Aurora MySQL, see [ Aurora MySQL configuration parameters](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Reference.html#AuroraMySQL.Reference.ParameterGroups) in the *Amazon Aurora User Guide*.
Only turn on efficient storage of binary logs for instances in an Aurora MySQL DB cluster that are MySQL binary log replication master instances.
+ **AURORA\$1VERSION system variable** – You can now get the Aurora version of your Aurora MySQL DB cluster by querying for the `AURORA_VERSION` system variable.
To get the Aurora version, use one of the following queries:
```
select AURORA_VERSION();
select @@aurora_version;
show variables like '%version';
```
You can also see the Aurora version in the AWS Management Console when you modify a DB cluster, or by calling the [describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI command or the [DescribeDBEngineVersions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBEngineVersions.html) API operation.
+ **Lock manager memory usage metric** – Information about lock manager memory usage is now available as a metric.
To get the lock manager memory usage metric, use one of the following queries:
```
show global status where variable_name in ('aurora_lockmgr_memory_used');
select * from INFORMATION_SCHEMA.GLOBAL_STATUS where variable_name in ('aurora_lockmgr_memory_used');
```
## Improvements
+ Improved stability during binlog and XA transaction recovery.
+ Fixed a memory issue resulting from a large number of connections.
+ Improved accuracy in the following metrics: `Read Throughput`,` Read IOPS`, `Read Latency`, `Write Throughput`, `Write IOPS`, `Write Latency`, and `Disk Queue Depth`.
+ Fixed a stability issue causing slow startup for large instances after a crash.
+ Improved concurrency in the data dictionary regarding synchronization mechanisms and cache eviction.
+ Stability and performance improvements for Aurora Replicas:
+ Fixed a stability issue for Aurora Replicas during heavy or burst write workloads for the primary instance.
+ Improved replica lag for db.r3.4xlarge and db.r3.8xlarge instances.
+ Improved performance by reducing contention between application of log records and concurrent reads on an Aurora Replica.
+ Fixed an issue for refreshing statistics on Aurora Replicas for newly created or updated statistics.
+ Improved stability for Aurora Replicas when there are many transactions on the primary instance and concurrent reads on the Aurora Replicas across the same data.
+ Improved stability for Aurora Replicas when running `UPDATE` and `DELETE` statements with `JOIN` statements.
+ Improved stability for Aurora Replicas when running `INSERT ... SELECT` statements.
## Integration of MySQL bug fixes
+ BACKPORT Bug \$118694052 FIX FOR ASSERTION `\$1M\$1ORDERED\$1REC\$1BUFFER' FAILED TO 5.6 (Port Bug \$118305270)
+ SEGV IN MEMCPY(), HA\$1PARTITION::POSITION (Port Bug \$1 18383840)
+ WRONG RESULTS WITH PARTITIONING,INDEX\$1MERGE AND NO PK (Port Bug \$1 18167648)
+ FLUSH TABLES FOR EXPORT: ASSERTION IN HA\$1PARTITION::EXTRA (Port Bug \$1 16943907)
+ SERVER CRASH IN VIRTUAL HA\$1ROWS HANDLER::MULTI\$1RANGE\$1READ\$1INFO\$1CONST (Port Bug \$1 16164031)
+ RANGE OPTIMIZER CRASHES IN SEL\$1ARG::RB\$1INSERT() (Port Bug \$1 16241773)
# Aurora MySQL database engine updates: 2016-01-11 (version 1.5) (Deprecated)
**Version:** 1.5
This update includes the following improvements:
## Improvements
+ Fixed a 10 second pause of write operations for idle instances during Aurora storage deployments.
+ Logical read-ahead now works when `innodb_file_per_table` is set to `No`. For more information on logical read-ahead, see [Aurora MySQL database engine updates: 2015-12-03 (version 1.4) (Deprecated)](AuroraMySQL.Updates.20151203.md).
+ Fixed issues with Aurora Replicas reconnecting with the primary instance. This improvement also fixes an issue when you specify a large value for the `quantity` parameter when testing Aurora Replica failures using fault-injection queries. For more information, see [ Testing an Aurora replica failure](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.FaultInjectionQueries.html#AuroraMySQL.Managing.FaultInjectionQueries.ReplicaFailure) in the *Amazon Aurora User Guide*.
+ Improved monitoring of Aurora Replicas falling behind and restarting.
+ Fixed an issue that caused an Aurora Replica to lag, become deregistered, and then restart.
+ Fixed an issue when you run the `show innodb status` command during a deadlock.
+ Fixed an issue with failovers for larger instances during high write throughput.
## Integration of MySQL bug fixes
+ Addressed incomplete fix in MySQL full text search affecting tables where the database name begins with a digit. (Port Bug \$117607956)
# Aurora MySQL database engine updates: 2015-12-03 (version 1.4) (Deprecated)
**Version:** 1.4
This update includes the following improvements:
## New features
+ **Fast Insert** – Accelerates parallel inserts sorted by primary key. For more information, see [ Amazon Aurora MySQL performance enhancements](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.AuroraMySQL.Overview.html#Aurora.AuroraMySQL.Performance) in the *Amazon Aurora User Guide*.
+ **Large dataset read performance** – Aurora MySQL automatically detects an IO heavy workload and launches more threads in order to boost the performance of the DB cluster. The Aurora scheduler looks into IO activity and decides to dynamically adjust the optimal number of threads in the system, quickly adjusting between IO heavy and CPU heavy workloads with low overhead.
+ **Parallel read-ahead** – Improves the performance of B-Tree scans that are too large for the memory available on your primary instance or Aurora Replica (including range queries). Parallel read-ahead automatically detects page read patterns and pre-fetches pages into the buffer cache in advance of when they are needed. Parallel read-ahead works multiple tables at the same time within the same transaction.
## Improvements:
+ Fixed brief Aurora database availability issues during Aurora storage deployments.
+ Correctly enforce the `max_connection` limit.
+ Improve binlog purging where Aurora is the binlog master and the database is restarting after a heavy data load.
+ Fixed memory management issues with the table cache.
+ Add support for huge pages in shared memory buffer cache for faster recovery.
+ Fixed an issue with thread-local storage not being initialized.
+ Allow 16K connections by default.
+ Dynamic thread pool for IO heavy workloads.
+ Fixed an issue with properly invalidating views involving UNION in the query cache.
+ Fixed a stability issue with the dictionary stats thread.
+ Fixed a memory leak in the dictionary subsystem related to cache eviction.
+ Fixed high read latency issue on Aurora Replicas when there is very low write load on the master.
+ Fixed stability issues on Aurora Replicas when performing operations on DDL partitioned tables such as ALTER TABLE ... REORGANIZE PARTITION on the master.
+ Fixed stability issues on Aurora Replicas during volume growth.
+ Fixed performance issue for scans on non-clustered indexes in Aurora Replicas.
+ Fix stability issue that makes Aurora Replicas lag and eventually get deregistered and re-started.
## Integration of MySQL bug fixes
+ SEGV in FTSPARSE(). (Bug \$116446108)
+ InnoDB data dictionary is not updated while renaming the column. (Bug \$119465984)
+ FTS crash after renaming table to different database. (Bug \$116834860)
+ Failed preparing of trigger on truncated tables cause error 1054. (Bug \$118596756)
+ Metadata changes might cause problems with trigger execution. (Bug \$118684393)
+ Materialization is not chosen for long UTF8 VARCHAR field. (Bug \$117566396)
+ Poor execution plan when ORDER BY with limit X. (Bug \$116697792)
+ Backport bug \$111765744 TO 5.1, 5.5 AND 5.6. (Bug \$117083851)
+ Mutex issue in SQL/SQL\$1SHOW.CC resulting in SIG6. Source likely FILL\$1VARIABLES. (Bug \$120788853)
+ Backport bug \$118008907 to 5.5\$1 versions. (Bug \$118903155)
+ Adapt fix for a stack overflow error in MySQL 5.7. (Bug \$119678930)
# Aurora MySQL database engine updates: 2015-10-16 (versions 1.2, 1.3) (Deprecated)
**Versions:** 1.2, 1.3
This update includes the following improvements:
## Fixes
+ Resolved out-of-memory issue in the new lock manager with long-running transactions
+ Resolved security vulnerability when replicating with non-RDS for MySQL databases
+ Updated to ensure that quorum writes retry correctly with storage failures
+ Updated to report replica lag more accurately
+ Improved performance by reducing contention when many concurrent transactions are trying to modify the same row
+ Resolved query cache invalidation for views that are created by joining two tables
+ Disabled query cache for transactions with `UNCOMMITTED_READ` isolation
## Improvements
+ Better performance for slow catalog queries on warm caches
+ Improved concurrency in dictionary statistics
+ Better stability for the new query cache resource manager, extent management, files stored in Amazon Aurora smart storage, and batch writes of log records
## Integration of MySQL bug fixes
+ Killing a query inside innodb causes it to eventually crash with an assertion. (Bug \$11608883)
+ For failure to create a new thread for the event scheduler, event execution, or new connection, no message was written to the error log. (Bug \$116865959)
+ If one connection changed its default database and simultaneously another connection executed SHOW PROCESSLIST, the second connection could access invalid memory when attempting to display the first connection's default database memory. (Bug \$111765252)
+ PURGE BINARY LOGS by design does not remove binary log files that are in use or active, but did not provide any notice when this occurred. (Bug \$113727933)
+ For some statements, memory leaks could result when the optimizer removed unneeded subquery clauses. (Bug \$115875919)
+ During shutdown, the server could attempt to lock an uninitialized mutex. (Bug \$116016493)
+ A prepared statement that used GROUP\$1CONCAT() and an ORDER BY clause that named multiple columns could cause the server to exit. ( Bug \$116075310)
+ Performance Schema instrumentation was missing for replica worker threads. (Bug \$116083949)
+ `STOP SLAVE` could cause a deadlock when issued concurrently with a statement such as SHOW STATUS that retrieved the values for one or more of the status variables `Slave_retried_transactions`, `Slave_heartbeat_period`, `Slave_received_heartbeats`, `Slave_last_heartbeat`, or `Slave_running`. (Bug \$116088188)
+ A full-text query using Boolean mode could return zero results in some cases where the search term was a quoted phrase. (Bug \$116206253)
+ The optimizer's attempt to remove redundant subquery clauses raised an assertion when executing a prepared statement with a subquery in the ON clause of a join in a subquery. (Bug \$116318585)
+ GROUP\$1CONCAT unstable, crash in ITEM\$1SUM::CLEAN\$1UP\$1AFTER\$1REMOVAL. (Bug \$116347450)
+ Attempting to replace the default InnoDB full-text search (FTS) stopword list by creating an InnoDB table with the same structure as INFORMATION\$1SCHEMA.INNODB\$1FT\$1DEFAULT\$1STOPWORD would result in an error. (Bug \$116373868)
+ After the client thread on a worker performed a FLUSH TABLES WITH READ LOCK and was followed by some updates on the master, the worker hung when executing `SHOW SLAVE STATUS`. (Bug \$116387720)
+ When parsing a delimited search string such as "abc-def" in a full-text search, InnoDB now uses the same word delimiters as MyISAM. (Bug \$116419661)
+ Crash in FTS\$1AST\$1TERM\$1SET\$1WILDCARD. (Bug \$116429306)
+ SEGFAULT in FTS\$1AST\$1VISIT() for FTS RQG test. (Bug \$1 16435855)
+ For debug builds, when the optimizer removed an Item\$1ref pointing to a subquery, it caused a server exit. (Bug \$116509874)
+ Full-text search on InnoDB tables failed on searches for literal phrases combined with \$1 or - operators. (Bug \$116516193)
+ `START SLAVE` failed when the server was started with the options --master-info-repository=TABLE relay-log-info-repository=TABLE and with autocommit set to 0, together with `--skip-slave-start`. (Bug \$116533802)
+ Very large InnoDB full-text search (FTS) results could consume an excessive amount of memory. (Bug \$116625973)
+ In debug builds, an assertion could occur in OPT\$1CHECK\$1ORDER\$1BY when using binary directly in a search string, as binary might include NULL bytes and other non-meaningful characters. (Bug \$116766016)
+ For some statements, memory leaks could result when the optimizer removed unneeded subquery clauses. (Bug \$116807641)
+ It was possible to cause a deadlock after issuing FLUSH TABLES WITH READ LOCK by issuing `STOP SLAVE` in a new connection to the worker, then issuing `SHOW SLAVE STATUS` using the original connection. (Bug \$116856735)
+ GROUP\$1CONCAT() with an invalid separator could cause a server exit. (Bug \$116870783)
+ The server did excessive locking on the LOCK\$1active\$1mi and active\$1mi->rli->data\$1lock mutexes for any SHOW STATUS LIKE 'pattern' statement, even when the pattern did not match status variables that use those mutexes (`Slave_heartbeat_period`, `Slave_last_heartbeat`, `Slave_received_heartbeats`, `Slave_retried_transactions`, `Slave_running`). (Bug \$116904035)
+ A full-text search using the IN BOOLEAN MODE modifier would result in an assertion failure. (Bug \$116927092)
+ Full-text search on InnoDB tables failed on searches that used the \$1 boolean operator. (Bug \$117280122)
+ 4-way deadlock: zombies, purging binlogs, show processlist, show binlogs. (Bug \$117283409)
+ When an SQL thread which was waiting for a commit lock was killed and restarted it caused a transaction to be skipped on worker. (Bug \$117450876)
+ An InnoDB full-text search failure would occur due to an "unended" token. The string and string length should be passed for string comparison. (Bug \$117659310)
+ Large numbers of partitioned InnoDB tables could consume much more memory when used in MySQL 5.6 or 5.7 than the memory used by the same tables used in previous releases of the MySQL Server. (Bug \$117780517)
+ For full-text queries, a failure to check that num\$1token is less than max\$1proximity\$1item could result in an assertion. (Bug \$118233051)
+ Certain queries for the INFORMATION\$1SCHEMA TABLES and COLUMNS tables could lead to excessive memory use when there were large numbers of empty InnoDB tables. (Bug \$118592390)
+ When committing a transaction, a flag is now used to check whether a thread has been created, rather than checking the thread itself, which uses more resources, particularly when running the server with master\$1info\$1repository=TABLE. (Bug \$118684222)
+ If a client thread on a worker executed FLUSH TABLES WITH READ LOCK while the master executed a DML, executing `SHOW SLAVE STATUS` in the same client became blocked, causing a deadlock. (Bug \$119843808)
+ Ordering by a GROUP\$1CONCAT() result could cause a server exit. (Bug \$119880368)
# Aurora MySQL database engine updates: 2015-08-24 (version 1.1) (Deprecated)
**Version:** 1.1
This update includes the following improvements:
+ Replication stability improvements when replicating with a MySQL database (binlog replication). For information on Aurora MySQL replication with MySQL, see [ Replication with Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Replication.html) in the *Amazon Aurora User Guide*.
+ A 1 gigabyte (GB) limit on the size of the relay logs accumulated for an Aurora MySQL DB cluster that is a replication worker. This improves the file management for the Aurora DB clusters.
+ Stability improvements in the areas of read ahead, recursive foreign-key relationships, and Aurora replication.
+ Integration of MySQL bug fixes.
+ InnoDB databases with names beginning with a digit cause a full-text search (FTS) parser error. (Bug \$117607956)
+ InnoDB full-text searches fail in databases whose names began with a digit. (Bug \$117161372)
+ For InnoDB databases on Windows, the full-text search (FTS) object ID is not in the expected hexadecimal format. (Bug \$116559254)
+ A code regression introduced in MySQL 5.6 negatively impacted DROP TABLE and ALTER TABLE performance. This could cause a performance drop between MySQL Server 5.5.x and 5.6.x. (Bug \$116864741)
+ Simplified logging to reduce the size of log files and the amount of storage that they require.