Introducing Read Replicas

Introduction

Currently, RDS for MySQL supports read replicas and read/write splitting.

In read-intensive scenarios, a single DB instance may be unable to handle the read pressure and service performance may be affected. To offload read pressure on the primary DB instance, you can create one or more read replicas in the same region as the primary instance. These read replicas can process a large number of read requests and increase application throughput.

Once read replicas are created, you can enable read/write splitting. Write requests are automatically routed to the primary DB instance and read requests are routed to read replicas by user-defined weights.

If read/write splitting is disabled, separately configure connection addresses for the primary DB instance and each read replica on your applications so that read requests are sent to read replicas and write requests are sent to the primary DB instance.

A read replica uses a single-node architecture (without a standby node). Changes to the primary DB instance are also automatically synchronized to all associated read replicas through the native MySQL replication function. The synchronization is not affected by network latency. Read replicas and the primary DB instance must be in the same region but can be in different AZs.

Single Read Replicas and HA Read Replicas

In read-intensive scenarios, read replicas help offload read pressure from the primary instance.

Data is replicated from the primary instance to read replicas asynchronously. Although there is a replication delay, the data on read replicas will eventually be consistent with that on the primary instance. You can use read replicas if you do not mind such a replication delay.

Read replicas include single read replicas and HA read replicas.

• Single read replicas: If you choose single read replicas, you are advised to buy more than one single read replica and enable database proxy. That way, if one read replica fails, the database proxy can route traffic to other read replicas or the primary DB instance.
• HA read replicas: If the physical server where the primary read replica resides is faulty, the standby read replica automatically takes over workloads from the primary read replica. When you purchase a read replica, select the same value for Table Name as the DB instance.

Recommendations for using read replicas:

• Configure no more than two HA read replicas for a DB instance.
• If your DB instance is associated with more than two read replicas, enable database proxy for cost-effectiveness.

If the replication between a read replica (single or HA) and the DB instance is abnormal, it takes a long time to rebuild and restore the read replica (depending on the data volume).

Billing Standards

Read replicas are billed on a yearly/monthly or pay-per-use basis.

Functions

• Read replica specifications can be different from primary DB instance specifications.
  

  To prevent a read replica creation failure, long delay, and high load of the read replica, it is recommended that the specifications of the read replica be at least equal to those of the primary instance.

• Read replicas are billed on a yearly/monthly or pay-per-use basis. Yearly/monthly billing provides a larger discount than pay-per-use billing and is recommended for long-term users.
• Read replicas support system performance monitoring.

  RDS provides up to 20 monitoring metrics, including storage space, IOPS, the number of database connections, CPU usage, and network traffic. You can view these metrics to learn about the load on DB instances.

Constraints

• A maximum of 10 read replicas can be created for a DB instance.
• You can purchase read replicas only for your created primary DB instance.
• You cannot stop a read replica without stopping the primary instance. If you stop a primary instance, read replicas (if there are any) will also be stopped.
• All databases and tables in the primary instance are synchronized to read replicas. Data of the primary instance, standby instance, and read replicas is consistent.
• Read replicas do not support automated backups or manual backups. Read replicas do not provide binlogs.
• Read replicas do not support restoration from backups to new, existing, or original read replicas.
• Data cannot be migrated to read replicas.
• Read replicas do not support database creation or deletion.
• Read replicas do not support database account creation. Create database accounts on the primary DB instance. For details, see Creating a Database Account.

• Read replicas cannot be recycled after they are deleted.

Creating and Managing a Read Replica

• Creating a Single Read Replica
• Creating Read Replicas in Batches
• Managing a Read Replica