Amazon Relational Database Service
User Guide (API Version 2014-10-31)

Known Issues and Limitations for MySQL on Amazon RDS

Known issues and limitations for working with MySQL on Amazon RDS are as follows.

Inconsistent InnoDB Buffer Pool Size

For MySQL 5.7, there is currently a bug in the way that the InnoDB buffer pool size is managed. MySQL 5.7 might adjust the value of the innodb_buffer_pool_size parameter to a large value that can result in the InnoDB buffer pool growing too large and using up too much memory. This effect can cause the MySQL database engine to stop running or can prevent the MySQL database engine from starting. This issue is more common for DB instance classes that have less memory available.

To resolve this issue, set the value of the innodb_buffer_pool_size parameter to a multiple of the product of the innodb_buffer_pool_instances parameter value and the innodb_buffer_pool_chunk_size parameter value. For example, you might set the innodb_buffer_pool_size parameter value to a multiple of eight times the product of the innodb_buffer_pool_instances and innodb_buffer_pool_chunk_size parameter values, as shown in the following example.

innodb_buffer_pool_chunk_size = 536870912 innodb_buffer_pool_instances = 4 innodb_buffer_pool_size = (536870912 * 4) * 8 = 17179869184

For details on this MySQL 5.7 bug, go to in the MySQL documentation.

Memcached Recommended MySQL Version

We recommend that you only use the memcached interface with MySQL version 5.6.21b or later. We do so because there are a number of bug fixes related to the memcached interface that are included in the MySQL engine starting with version 5.6.21b. For more information, go to Changes in MySQL 5.6.20 (2014-07-31) and Changes in MySQL 5.6.21 (2014-09-23) in the MySQL documentation.

For more information on using memcached with MySQL on Amazon RDS, see MySQL MEMCACHED Support.

MySQL Version 5.5.40 Asynchronous I/O Is Disabled

You might observe reduced I/O performance if you have a MySQL DB instance that was created before April 23, 2014, and then upgraded to MySQL version 5.5.40 after October 17, 2014. This reduced performance can be caused by an error that disables the innodb_use_native_aio parameter even if the corresponding DB parameter group enables the innodb_use_native_aio parameter.

To resolve this error, we recommend that you upgrade your MySQL DB instance running version 5.5.40 to version 5.5.40a, which corrects this behavior. For information on minor version upgrades, see Upgrading the MySQL DB Engine.

For more information on MySQL asynchronous I/O, go to Asynchronous I/O on Linux in the MySQL documentation.

Index Merge Optimization Returns Wrong Results

Queries that use index merge optimization might return wrong results due to a bug in the MySQL query optimizer that was introduced in MySQL 5.5.37. When you issue a query against a table with multiple indexes the optimizer scans ranges of rows based on the multiple indexes, but does not merge the results together correctly. For more information on the query optimizer bug, go to and in the MySQL bug database.

For example, consider a query on a table with two indexes where the search arguments reference the indexed columns.

SELECT * FROM table1 WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';

In this case, the search engine will search both indexes. However, due to the bug, the merged results will be incorrect.

To resolve this issue, you can do one of the following:

  • Set the optimizer_switch parameter to index_merge=off in the DB parameter group for your MySQL DB instance. For information on setting DB parameter group parameters, see Working with DB Parameter Groups.

  • Upgrade your MySQL DB instance to MySQL version 5.6.19a. For information on major version upgrades, see DB Instance and DB Cluster Maintenance and Upgrades.

  • If you cannot upgrade your instance or change the optimizer_switch parameter, you can work around the bug by explicitly identifying an index for the query, for example:

    SELECT * FROM table1 USE INDEX covering_index WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';

For more information, go to Index Merge Optimization.

Replication Fails After Upgrading to MySQL Version 5.6.21

If you have a DB instance that runs a version prior to version 5.6.4, or if the DB instance was upgraded from a version prior to version 5.6.4, you can receive the following error if you have a Read Replica that runs MySQL version 5.6.21.

mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.

MySQL version 5.6.4 introduced a new date and time format for datetime, time, and timestamp columns that allows fractional components in date and time values. The error is caused by a mismatch in date and time formats between the master and the replica, and results in a failure when row-based logging attempts to replay an operation from the master DB instance to the replica DB instance. You might also see a number of related row-based logging messages in your MySQL error log, for example: Relay_log_info, Rows_log_event, and so on. For information on the new date and time format for MySQL, go to Upgrading from MySQL 5.5 to 5.6 in the MySQL documentation.

