This topic provides an overview of read-only ApsaraDB RDS for MySQL instances. If your database system receives a small number of write requests but a large number of read requests, a single primary RDS instance may be overwhelmed by the read requests and your workloads may be interrupted. To offload read requests from the primary RDS instance, you can create one or more read-only RDS instances. Read-only RDS instances help increase the read capability of your database system and the throughput of your application.
For more information about read-only RDS instances that run a different database engine, see the following topics:
Introduction
When a read-only RDS instance is being created, ApsaraDB RDS replicates data from the secondary RDS instance to the read-only RDS instance. Each read-only RDS instance has the same data as the primary RDS instance. After the data on the primary RDS instance is updated, ApsaraDB RDS immediately replicates the data updates to all the read-only RDS instances. You can specify a replication latency on each read-only RDS instance. For more information, see Set the data replication latency of a read-only ApsaraDB RDS for MySQL instance.
Prerequisites
The primary RDS for MySQL instance must meet the following conditions:
The RDS instance runs MySQL 8.0, MySQL 5.7, or MySQL 5.6.
The RDS instance uses the subscription or pay-as-you-go billing method. Serverless RDS instances do not support read-only RDS instances.
The RDS instance runs RDS High-availability Edition.
You can go to the Basic Information page of your RDS instance to obtain the preceding information.
You can create read-only RDS instances that run RDS High-availability Edition or RDS Basic Edition. A read-only RDS instance that runs RDS High-availability Edition includes a primary instance and a secondary instance that work in HA mode. For more information, see RDS High-availability Edition.
Scenarios
If a primary RDS instance is overloaded, you can create read-only RDS instances to offload read requests from the primary RDS instance.
If a primary RDS instance is temporarily unavailable due to backup or maintenance reasons, you can use read-only RDS instances to process read requests. This helps ensure business continuity.
In scenarios such as report analysis, you can use read-only RDS instances to query and analyze a large amount of data. This does not affect the primary RDS instance.
If the read/write splitting feature is used, you can use read-only RDS instances to prevent read/write lock contention and improve system performance and throughput.
Billing rules
Read-only RDS instances support the pay-as-you-go billing method and the subscription billing method. For more information about the prices of read-only RDS instances, see Instance types for read-only ApsaraDB RDS instances.
Usage notes
If the primary RDS instance uses the subscription billing method and you want to create a subscription read-only RDS instance, you can configure the read-only RDS instance to have the same subscription duration as the primary RDS instance.
If the primary RDS instance is locked due to expiration, you can still access the read-only RDS instances of the primary RDS instance. However, the status of the read-only RDS instances changes to Running (Primary Instance Locked).
After the primary RDS instance is released, the subscription read-only RDS instances of the primary RDS instance are automatically refunded and released. However, the pay-as-you-go read-only RDS instances of the primary RDS instance are directly released.
When you release or unsubscribe from the last read-only RDS instance of the primary RDS instance that runs MySQL and has the shared database proxy feature enabled, the system deletes the read/write splitting endpoint provided by the shared database proxy feature. If an application is connected to the RDS instance by using the read/write splitting endpoint, the application cannot access the RDS instance.
Highlights
Billing methods: Read-only RDS instances support both the pay-as-you-go billing method and the subscription billing method. The pay-as-you-go billing method is flexible and allows you to release your read-only RDS instances when you no longer need the instances. The subscription billing method is cost-effective for long-term commitments.
Read-only RDS instances reside in the same region as the primary RDS instance, but optionally in different zones.
Specifications: The specifications of read-only RDS instances can differ from the specifications of the primary RDS instance. You can change the specifications of read-only RDS instances at any time. We recommend that you specify an instance type whose specifications are higher than or equal to the specifications of the instance type of the primary RDS instance. If the specifications of the read-only RDS instance are lower than the specifications of the primary RDS instance, the read-only RDS instance may encounter issues such as high latency and heavy load.
Storage type: Read-only RDS instances use the same storage type as the primary RDS instance.
Storage capacity: The storage capacity of the read-only RDS instance is greater than or equal to the storage capacity of the primary RDS instance.
Network types: The network types of read-only RDS instances can differ from the network type of the primary RDS instance. For more information, see Change the network type of an ApsaraDB RDS for MySQL instance.
Account and database management: The accounts and databases on read-only RDS instances are synchronized from the primary RDS instance. You do not need to manage databases or accounts on read-only RDS instances.
Management of IP address whitelists: When you create a read-only RDS instance, the system replicates the IP address whitelists of the primary RDS instance to the read-only RDS instance. However, the IP address whitelists of the read-only RDS instance are independent of the IP address whitelists of the primary RDS instance. For more information about how to modify the IP address whitelists of a read-only RDS instance, see Change the network type of an ApsaraDB RDS for MySQL instance.
Monitoring and alerting: Read-only RDS instances support monitoring and alerting. You can monitor near 20 metrics, such as disk usage, IOPS, number of connections, CPU utilization, and network traffic.
Primary/secondary switchover: Read-only RDS instances that run RDS High-availability Edition support primary/secondary switchover. You can view primary/secondary switchover logs of read-only RDS instances in the ApsaraDB RDS console.
Limits
You can create up to 10 read-only RDS instances.
Instance backup: You cannot configure automatic backup policies or manually create backups for a read-only RDS instance because these operations are performed on the primary RDS instance. You can only configure a retention policy for binary log files of the read-only RDS instance. For more information, see Delete the binary log files of an ApsaraDB RDS for MySQL instance.
Instance restoration:
Full data restoration (instance-level restoration): You cannot restore full data of a read-only RDS instance to a new RDS instance by using backup sets or to a specific point in time. For more information, see Restore full data.
Restoration of individual databases and tables: You cannot restore individual databases or tables of a read-only RDS instance to the original RDS instance or a new RDS instance by using backup sets or to a specific point in time. For more information, see Restore individual databases and tables.
You cannot migrate data to read-only RDS instances.
You cannot create or delete databases on read-only RDS instances.
You cannot create or delete accounts, grant permissions to accounts, or change the passwords of accounts on read-only RDS instances.
Creation of read-only RDS instances
Create a read-only RDS instance. For more information, see Create a read-only RDS instance.
FAQ
After I create accounts on my primary RDS instance, can I manage the accounts on the read-only RDS instances of my primary RDS instance?
The accounts that are created on your primary RDS instance are synchronized to the read-only RDS instances. You cannot manage the accounts on the read-only RDS instances. The accounts that are created on your primary RDS instance are synchronized to the read-only RDS instances and have only the read permissions on the read-only RDS instances.
Can I pause the billing for my read-only RDS instances? Can I set the read weights of my read-only RDS instances to 0 to stop the billing?
No, you cannot pause the billing for your read-only RDS instances. If you no longer need your read-only RDS instances, we recommend that you immediately release the instances. For more information, see Release or unsubscribe from an ApsaraDB RDS for MySQL instance.
If the database proxy feature is disabled for my RDS instance, can I set read weights for the read-only RDS instances that are attached to my RDS instance?
No, you cannot set read weights for the read-only RDS instances that are attached to your RDS instance if the database proxy feature is disabled for your RDS instance. You can configure the endpoints of the primary RDS instance and its read-only RDS instances in different applications to implement read/write splitting and load balancing.
When do I need to purchase read-only RDS instances that run RDS High-availability Edition?
If your workloads are read-heavy, we recommend that you purchase read-only RDS instances that run RDS High-availability Edition to offload the read requests from your primary RDS instance. This helps ensure business stability.
If a secondary RDS instance is provisioned for my primary RDS instance, do I need to purchase read-only RDS instances that run RDS High-availability Edition?
Yes, if your primary RDS instance needs to process a large number of read requests, we recommend that you purchase read-only RDS instances that run RDS High-availability Edition to offload the read requests from your primary RDS instance. The secondary RDS instance ensures the business availability whereas read-only RDS instances are used to implement read/write splitting and process read requests.