MySQL on Amazon RDS
Amazon RDS supports DB instances running several versions of MySQL. You first use the Amazon RDS management tools or interfaces to create an Amazon RDS MySQL DB instance. You can then use the resizing the DB instance, authorizing connections to the DB instance, creating and restoring from backups or snapshots, creating Multi-AZ secondaries, creating Read Replicas, and monitoring the performance of the DB instance. You use standard MySQL utilities and applications to store and access the data in the DB instance.
These are the common management tasks you perform with an Amazon RDS MySQL DB instance, with links to information about each task:
For planning information, such as MySQL versions, storage engines, security, and features supported in Amazon RDS, see MySQL on Amazon RDS Planning Information.
Before creating a DB instance, you should complete the steps in the Setting Up for Amazon RDS section of this guide.
You can create an Amazon RDS MySQL DB instance after you have met prerequisites, such as creating security groups, DB parameter groups, or DB option groups. For information, see Creating a DB Instance Running the MySQL Database Engine.
After creating the security group and DB instance, you can connect to the DB instance from MySQL applications and utilities. For information, see Connecting to a DB Instance Running the MySQL Database Engine.
A newly created Amazon RDS DB instance has one empty database with the name you specified when you created the DB instance, and one master user account with the name and password you specified. You must use a MySQL tool or utility to log in as the master user, and then use MySQL commands and SQL statements to add all of the users and elements required for your applications to store and retrieve data in the DB instance, such as:
Create all user IDs and grant them the appropriate permissions. For information, go to MySQL User Account Management in the MySQL documentation.
Create any required databases and objects such as tables and views. For information, go to Data Definition Statements in the MySQL documentation.
Establish procedures for importing or exporting data. For information on some recommended procedures, see Importing and Exporting Data From a MySQL DB Instance.
You might need to periodically change your DB instance, such as to resize or reconfigure the DB instance. For information, see Modifying a DB Instance Running the MySQL Database Engine. For additional information on specific tasks, see:
You can configure your DB instance to take automated backups, or take manual snapshots, and then restore instances from the backups or snapshots. For information, see Backing Up and Restoring.
You can monitor an instance through actions such as viewing the MySQL logs, CloudWatch Amazon RDS metrics, and events. For information, see Monitoring Amazon RDS.
You can offload read traffic from your primary MySQL DB instance by creating Read Replicas. For information, see Working with PostgreSQL, MySQL, and MariaDB Read Replicas.
There are several Amazon RDS features you can use with MySQL DB instances that are common across the Amazon RDS database engines. For information, see:
There are also several appendices with useful information about working with Amazon RDS MySQL DB instances:
MySQL on Amazon RDS Planning Information
MySQL on Amazon RDS Versions
Amazon RDS currently supports MySQL versions 5.7, 5.6, 5.5, and 5.1. Over time, we plan to support additional MySQL versions for Amazon RDS. The number of new version releases supported in a given year will vary based on the frequency and content of the MySQL version releases and the outcome of a thorough vetting of the release by our database engineering team. However, as a general guidance, we aim to support new MySQL versions within 3 to 5 months of their General Availability release.
MySQL, version numbers are organized as version = X.Y.Z. In Amazon RDS terminology, X.Y denotes the major version, and Z is the minor version number. For Amazon RDS implementations, a version change is considered major if the major version number changes—for example, going from version 5.1.71 to 5.5.33. A version change is considered minor if only the minor version number changes—for example, going from version 5.5.31 to 5.5.33.
You can specify any currently supported MySQL version when creating a new DB instance. You can specify the MySQL 5.7, 5.6, 5.5, or 5.1 major versions, and any supported minor version for the specified major version. If no version is specified, Amazon RDS will default to a supported version, typically the most recent version. If a major version (for example, MySQL 5.7) is specified but a minor version is not, Amazon RDS will default to a recent release of the major version you have specified. To see a list of supported versions, as well as defaults for newly created DB instances, use the DescribeDBEngineVersions API action.
With Amazon RDS, you control when to upgrade your MySQL instance to a new version supported by Amazon RDS. You can maintain compatibility with specific MySQL versions, test new versions with your application before deploying in production, and perform version upgrades at times that best fit your schedule.
Unless you specify otherwise, your DB instance will automatically be upgraded to new MySQL minor versions as they are supported by Amazon RDS. This patching will occur during your scheduled maintenance window, and it will be announced on the Amazon RDS Community Forum in advance. To turn off automatic version upgrades, set the AutoMinorVersionUpgrade parameter to “false.”
If you opt out of automatically scheduled upgrades, you can manually upgrade to a supported minor version release by following the same procedure as you would for a major version update. For information, see DB Instance Maintenance and Upgrades.
Amazon RDS currently supports the major version upgrades from MySQL version 5.5 to version 5.6 and MySQL version 5.6 to version 5.7. Because major version upgrades involve some compatibility risk, they do not occur automatically; you must make a request to modify the DB instance. You should thoroughly test any upgrade before upgrading your production instances. For information about upgrading a DB instance, see DB Instance Maintenance and Upgrades.
You can test a DB instance against a new version before upgrading by creating a DB snapshot of your existing DB instance, restoring from the DB snapshot to create a new DB instance, and then initiating a version upgrade for the new DB instance. You can then experiment safely on the upgraded clone of your DB instance before deciding whether or not to upgrade your original DB instance.
The Amazon RDS deprecation policy for MySQL includes the following:
We intend to support major MySQL version releases, including MySQL 5.5, for 3 years after they are initially supported by Amazon RDS.
We intend to support minor MySQL version releases (for example, MySQL 5.5.46) for at least 1 year after they are initially supported by Amazon RDS.
After a MySQL major or minor version has been “deprecated,” we expect to provide a three month grace period for you to initiate an upgrade to a supported version prior to an automatic upgrade being applied during your scheduled maintenance window.
MySQL 5.1 Deprecation
On November 6, 2016, Amazon RDS is retiring support for MySQL version 5.1. In December 2013, MySQL Community Edition 5.1 was moved to sustaining support with no new software or security fixes or updates. To provide the best experience for AWS customers, we are retiring version 5.1.
We recommend that before October 18, 2016, you upgrade any DB instances that are running MySQL version 5.1 to one of the supported MySQL versions. Amazon RDS supports MySQL versions 5.5, 5.6, and 5.7.
MySQL version 5.6.4 introduced a new date and time format for the datetime , time , and timestamp columns that is different than MySQL version 5.1. If you are upgrading a MySQL version 5.1 DB instance to version 5.5, then version 5.6, and finally version 5.7, you might encounter a slow upgrade from version 5.6 to version 5.7. This is because MySQL forces the conversion of all date and time column types to the new format when you upgrade to version 5.7. Because this conversion rebuilds your tables, it might take a considerable amount of time to complete the DB instance upgrade. For information on how to convert the date and time formats yourself and reduce the amount of time required to upgrade to MySQL version 5.7, Upgrades to MySQL Version 5.7 Might Be Slow.
You might want to create a DB instance running a supported version of the MySQL database engine and test your application with that DB instance before upgrading your DB instance running MySQL version 5.1.
To create a test version of your DB instance running a newer version of MySQL
Take a snapshot of your MySQL 5.1 DB instance. For more information, see Creating a DB Snapshot.
Restore the snapshot to a new DB instance. For more information, see Restoring From a DB Snapshot.
Upgrade the new DB instance to a supported version of MySQL. For more information, see Upgrading the MySQL DB Engine.
You can review the release notes for each supported version of MySQL at the following sites:
If you want to upgrade your DB instance to MySQL version 5.6, you must first upgrade your DB instance to MySQL version 5.5, and then upgrade the DB instance to MySQL version 5.6. If you want to upgrade your DB instance to MySQL version 5.7, you must first upgrade your DB instance to MySQL version 5.5, and then upgrade to version 5.6, and then upgrade to version 5.7.
For information and instructions on upgrading a DB instance to a new version of MySQL, see Upgrading the MySQL DB Engine.
Amazon RDS will retire MySQL version 5.1 support according to the following schedule:
After August 9, 2016, you will no longer be able to create DB instances that use MySQL version 5.1.
Beginning on October 18, 2016, MySQL DB instances running version 5.1 will automatically be scheduled for an upgrade to version 5.5 during the next maintenance window. Any DB instance restored from a MySQL 5.1 DB snapshot will also be upgraded during the instance maintenance window.
On November 6, 2016, any DB instance running MySQL version 5.1 will be immediately upgraded to version 5.5.
Using the memcached Option with MySQL
Most Amazon RDS DB engines support option groups that allow you to select
additional features for your DB instance. DB instances on MySQL version 5.6 and
later support the
memcached option, a simple, key-based cache. For
more information about the
memcached option, see Appendix: Options for MySQL Database Engine.
For more information about working with option groups, see Working with Option Groups.
Amazon RDS Supported Storage Engines
While MySQL supports multiple storage engines with varying capabilities, not all
of them are optimized for recovery and data durability. Amazon RDS fully supports
the InnoDB storage engine for MySQL DB instances. Amazon RDS features such as
Point-In-Time restore and snapshot restore require a recoverable storage engine and
are supported for the InnoDB storage engine only. You must be running an instance of
MySQL 5.6 or later to use the InnoDB
memcached interface. For more
information, see MySQL memcached Support.
The Federated Storage Engine is currently not supported by Amazon RDS for MySQL.
The MyISAM storage engine does not support reliable recovery and can result in lost or corrupt data when MySQL is restarted after a recovery, preventing Point-In-Time restore or snapshot restore from working as intended. However, if you still choose to use MyISAM with Amazon RDS, snapshots can be helpful under some conditions. For more information on MyISAM restrictions, see Automated Backups with Unsupported MySQL Storage Engines.
If you want to convert existing MyISAM tables to InnoDB tables, you can use the alter table command (for example, alter table TABLE_NAME engine=innodb;). Bear in mind that MyISAM and InnoDB have different strengths and weaknesses, so you should fully evaluate the impact of making this switch on your applications before doing so.
Amazon RDS and MySQL Security
Security for Amazon RDS MySQL DB instances is managed at three levels:
AWS Identity and Access Management controls who can perform Amazon RDS management actions on DB instances. When you connect to AWS using IAM credentials, your IAM account must have IAM policies that grant the permissions required to perform Amazon RDS management operations. For more information, see Authentication and Access Control for Amazon RDS.
When you create a DB instance, you use either a VPC security group or a DB security group to control which devices and Amazon EC2 instances can open connections to the endpoint and port of the DB instance. These connections can be made using SSL. In addition, firewall rules at your company can control whether devices running at your company can open connections to the DB instance.
Once a connection has been opened to a MySQL DB instance, authentication of the login and permissions are applied the same way as in a stand-alone instance of MySQL. Commands such as
SET PASSWORDwork just as they do in stand-alone databases, as does directly modifying database schema tables. For information, go to MySQL User Account Management in the MySQL documentation.
When you create an Amazon RDS DB instance, the master user has the following default privileges:
create temporary tables
replication slave (MySQL 5.6 and later)
Although it is possible to delete the master user on the DB instance, it is
not recommended. To recreate the master user, use the
ModifyDBInstance RDS API action or the
modify-db-instance AWS CLI tool and specify a new
master user password with the appropriate parameter. If the master user does not
exist in the instance, the master user will be created with the specified
To provide management services for each DB instance, the
user is created when the DB instance is created. Attempting to drop, rename, change
the password, or change privileges for the
rdsadmin account will result
in an error.
To allow management of the DB instance, the standard
kill_query commands have been restricted. The Amazon RDS
provided to allow you to terminate user sessions or queries on DB instances.
Using SSL with a MySQL DB Instance
Amazon RDS supports SSL connections with DB instances running the MySQL database engine.
Amazon Aurora is compatible with MySQL. However, you use a different SSL certificate to connect to an Amazon Aurora DB cluster. For information on connecting to Amazon Aurora using SSL, see Securing Aurora Data with SSL.
Amazon RDS creates an SSL certificate and installs the certificate on the DB instance when Amazon RDS provisions the instance. These certificates are signed by a certificate authority. The SSL certificate includes the DB instance endpoint as the Common Name (CN) for the SSL certificate to guard against spoofing attacks. The public key is stored at https://s3.amazonaws.com/rds-downloads/rds-combined-ca-bundle.pem.
An SSL certificate created by Amazon RDS is the trusted root entity and should work in most cases but might fail if your application does not accept certificate chains. If your application does not accept certificate chains, you might need to use an intermediate certificate to connect to your region. For example, you must use an intermediate certificate to connect to the GovCloud (US) region using SSL. For a list of regional intermediate certificates that you can download, see Intermediate certificates.
To encrypt connections using the default mysql client,
launch the mysql client using the
--ssl-ca parameter to
reference the public key, for example:
mysql -h myinstance.c9akciq32.rds-us-east-1.amazonaws.com --ssl-ca=
[full path]rds-combined-ca-bundle.pem --ssl-verify-server-cert
You can use the GRANT statement to require SSL connections for specific users accounts. For example, you can use the following statement to require SSL connections on the user account encrypted_user:
GRANT USAGE ON *.* TO 'encrypted_user'@'%' REQUIRE SSL
For more information on SSL connections with MySQL, go to the MySQL documentation.
Local Time Zone for MySQL DB Instances
By default, the time zone for an RDS MySQL DB instance is Universal Time Coordinated (UTC). You can set the time zone for your DB instance to the local time zone for your application instead.
To set the local time zone for a DB instance, set the
time_zone parameter in the
parameter group for your DB instance to one of the supported values listed later in this section.
When you set the
time_zone parameter for a parameter group, all DB instances and
Read Replicas that are using that parameter group change to use the new local time zone. For
information on setting parameters in a parameter group, see Working with DB Parameter Groups.
After you set the local time zone, all new connections to the database reflect the change. If you have any open connections to your database when you change the local time zone, you won't see the local time zone update until after you close the connection and open a new connection.
You can set a different local time zone for a DB instance and one or more of its Read Replicas. To do this,
use a different parameter group for the DB instance and the replica or replicas and set the
parameter in each parameter group to a different local time zone.
If you are replicating across regions, then the replication master DB instance and the Read Replica use
different parameter groups (parameter groups are unique to a region). To use the same local time zone for
each instance, you must set the
time_zone parameter in the instance's and Read Replica's parameter groups.
When you restore a DB instance from a DB snapshot, the local time zone is set to UTC. You can update the time zone to your local time zone after the restore is complete. If you restore a DB instance to a point in time, then the local time zone for the restored DB instance is the time zone setting from the parameter group of the restored DB instance.
Local time zone is supported for MySQL versions 5.5, 5.6, and 5.7 only.
You can set your local time zone to one of the following values.
InnoDB Cache Warming
InnoDB cache warming can provide performance gains for your MySQL DB instance by saving the current state of the buffer pool when the DB instance is shut down, and then reloading the buffer pool from the saved information when the DB instance starts up. This bypasses the need for the buffer pool to "warm up" from normal database use and instead preloads the buffer pool with the pages for known common queries. The file that stores the saved buffer pool information only stores metadata for the pages that are in the buffer pool, and not the pages themselves. As a result, the file does not require much storage space. The file size is about 0.2 percent of the cache size. For example, for a 64 GB cache, the cache warming file size is 128 MB. For more information on InnoDB cache warming, go to Preloading the InnoDB Buffer Pool for Faster Restart in the MySQL documentation.
MySQL on Amazon RDS supports InnoDB cache warming for MySQL version 5.6 and later. To enable InnoDB cache warming,
parameters to 1 in the parameter group for your DB instance. Changing these parameter values in a parameter group will
affect all MySQL DB instances that use that parameter group. To enable InnoDB cache warming for specific MySQL DB
instances, you might need to create a new parameter group for those instances. For information on parameter groups, see
Working with DB Parameter Groups.
InnoDB cache warming primarily provides a performance benefit for DB instances that use standard storage. If you use PIOPS storage, you do not commonly see a significant performance benefit.
If your MySQL DB instance does not shut down normally, such as during a failover, then the buffer pool state will not be saved to disk. In this case, MySQL loads whatever buffer pool file is available when the DB instance is restarted. No harm is done, but the restored buffer pool might not reflect the most recent state of the buffer pool prior to the restart. To ensure that you have a recent state of the buffer pool available to warm the InnoDB cache on startup, we recommend that you periodically dump the buffer pool "on demand." You can dump or load the buffer pool on demand if your DB instance is running MySQL version 5.6.19 or later.
You can create an event to dump the buffer pool automatically and on a regular
interval. For example, the following statement creates an event named
periodic_buffer_pool_dump that dumps the buffer pool every hour.
CREATE EVENT periodic_buffer_pool_dump ON SCHEDULE EVERY 1 HOUR DO CALL mysql.rds_innodb_buffer_pool_dump_now();
For more information on MySQL events, see Event Syntax in the MySQL documentation.
Dumping and Loading the Buffer Pool on Demand
For MySQL version 5.6.19 and later, you can save and load the InnoDB cache "on demand."
To dump the current state of the buffer pool to disk, call the mysql.rds_innodb_buffer_pool_dump_now stored procedure.
To load the saved state of the buffer pool from disk, call the mysql.rds_innodb_buffer_pool_load_now stored procedure.
To cancel a load operation in progress, call the mysql.rds_innodb_buffer_pool_load_abort stored procedure.
MySQL Features Not Supported By Amazon RDS
Amazon RDS currently does not support the following MySQL features:
Global Transaction IDs
Transportable Table Space
Password Strength Plugin
In order to deliver a managed service experience, Amazon RDS does not provide shell access to DB instances, and it restricts access to certain system procedures and tables that require advanced privileges. Amazon RDS supports access to databases on a DB instance using any standard SQL client application. Amazon RDS does not allow direct host access to a DB instance via Telnet, Secure Shell (SSH), or Windows Remote Desktop Connection. When you create a DB instance, you are assigned to the db_owner role for all databases on that instance, and you will have all database-level permissions except for those used for backups (Amazon RDS manages backups for you).
Known Issues and Limitations
Known issues and limitations 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
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_chunk_size parameter values, as shown in the
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 https://bugs.mysql.com/bug.php?id=79379 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
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
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 http://bugs.mysql.com/bug.php?id=72745 and http://bugs.mysql.com/bug.php?id=68194 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:
index_merge=offin 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 Maintenance and Upgrades.
If you cannot upgrade your instance or change the
optimizer_switchparameter, 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
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:
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 the Database Engine Version for a DB Instance.
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 the Database Engine Version for a DB Instance.
To upgrade your date and time columns to the new format on your master DB instance, you must issue the
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
timestampand create an
ALTER TABLEcommand 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
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
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").
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
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 size limit of 2 TB. This 2 TB file size limit also applies to DB instances 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 https://dev.mysql.com/doc/refman/5.6/en/partitioning.html 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
1in 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
0in 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
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
ALTER TABLE table_name ENGINE=InnoDB;