Skip to main content

Amazon RDS for MySQL

Amazon RDS for MySQL FAQs

Page topics

General

Open all
Amazon Relational Database (Amazon RDS) for MySQL currently supports MySQL Community Edition versions 8.4 and 8.0. RDS for MySQL also supports MySQL 5.7 under RDS Extended Support. You can find more information about supported minor versions is available in the Amazon RDS User Guide.
In the context of MySQL, version numbers are organized as follows:
MySQL version = X.Y.Z

X = Major version, Y = Release level, Z = Version number within release series.
From the Amazon RDS standpoint, a version change would be considered major if either major version or release level is being changed. Example: going from 5.6.X -> 5.7.X.
A version change would be considered minor if the version number within the release is being changed. Example: going from 5.6.27 -> 5.6.29.
Yes. Please refer to the Amazon RDS FAQs.
The point-in-time restore, snapshot restore, and zero-ETL integration with Amazon Redshift features of Amazon RDS for MySQL require a crash-recoverable storage engine and are only supported for the InnoDB storage engine. While MySQL supports multiple storage engines with varying capabilities, not all of them are optimized for crash recovery and data durability. For example, the MyISAM storage engine does not support reliable crash recovery and could result in data loss or data corruption when MySQL is restarted after a crash, preventing point-in-time restore or snapshot restore from working as intended. However, if you still choose to use MyISAM with Amazon RDS, following these steps might be helpful in certain scenarios for DB snapshot restore functionality. Federated Storage Engine is currently not supported by RDS for MySQL.
When you create a new DB instance, the default primary user that you use gets certain privileges. See Master User Account Privileges in the Amazon RDS User Guide for a list of the privileges.
RDS for MySQL Read Replicas require a transactional storage engine and are only supported for the InnoDB storage engine. Non-transactional MySQL storage engines, such as MyISAM, might prevent Read Replicas from working as intended. However, if you still choose to use MyISAM with Read Replicas, we advise you to watch the Amazon CloudWatch “Replica Lag” metric (available via the AWS Management Console or Amazon CloudWatch APIs) carefully and recreate the Read Replica should it fall behind due to replication errors. The same considerations apply to the use of temporary tables and any other non-transactional engines.
You can set the binary logging format to row-based for MySQL version 5.6 and later. By default, replication is set to mixed-format (which includes both row-based and statement-based replication), which should meet the requirements of most use cases. The MySQL documentation offers more information about the difference between mixed-format and row-based replication.

Amazon Blue/Green Deployments FAQs

Open all
Amazon RDS Blue/Green Deployments are available in RDS for MySQL versions 5.7 and higher. Learn more about available versions in the RDS for MySQL documentation.
Amazon RDS Blue/Green Deployments are available in all applicable AWS Regions and AWS GovCloud Regions.
Amazon RDS Blue/Green Deployments allow you to make safer, simpler, and faster database changes, such as major or minor version upgrades, schema changes, instance scaling, engine parameter changes, and maintenance updates.
Amazon RDS Blue/Green Deployments allow you to make safer, simpler, and faster database changes. Blue/Green Deployments are ideal for use cases such as major or minor version database engine upgrades, operating system updates, schema changes on green environments that do not break logical replication, like adding a new column at the end of a table, or database parameter setting changes. You can use Blue/Green Deployments to make multiple database updates at the same time using a single switchover. This allows you to stay current on security patches, improve database performance, and access newer database features with short, predictable downtime.
You will incur the same price for running your workloads on green instances as you do for blue instances. The cost of running on blue and green instances include our current standard pricing for db.instances, cost of storage, cost of read/write I/Os, and any enabled features, such as cost of backups and Amazon RDS Performance Insights. Effectively, you are paying approximately 2x the cost of running workloads on db.instance for the lifespan of the blue-green-deployment.

