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.

Zero-ETL integration with Amazon Redshift FAQs

Open all
You should use the Amazon RDS for MySQL zero-ETL integration with Amazon Redshift when you want to remove the need to build and manage complex data pipelines. Once the data is in Amazon Redshift, you have access to near real-time analytics and machine learning (ML) capabilities on your transactional data from RDS for MySQL.
The RDS for MySQL zero-ETL integration with Amazon Redshift is available for MySQL versions 8.0.32 and higher in supported AWS Regions.
The RDS for MySQL zero-ETL integration with Amazon Redshift enables near real-time analytics and machine learning (ML) on petabytes of transactional data and removes the need for you to build and manage complex data pipelines. Within seconds of the data being written to RDS for MySQL, it is replicated to Amazon Redshift. You can consolidate data from multiple databases and tables from RDS for MySQL to Amazon Redshift. Based on your analytics needs, data filtering of specific databases and tables helps you selectively bring data into Amazon Redshift.

You pay for RDS for MySQL and Amazon Redshift resources used to create and process the change data created as part of a zero-ETL integration. These resources include Amazon RDS snapshot export costs to seed and resynchronize your Amazon Redshift data warehouses, change data capture (CDC) data transfer costs for ongoing replication of data changes from source to target, regular RDS I/O and storage used to process change data, and regular Amazon Redshift storage and compute costs for the replicated data. For more information, see the RDS for MySQL pricing page.


For example: You have an RDS for MySQL 8.0.32 database and an Amazon Redshift data warehouse running in the US East (N. Virginia) Region. This RDS for MySQL DB instance currently uses 50 GB of General Purpose SSD (gp3) storage capacity that includes provisioned baseline IOPS, has automated backups enabled, and has MySQL binary logging turned on.


When you create a zero-ETL integration with Amazon Redshift for your RDS for MySQL DB instance, a snapshot of the data (50 GB) is created and exported to seed an Amazon Redshift data warehouse. The next day, you change the primary key of a table in your RDS for MySQL DB instance, which results in a resynchronization of the snapshot export to Amazon Redshift. Over the course of 30 days, the database processes 5 GB of data changes.


In this example, the cost to use RDS for MySQL zero-ETL integration with Amazon Redshift in US East (N. Virginia) in the 30 days is 50 GB x ($0.10/GB) initial export plus 50 GB x ($0.10/GB) resynchronization costs plus 5 GB x ($2.00/GB) CDC data transfer, for a total of $20.00. In addition to these costs for the zero-ETL integration, you are responsible for charges from the normal use of Amazon RDS and Amazon Redshift to process the replicated data, such as I/O, storage, and compute costs.
Yes, to reduce resource consumption on the primary instance, you can use an Amazon RDS Read Replica as the source Amazon RDS instance for a zero-ETL integration with Amazon Redshift.
Yes, you can use AWS CloudFormation to manage and automate the configuration and deployment of resources needed for an RDS for MySQL zero-ETL integration with Amazon Redshift. For more information, visit the AWS CloudFormation user guide.
The RDS for MySQL zero-ETL integration to Amazon Redshift atomically replicates transactions to ensure data consistency between the source RDS for MySQL database and the target Amazon Redshift cluster.

Here are some key points about the atomicity of transactions with this integration:
  • Only committed transactions in RDS for MySQL are replicated to Amazon Redshift. Uncommitted or rolled-back transactions are not applied.
  • The integration uses a two-phase commit process to atomically apply each transaction to Amazon Redshift. Either all data changes in the transaction are applied or if an error occurs none are applied.
  • Transaction consistency is maintained between the source and target. After replication, the data for a given transaction will be consistent in both RDS for MySQL and Amazon Redshift.
  • Schema changes through DDL or DML are also atomically applied to maintain integrity.
  • The atomic application of transactions ensures no partial transactions or inconsistent data states can occur between the databases.
The RDS for MySQL zero-ETL integration with Amazon Redshift maintains full transactional consistency between the source RDS for MySQL database and the target Amazon Redshift cluster.

Here are some key points on how schema changes are handled:

  • DDL statements like CREATE TABLE, ALTER TABLE, DROP TABLE, and so on are automatically replicated from RDS for MySQL to Amazon Redshift.
  • The integration makes the necessary checks and adjustments in Amazon Redshift tables for replicated schema changes. For example, adding a column in RDS for MySQL will add the column in Amazon Redshift.
  • The replication and schema sync automatically happen in near real-time with minimal lag between source and target databases.
  • Schema consistency is maintained even as DML changes occur in parallel to DDL changes.