ApsaraDB RDS:MySQL read-only instances

Overview

A read-only instance replicates data from the primary instance. All data updates are synchronized automatically. You can also configure a replication delay for a read-only instance.

Troubleshoot replication lag: Causes of and solutions for replication latency of an ApsaraDB RDS for MySQL read-only instance.

Prerequisites

Use cases

• Offload an overloaded primary instance by directing read requests to read-only instances.

• During primary instance backups or maintenance, forward read requests to a read-only instance to maintain application availability.

• Run data-intensive reporting and analytics on read-only instances without affecting primary instance performance.

• In a read/write splitting architecture, read-only instances eliminate lock contention between read and write operations, improving throughput.

Billing

Read-only instances support subscription and pay-as-you-go billing. Read-only instance specifications.

Usage notes

• For subscription primary instances, you can align the read-only instance's subscription duration with the primary.

• If your primary instance is locked due to an overdue payment, you can still access any unexpired read-only instances. Their status changes to Running (Primary Instance Locked).

• When a primary instance is released, subscription read-only instances are refunded and released. Pay-as-you-go read-only instances are released immediately.

• When the last read-only instance of a primary instance with the shared database proxy is released, the proxy's read/write splitting endpoint is deleted. Clients using this endpoint will lose connectivity.

Features

• Billing method: Pay-as-you-go for flexibility, or subscription for long-term cost savings.

• Region and availability zone: A read-only instance must be in the same region as its primary instance but can be in a different availability zone.

• Specifications: Can differ from the primary instance and be changed at any time. Use specifications equal to or greater than the primary to avoid high replication lag and load.

• Storage type: A read-only instance must use the same storage type as its primary instance.

• Storage capacity: The storage capacity of a read-only instance cannot be smaller than that of its primary instance.

• Network type: The network type of a read-only instance can be different from that of the primary instance.

• Account and database management: Accounts and databases are synchronized from the primary instance and cannot be managed on the read-only instance.

• IP address whitelist: The primary instance's whitelist is copied to a new read-only instance, but the two whitelists are independent afterward. Configure an IP address whitelist.

• Monitoring and alerting: Supported for nearly 20 metrics, including disk capacity, IOPS, connections, CPU utilization, and network traffic.

• Primary/secondary switchover: A read-only instance of High-availability Edition supports primary/secondary switchover and allows you to view switchover logs.

Limitations

• Number of read-only instances: Up to 10 per primary instance.

• Instance backup: Backups run on the primary instance only. You cannot configure backup policies or create backups for a read-only instance. You can only set a retention policy for local log files.

• Instance restoration:

  • Full data restoration (instance-level): You cannot restore data from a read-only instance to a new instance by backup set or point-in-time recovery.

  • Database and table restoration (database- or table-level): You cannot restore individual databases or tables from a read-only instance to the original or a new instance by backup set or point-in-time recovery.

• Data migration: You cannot migrate data to a read-only instance.

• Database management: You cannot create or delete databases on a read-only instance.

• Account management: You cannot create or delete accounts, grant permissions to accounts, or change account passwords on a read-only instance.

Create a read-only instance

Create an ApsaraDB RDS for MySQL read-only instance

FAQ

• Can I use accounts created on the primary instance to access the read-only instances?

  Yes. Accounts are synchronized from the primary instance with read-only permissions. You cannot manage accounts on a read-only instance.

• Can I pause the billing for a read-only instance? If I set its read weight to 0, will billing stop?

  No, you cannot pause billing for a read-only instance. If you no longer need the instance, release or unsubscribe from an instance immediately.

• If the database proxy service is not enabled, can I configure the read weights for read-only instances?

  No. Read weight configuration requires the database proxy service. Without it, configure separate connection endpoints for the primary and read-only instances in your application.

• When should I purchase a read-only instance of High-availability Edition?

  For read-heavy workloads, purchase High-availability Edition read-only instances to ensure high availability.

• If my primary instance already has a secondary instance, do I still need a read-only instance of High-availability Edition?

  A secondary instance provides high availability; a read-only instance offloads read traffic via read/write splitting. For read-heavy workloads, High-availability Edition read-only instances are still recommended.

• How do I implement read/write splitting for an instance of Basic Edition?

  Basic Edition instances do not support read-only instances. To implement read/write splitting, you must first change the edition of an instance to High-availability Edition. After you create a read-only instance, ApsaraDB RDS automatically enables read/write splitting, and you can then adjust read weights.