Updated on 2024-04-11 GMT+08:00

Introducing Read Replicas

Introduction

RDS for PostgreSQL supports read replicas.

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. You need to separately configure connection addresses of the primary DB instance and each read replica on your applications so that all read requests can be sent to read replicas and write requests to the primary DB instance.

A read replica uses a single-node architecture (without a standby node). Changes to the primary DB instance are automatically synchronized to all associated read replicas through the native PostgreSQL replication function. High network latency of the primary node affects data synchronization between the primary DB instance and read replicas. Read replicas and the primary DB instance must be in the same region but can be in different AZs.

Billing Standards

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

Functions

  • The specifications of a read replica must be at least equal to those of the primary DB instance to prevent long delay and high load.
  • 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.
  • You do not need to maintain separate database accounts or databases. They are synchronized from the primary DB instance.
  • 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.
  • You can bind EIPs to read replicas and unbind EIPs from read replicas.
  • Read replicas do not support automated backups or manual backups.
  • 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 and deletion.
  • Read replicas do not support database account creation.
  • The specifications of read replicas must be greater than or equal to the specifications of the current primary DB instance.

Constraints

  • Primary DB instances and read replicas billed on the yearly/monthly basis can be unsubscribed only through the RDS console.
  • If you want to unsubscribe both primary DB instances and read replicas that are billed on the yearly/monthly basis, unsubscribe the read replicas first.
  • Expired primary DB instances are recycled in the recycle bin and deleted after the retention period expires. The associated read replicas must be unsubscribed before the DB instances are deleted. After the DB instances are deleted, its associated read replicas cannot be unsubscribed.
  • You can purchase read replicas only for your created primary DB instance.
  • A maximum of five read replicas can be created for a DB instance.

Creating and Managing a Read Replica