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, the primary RDS instance may be overwhelmed by the read requests and your workloads may be interrupted. In this case, you can create one or more read-only RDS instances to offload read requests from the primary RDS instance. This scales the read capability of your database system and increases the throughput of your application.

For more information about read-only RDS instances that run other database engines, see the following topics:

Background information

When you create a read-only RDS instance, ApsaraDB RDS replicates data from the secondary RDS instance. The created 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 set a replication latency on each read-only RDS instance. For more information, see Set a replication delay for a read-only ApsaraDB RDS for MySQL instance.

Note Each read-only RDS instance runs in the high availability architecture that allows the read-only RDS instance to have a secondary instance.

Prerequisites

The primary RDS instance runs one of the following MySQL versions and RDS editions:

  • MySQL 8.0 on RDS High-availability or Enterprise Edition
  • MySQL 5.7 on RDS High-availability or Enterprise Edition
  • MySQL 5.6
Note If the primary RDS instance runs MySQL 5.7 on RDS Enterprise Edition but you cannot create read-only RDS instances, click here to submit a ticket.

Billing

Read-only RDS instances are charged based on the pay-as-you-go or subscription billing method. For more information about pricing, see Read-only instance types.

Features

  • Read-only RDS instances support both the pay-as-you-go and subscription billing methods. The pay-as-you-go billing method is flexible and allows you to release your read-only RDS instances when the instances are no longer needed. 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 possibly in different zones.
  • 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 the specifications of read-only RDS instances be greater than or equal to the specifications of the primary RDS instance. If the specifications of a 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 or heavy load.
  • 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.
  • Read-only RDS instances do not require database or account maintenance. This is because their database and account data is synchronized from the primary RDS instance.
  • When you create a read-only RDS instance, ApsaraDB RDS replicates the whitelist settings of the primary RDS instance to the read-only RDS instance. However, the whitelist settings on the read-only RDS instance are independent of the whitelist settings that are configured on the primary RDS instance. For more information about how to modify the whitelist settings of a read-only RDS instance, see Control access to an ApsaraDB RDS for MySQL instance.
  • Read-only RDS instances support monitoring and alerting. You can monitor near 20 metrics, such as the disk usage, input/output operations per second (IOPS), number of connections, CPU utilization, and network traffic.

Limits

  • The maximum number of read-only RDS instances allowed varies based on the memory capacity.
    Database engine Memory capacity Maximum number of read-only RDS instances
    MySQL ≥ 64 GB 10
    < 64 GB 5
  • You cannot configure backup policies or manually create backups for read-only RDS instances. These are configured and created on the primary RDS instance.
  • The following limits are imposed on instance restoration:
    • You cannot create a temporary RDS instance to which you can restore the data of a read-only RDS instance by using a backup set or from a point in time. In addition, you cannot overwrite a read-only RDS instance by using a backup set.
    • After a read-only RDS instance is created, you cannot use a backup set to overwrite the data on the primary RDS instance.
  • 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, authorize accounts, or change the passwords of accounts on read-only RDS instances.

Create a read-only RDS instance

For more information, see Create a read-only ApsaraDB RDS for MySQL instance.

FAQ

  • After I create accounts on my primary RDS instance, can I manage the accounts on the read-only RDS instances?

    No, although the accounts 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 have only the read permissions on the read-only RDS instances.

  • Can I pause the billing for my read-only RDS instances? And 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 them. For more information, see Release or unsubscribe from an ApsaraDB RDS for MySQL instance.