Amazon RDS Read Replicas: Scaling & Performance

This study guide focuses on the concepts of horizontal scaling within Amazon RDS and Amazon Aurora, specifically through the implementation of Read Replicas to optimize database performance and availability.

Learning Objectives

After studying this guide, you should be able to:

• Differentiate between Vertical and Horizontal database scaling.
• Explain the mechanics and limitations of Asynchronous Replication.
• Contrast the use cases for Read Replicas versus Multi-AZ Deployments.
• Identify specific replica limits for RDS and Amazon Aurora.
• Understand the process and risks of Promoting a replica to a master instance.

Key Terms & Glossary

• Asynchronous Replication: A data mirroring method where the master instance does not wait for a confirmation from the replica before completing a write. This results in "replication lag."
• Read-Only Endpoint: A DNS name provided by RDS that connects applications specifically to the read replicas rather than the master database.
• Vertical Scaling (Scaling Up): Increasing the compute, memory, or network resources of a single existing instance.
• Horizontal Scaling (Scaling Out): Adding more instances (replicas) to distribute the load across multiple nodes.
• Promotion: The process of converting a read-only replica into a standalone, primary (read-write) database instance.

The "Big Idea"

In modern cloud architectures, the most common database bottleneck is Read Heaviness. While a single master instance must handle all writes to maintain data integrity, the read load can be distributed. Read Replicas allow an application to scale horizontally, ensuring that reporting tools and user queries don't overwhelm the primary database responsible for business-critical transactions.

Formula / Concept Box

Hierarchical Outline

1. Database Scaling Strategies
   • Vertical Scaling: Upgrading instance class (e.g., db.t3.micro to db.m5.large).
   • Horizontal Scaling: Creating Read Replicas to offload queries.
2. Read Replica Mechanics
   • Function: Master handles Writes; Replicas handle Reads.
   • Consistency: Asynchronous nature means data might be slightly stale (Lag).
   • Connectivity: RDS provides a Read-only Endpoint for routing traffic.
3. Deployment Topology
   • Cross-AZ: Replicas can be in different Availability Zones.
   • Cross-Region: Replicas can be in different Regions (useful for global users/DR).
4. Operational Tasks
   • Creation: Can be created from a running instance.
   • Promotion: Manual process; breaks replication and makes the replica a Master.
5. Engine Support
   • Supported: MySQL, PostgreSQL, MariaDB, Oracle, Aurora, SQL Server (Enterprise).

Visual Anchors

Database Scaling Flow

Scaling Types Comparison

\begin{tikzpicture} % Vertical Scaling \draw[thick] (0,0) rectangle (1,1) node[midway] {Small}; \draw[->, thick] (0.5, 1.1) -- (0.5, 1.6) node[above] {Scale Up}; \draw[thick] (0, 1.8) rectangle (1, 3.3) node[midway] {Large}; \node at (0.5, -0.5) {Vertical};

% Horizontal Scaling \draw[thick] (3,0) rectangle (4,1) node[midway] {DB}; \draw[->, thick] (4.1, 0.5) -- (4.6, 0.5) node[right] {Scale Out}; \draw[thick] (5.5,0) rectangle (6.5,1) node[midway] {DB}; \draw[thick] (7,0) rectangle (8,1) node[midway] {DB}; \draw[thick] (8.5,0) rectangle (9.5,1) node[midway] {DB}; \node at (6.5, -0.5) {Horizontal}; \end{tikzpicture}

Definition-Example Pairs

• Read-Heavy Application
  • Definition: An application where the number of data retrieval requests (SELECT) significantly outweighs data modification requests (INSERT/UPDATE).
  • Example: A social media platform where thousands of users view a post (reads), but only one person authored it (write).
• Replication Lag
  • Definition: The time delay between a change happening on the master and that change appearing on the replica.
  • Example: A user updates their profile picture, but when they immediately refresh the page, the old picture still shows because the replica hasn't received the update yet.

Worked Examples

Scenario 1: The Holiday Sale

Problem: An e-commerce site expects a 10x surge in traffic. The database CPU is currently at 70%. CloudWatch shows most of the load is from users searching for products. Solution: Add 3 RDS Read Replicas. Update the application connection string for the "Product Search" module to use the Read-only Endpoint. This offloads the search queries from the Master, dropping its CPU usage and allowing it to focus on processing Orders (Writes).

Scenario 2: Global Reporting

Problem: A company in New York has a database in us-east-1. Their London office complains that their daily reports take too long to run due to network latency. Solution: Create a Cross-Region Read Replica in eu-west-2 (London). The London office points their reporting tools to the local replica's endpoint, reducing latency and avoiding impact on the New York production database.

Checkpoint Questions

1. What is the maximum number of Read Replicas you can have for a standard Amazon RDS MySQL instance?
2. True or False: Read Replicas are primarily used for Disaster Recovery (DR) and offer automatic failover.
3. If your master database fails, what manual action can you take with a Read Replica to restore write capabilities?
4. Why is replication to a Read Replica considered "asynchronous" rather than "synchronous"?

[!TIP] Exam Tip: If the question asks about Performance/Scaling, think Read Replicas. If the question asks about Availability/Durability, think Multi-AZ.

▶Click to view Checkpoint Answers

1. 5 (Aurora supports up to 15).
2. False. Multi-AZ is for DR/High Availability; Read Replicas are for performance/scaling (though they can be promoted manually).
3. Promote the Read Replica to a standalone Master instance.
4. To ensure that the Master instance can process writes as fast as possible without waiting for the replicas to acknowledge the data.