Managed Databases
Advanced 13 min read Managed Databases

Global and Read Replicas

Replicas that read faster and farther

Read replicas scale out reads in one region; global clusters (Aurora Global, Azure geo-replicas, Cloud SQL cross-region) replicate across distances for disaster recovery and low-latency reads worldwide.

read replicaglobal databasecross-regionbinlogreplication lagAurora Global
Prerequisites: Database High Availability
Before we start

What you will learn

  • Use read replicas to scale reads safely
  • Explain replication lag and consistency consequences
  • Design global clusters for DR and latency
In 60 seconds

A read replica is an async copy handling reads while the primary writes. Global/regional replicas extend copies across regions for disaster recovery and near-local reads — but lag and consistency must be managed.

Introduction

What is this?

Read replicas: RDS read replicas (same-region, cross-region), Aurora replicas (cluster), Azure SQL geo-replicas, Cloud SQL read replicas (5 per primary typically). Lag depends on load/links; readers may serve slightly stale data — design accordingly ('read your writes' via session affinity). Global: Aurora Global Database (cross-region, ~1s lag, 3-region), Cosmos global distribution with consistency sliders, Cloud Spanner multi-region with strong consistency.

Motivation

Why do you need it?

  • Separating reporting from the write path removes query contention.
  • Cross-region copies create DR sites with read access.
  • Replicas double as HA promotion candidates (async-commit trade-off).
  • Global reads route users to the nearest copy for latency.
Think about it

Mental model

Imagine

News desks re-printing the morning paper to regional editions

Think of

Global read replicas

The newsroom (primary) writes once; each regional edition (replica) prints from the wire with a slight time offset — readers near each desk get their paper fast, yet may miss the 6:02am headline by minutes (lag).

Mechanics

How it works

  • The primary streams binary/WAL changes; replicas apply them asynchronously in the background.
  • Replica lag = last applied vs primary; visible as stale reads immediately after a write.
  • Promotion turns a replica into a primary (losing un-replicated writes): re-route writes carefully.
  • Cross-region = network round trips escalate lag; Aurora Global/Azure geo optimize transport.
  • Session affinity (read-your-writes) or time-bounded reads reconcile staleness.

Global topology.

Primary
Region replica
DR region
Local readers
Promote
Hands-on

Examples

Create a read replica and route reads to it

Create a read replica and route reads to it
# AWS: read replica of an RDS instance
aws rds create-db-instance-read-replica \
  --db-instance-identifier app-db-readonly \
  --source-db-instance-identifier app-db --region us-east-1
# app config: writer -> cluster endpoint, reader -> replica endpoint
# AWS Aurora Global cluster:
aws rds create-global-cluster --global-cluster-identifier app-global \
  --engine aurora-postgresql --global-cluster-members '[
    {"db-cluster-identifier":"app-us-east-1"},
    {"db-cluster-identifier":"app-eu-west-1"}]'

Replicas accept reads transparently; the writer endpoint stays on the primary.

Real world

In production

  • A retail BI tier reads from a dedicated replica; heavy OLAP queries never touch the DB primary.
  • A global SaaS uses Aurora Global with eu-west-1 as active reads + DR promotion path.
  • Cosmos DB multi-master writes across two regions with tunable consistency.
Guidelines

Best practices

  • Direct report/BI reads to replicas, keep writes to the cluster writer.
  • Track lag; bill report jobs on lag budget (wait for the replica to catch up).
  • Promote deliberately during DR, never accidentally (flag alerts on writes to a replica).
  • Limit replica count per primary (latency + binlog cost); tear down idle replicas.
Watch out

Common mistakes

  • Sending write-then-read-your-own-write through replicas (stale response).
  • Scaling reads with replicas while the primary still bottlenecked (schema/index problem).
  • Assuming cross-region replica is 'regional HA with zero-loss' — it's async.
  • Promoting a lagged replica for a write path without catching it up first.
Root cause analysis

Common issues

Error
Replica lag grows unboundedly
Root cause

Replicas under-powered or write DDL/load locks

Fix

Resize replicas, reduce write amplification, split heavy analytics onto its own stack.

Error
Reports read stale recent writes
Root cause

Reporting path through async replica

Fix

Add lag-aware routing: read-your-writes or a freshness check before hooks are allowed.

When things break

Debugging tips

  • Stale data: check replica lag metric on the specific replica and the network path.
  • Read-only replica writes fail: that's by design — verify the client used the right endpoint.
  • Lag spikes correlate with heavy OLAP on the primary — move such jobs off the write path.
  • Global lag: measure per-region poll; switch report feeds to the nearest replica's DB for freshness.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/1
1

A read replica can become the primary during a disaster without data loss if it lags the primary.

Go deeper

Official documentation

AWS — Aurora Global Database
docs
Azure — Geo-replication
docs
GCP — Cloud SQL replicas
docs