For example: You have an RDS for MySQL 5.7 database running on two r5.2xlarge db.instances, a primary database instance and a read replica, in us-east-1 AWS Region with a Multi-AZ (MAZ) configuration. Each of the r5.2xlarge db.instance is configured for 20 GiB General Purpose Amazon Elastic Block Store (Amazon EBS). You create a clone of the blue instance topology using Amazon RDS Blue/Green Deployments, run it for 15 days (360 hours), and then delete the blue instances after a successful switchover. The blue instances cost $1,387 for 15 days at an on-demand rate of $1.926/hr (Instance + EBS cost). The total cost to you for using Blue/Green Deployments for those 15 days is $2,774, which is 2x the cost of running blue instances for that time period.
Amazon RDS Blue/Green Deployments allow you to make safer, simpler, and faster database changes, such as major or minor version upgrades, schema changes, instance scaling, engine parameter changes, and maintenance updates.
In Amazon RDS Blue/Green Deployments, the blue environment is your current production environment. The green environment is your staging environment that will become your new production environment after switchover.
When Amazon RDS Blue/Green Deployments initiate a switchover, it blocks writes to both the blue and green environments, until switchover is complete. During switchover, the staging environment—or green environment—catches up with the blue environment, ensuring data is consistent between the blue and green environments. Once the blue and green environment are in complete sync, Blue/Green Deployments promote the green environment as the new blue environment by redirecting traffic to the green environment. Blue/Green Deployments are designed to enable writes on the green environment after switch-over is complete, ensuring zero data loss during the switchover process.
If your blue environment is a self-managed logical replica, or subscriber, we will block switchover. We recommend that you first stop replication to the blue environment, proceed with the switchover, and then resume replication. In contrast, if your blue environment is a source for a self-managed logical replica, or publisher, you can continue to switchover. However, you will need to update the self-managed replica to replicate from the green environment post switchover.
Amazon RDS Blue/Green Deployments do not delete your old production environment. If needed, you can access it for additional validations and performance/regression testing. If you no longer need the old production environment, you can delete it. Standard billing charges apply on old production instances until you delete them.
Amazon RDS Blue/Green Deployments switchover guardrails block writes on your blue and green environments until your green environment catches up before switching over. Blue/Green Deployments also perform health checks of your primary and replicas in your blue and green environments. They also perform replication health checks, for example, to see if replication has stopped or if there are errors. They detect long running transactions between your blue and green environments. You can specify your maximum tolerable downtime, as low as 30 seconds, and if you have an ongoing transaction that exceeds this your switchover will time out.
No, Amazon RDS Blue/Green Deployments do not support Amazon RDS Proxy, cross-Region read replicas, or cascaded read replicas.
No, at this time you cannot use Amazon RDS Blue/Green Deployments to rollback changes.

Amazon RDS Optimized Writes FAQs

Open all
MySQL protects users from data loss by writing data in 16KiB pages in memory twice to durable storage—first to the "doublewrite buffer" and then to table storage. Amazon RDS Optimized Writes write your 16KiB data pages directly to your data files reliably and durably in one step using the Torn Write Prevention feature of the AWS Nitro System.
Amazon RDS Optimized Writes are available for MySQL major version 8.0.30 and higher.

Amazon RDS Optimized Writes are available in db.r6i and db.r5b instances. They are available in all Regions where these instances are available.

All RDS for MySQL users should implement Amazon RDS Optimized Writes for up to 2x improved write transaction throughput. Applications with write-heavy workloads, such as digital payments, financial trading, and online gaming applications will find this feature especially helpful.
No. Amazon Aurora MySQL-Compatible Edition already avoids the use of the "doublewrite buffer." Instead, Aurora replicates data six ways across three Availability Zones (AZs) and uses a quorum-based approach to durably write data and correctly read it thereafter.
At this time, this initial release does not support enabling Amazon RDS Optimized Writes for your existing database instances even if the instance class supports Optimized Writes.
Amazon RDS Optimized Writes are available to RDS for MySQL customers at no additional cost.

Amazon RDS Optimized Reads FAQs

Open all

Workloads that use temporary objects in MySQL for query processing benefit from Amazon RDS Optimized Reads. Optimized Reads place temporary objects on the database instance's NVMe-based instance storage, instead of the Amazon EBS volume. This helps to speed up complex query processing by up to 50%.
Amazon RDS Optimized Reads are available for RDS for MySQL on MySQL versions 8.0.28 and higher.
Amazon RDS Optimized Reads are available in all Regions where db.r5d, db.m5d, db.r6gd, db.m6gd, X2idn, and X2iedn instances are available. For more information, see the Amazon RDS DB instance classes documentation.
Customers should use Amazon RDS Optimized Reads when they have workloads that require complex queries; general-purpose analytics; or require intricate groups, sorts, hash aggregations, high-load joins, and Common Table Expressions (CTEs). These use cases result in the creation of temporary tables, allowing Optimized Reads to speed up your workload’s query processing.
Yes, customers can convert their existing Amazon RDS database to use Amazon RDS Optimized Reads by moving your workload to an Optimized Read-enabled instance. Optimized Reads is also available by default on all supported instance classes. If you’re running your workload on db.r5d, db.m5d, db.r6gd, db.m6gd, X2idn, and X2iedn instances, you’re already benefiting from Optimized Reads.
OSZAR »