3.1.3.2. RDS Read Replicas and Multi-AZ

3.1.3.2. RDS Read Replicas and Multi-AZ

💡 First Principle: RDS Read Replicas enhance database read performance by distributing workloads. Multi-AZ deployments ensure high availability and fault tolerance through automatic failover.

RDS Read Replicas enhance database read performance by distributing workloads. Multi-AZ deployments ensure high availability and fault tolerance through automatic failover.

Amazon Relational Database Service (RDS) provides two key features for enhancing database scalability and availability:

• Read Replicas: Asynchronously replicated copies of your primary database instance. Primarily for scaling read performance. They asynchronously replicate data from the primary database, allowing you to offload read-heavy queries from the primary instance and improve application responsiveness. Can be in the same or different AWS Region for disaster recovery.
• Multi-AZ Deployments: A deployment option that provides high availability and automatic failover for your RDS database. Focuses on high availability and disaster recovery within a single AWS Region. It synchronously replicates data to a standby instance in a different Availability Zone (AZ), providing automatic failover with minimal downtime in case of primary instance failure or AZ outage.
• Promoting a read replica: Promotion is a manual action that stops replication and turns the replica into a standalone, writable DB instance (it reboots and takes a few minutes). The promoted instance keeps its own endpoint, so applications must be repointed to it (or reached through a DNS record you update).
• Amazon RDS Proxy: A fully managed database proxy that pools and shares connections. Clients such as Lambda functions that open and close many short-lived connections reuse the proxy's pooled connections instead of exhausting database memory and CPU; it also shortens failover time. It is not a substitute for Read Replicas (read scaling) or Multi-AZ (database HA).

Key Differences:

• "Read Replicas": Scalability (reads), asynchronous, manual failover.
• "Multi-AZ": High Availability (standby is passive — it cannot serve reads and exists only for automatic failover), synchronous replication.

More Read Replica and Aurora Facts:

• Creating replicas: The source DB instance must have automated backups enabled (backup retention period greater than 0). Replicas can live in the same AZ, another AZ or another Region, and a Multi-AZ primary can also have read replicas.
• Aurora Replicas: Up to 15 per cluster. They read the same shared cluster storage volume as the writer instead of replaying a binlog, so replica lag is usually far below 100 ms, much lower than RDS MySQL's binlog-based replicas. They also serve as automatic failover targets.
• Aurora endpoints: The cluster (writer) endpoint points at the primary. The reader endpoint load-balances across all replicas. A custom endpoint targets a subset you choose (e.g., only the large replicas used for reporting). Instance endpoints target one specific instance.

Scenario: An e-commerce platform uses Amazon RDS for PostgreSQL for its primary database. It experiences frequent read spikes (e.g., product catalog queries) and requires high availability for all transactions.

Visual: RDS Read Replicas and Multi-AZ

⚠️ Common Pitfall: Using a "Read Replica" for high availability/disaster recovery for write operations. "Read Replicas" are for read scaling and asynchronous. "Multi-AZ" is for HA with synchronous replication.

Key Trade-Offs:

• Read Scaling ("Read Replicas") vs. Write Availability ("Multi-AZ"): "Read Replicas" scale read throughput but don't protect write availability. "Multi-AZ" provides HA for the primary (write) instance but doesn't scale read operations by itself.

Reflection Question: How do RDS Read Replicas and Multi-AZ deployments collectively contribute to a resilient and scalable database architecture by offloading read traffic and ensuring automatic failover for high availability?