To resolve the error, you can do either of the following:

  • Upgrade your Read Replica to MySQL version 5.6.23 or later. For information on upgrading a MySQL DB instance on Amazon RDS to version 5.6, see Upgrading Database Engine Versions.

  • Upgrade your master DB instance to MySQL version 5.6.12 or later and update the format of the affected date and time columns. For information on upgrading a MySQL DB instance on Amazon RDS to version 5.6, see Upgrading Database Engine Versions.

    To upgrade your date and time columns to the new format on your master DB instance, you must issue the ALTER TABLE <table_name> FORCE; command.


    Because altering a table locks the table as read-only, we recommend that you perform this update during a maintenance window.

    You can run the following query to find all of the tables in your database that have columns of type datetime, time, or timestamp and create an ALTER TABLE <table_name> FORCE; command for each table.

    SELECT DISTINCT CONCAT('ALTER TABLE `', REPLACE(is_tables.TABLE_SCHEMA, '`', '``'), '`.`', REPLACE(is_tables.TABLE_NAME, '`', '``'), '` FORCE;') FROM information_schema.TABLES is_tables INNER JOIN information_schema.COLUMNS col ON col.TABLE_SCHEMA = is_tables.TABLE_SCHEMA AND col.TABLE_NAME = is_tables.TABLE_NAME LEFT OUTER JOIN information_schema.INNODB_SYS_TABLES systables ON SUBSTRING_INDEX(systables.NAME, '#', 1) = CONCAT(is_tables.TABLE_SCHEMA,'/',is_tables.TABLE_NAME) LEFT OUTER JOIN information_schema.INNODB_SYS_COLUMNS syscolumns ON syscolumns.TABLE_ID = systables.TABLE_ID AND syscolumns.NAME = col.COLUMN_NAME WHERE col.COLUMN_TYPE IN ('time','timestamp','datetime') AND is_tables.TABLE_TYPE = 'BASE TABLE' AND is_tables.TABLE_SCHEMA NOT IN ('mysql','information_schema','performance_schema') AND (is_tables.ENGINE = 'InnoDB' AND syscolumns.MTYPE = 6);

Log File Size

For MySQL version 5.6.20 and later, there is a size limit on BLOBs written to the redo log. To account for this limit, ensure that the innodb_log_file_size parameter for your MySQL DB instance is 10 times larger than the largest BLOB data size found in your tables, plus the length of other variable length fields (VARCHAR, VARBINARY, TEXT) in the same tables. For information on how to set parameter values, see Working with DB Parameter Groups. For information on the redo log BLOB size limit, go to Changes in MySQL 5.6.20.

MySQL Parameter Exceptions for Amazon RDS DB Instances

Some MySQL parameters require special considerations when used with an Amazon RDS DB instance.


Because Amazon RDS uses a case-sensitive file system, setting the value of the lower_case_table_names server parameter to 2 ("names stored as given but compared in lowercase") is not supported. Supported values for Amazon RDS DB instances are 0 ("names stored as given and comparisons are case-sensitive"), which is the default, or 1 ("names stored in lowercase and comparisons are not case-sensitive").

The lower_case_table_names parameter should be set as part of a custom DB parameter group before creating a DB instance. You should avoid changing the lower_case_table_names parameter for existing database instances because doing so could cause inconsistencies with point-in-time recovery backups and Read Replica DB instances.

Read Replicas should always use the same lower_case_table_names parameter value as the master DB instance.


You can set the long_query_time parameter to a floating point value which allows you to log slow queries to the MySQL slow query log with microsecond resolution. You can set a value such as 0.1 seconds, which would be 100 milliseconds, to help when debugging slow transactions that take less than one second.

MySQL File Size Limits

For Amazon RDS MySQL DB instances, the maximum provisioned storage limit constrains the size of a table to a maximum size of 6 TB when using InnoDB file-per-table tablespaces. This limit also constrains the system tablespace to a maximum size of 6 TB. InnoDB file-per-table tablespaces (with tables each in their own tablespace) is set by default for Amazon RDS MySQL DB instances.


MySQL DB instances created prior to April 2014 have a file and table size limit of 2 TB. This 2 TB file size limit also applies to DB instances or Read Replicas created from DB snapshots taken prior to April 2014, regardless of when the DB instance was created.

There are advantages and disadvantages to using InnoDB file-per-table tablespaces, depending on your application. To determine the best approach for your application, go to InnoDB File-Per-Table Mode in the MySQL documentation.

We don't recommend allowing tables to grow to the maximum file size. In general, a better practice is to partition data into smaller tables, which can improve performance and recovery times.

One option that you can use for breaking a large table up into smaller tables is partitioning. Partitioning distributes portions of your large table into separate files based on rules that you specify. For example, if you store transactions by date, you can create partitioning rules that distribute older transactions into separate files using partitioning. Then periodically, you can archive the historical transaction data that doesn't need to be readily available to your application. For more information, go to in the MySQL documentation.

To determine the file size of a table

  • Use the following SQL command to determine if any of your tables are too large and are candidates for partitioning.

    SELECT TABLE_SCHEMA, TABLE_NAME, round(((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024), 2) As "Approximate size (MB)" FROM information_schema.TABLES WHERE TABLE_SCHEMA NOT IN ('mysql', 'information_schema', 'performance_schema');

To enable InnoDB file-per-table tablespaces

  • To enable InnoDB file-per-table tablespaces, set the innodb_file_per_table parameter to 1 in the parameter group for the DB instance.

To disable InnoDB file-per-table tablespaces

  • To disable InnoDB file-per-table tablespaces, set the innodb_file_per_table parameter to 0 in the parameter group for the DB instance.

For information on updating a parameter group, see Working with DB Parameter Groups.

When you have enabled or disabled InnoDB file-per-table tablespaces, you can issue an ALTER TABLE command to move a table from the global tablespace to its own tablespace, or from its own tablespace to the global tablespace as shown in the following example: