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

Read-only, secondary, and disaster recovery instances

• A read-only instance must be in the same region as its primary instance but can be in a different availability zone. A secondary instance must be in the same region as its primary instance. A disaster recovery instance must be in a different region from its primary instance.

• You can create up to 10 read-only instances. Secondary instance count is fixed (for example, one per High-availability Edition instance). A disaster recovery setup pairs a primary instance with a disaster recovery instance in a different region.

• A read-only instance serves read traffic after creation and read weight configuration. Secondary and disaster recovery instances do not serve traffic during normal operation.

The following figure shows the instance topology.

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.

• Performance optimization (MySQL only): Provides optimization suggestions such as storage engine checks, primary key validation, large table detection, excessive index identification, and missing index detection.

• 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.