RDS Read Replica Replication Lag

Diagnose and reduce replication lag on RDS read replicas to ensure data freshness for reads.

Overview

Overview

RDS read replica replication lag is how far behind the primary a replica is, in seconds. It matters for every application that offloads reads to replicas, because a lagging replica serves stale data, causing user-visible inconsistencies and subtle bugs.

Why lag happens

Lag is the gap between the primary's write throughput and the replica's apply throughput. MySQL replication is asynchronous, and in older MySQL versions the replica's SQL thread applies binlog events serially by default.

Root cause: big transactions and schema changes

A single ALTER TABLE on a 100-million-row table with default MySQL settings can cause 10-30 minutes of lag during the copy phase. The fix is online schema change tools that copy in small chunks.

  • MySQL — pt-online-schema-change (Percona Toolkit) or gh-ost (GitHub Online Schema Change)
  • PostgreSQL — CREATE INDEX CONCURRENTLY

Checks and what each tells you

  • CloudWatch ReplicaLag on the replica — Seconds behind the primary; the monitoring baseline
  • Recent large transactions or DDL on the primary — Whether one big event is blocking apply

How much lag is acceptable

  • Reporting and analytics — Seconds or even minutes
  • Read-your-writes (user writes, then reads back) — Any lag above zero can show stale state

Read-your-writes without reading everything from the primary

> [!TIP] This keeps primary read traffic low while keeping each user's own writes visible.

Parallel replication

MySQL 5.7+ supports multi-threaded replication with slave_parallel_workers and slave_parallel_type=LOGICAL_CLOCK. It applies in parallel the transactions that committed in the same binlog group on the primary.

> [!NOTE] Parallel replication gives meaningful throughput gains when several independent tables are written concurrently.

Key concepts

ReplicaLag
CloudWatch metric on RDS read replicas measuring the time in seconds between the latest transaction applied on the primary and the latest transaction applied on the replica.
Parallel Replication
A MySQL and PostgreSQL feature that allows the replica to apply binlog events from multiple threads simultaneously, reducing lag on multi-table write workloads.
pt-online-schema-change
A Percona Toolkit utility that executes MySQL schema changes by copying the table in chunks with triggers to sync concurrent writes, avoiding long table locks.
gh-ost
GitHub Online Schema Change — uses binlog streaming instead of triggers to sync a shadow table during schema migrations, creating lower load on the primary than pt-osc.
Read-Your-Writes Consistency
A consistency guarantee ensuring that after a user writes data, their subsequent reads always reflect that write — requires careful routing when using read replicas.

When to use it

  • Diagnosing why read replicas are serving stale data inconsistently
  • Explaining the impact of large transactions and ALTER TABLE on replica lag
  • Designing read-your-writes consistency patterns using RDS replicas
  • Choosing between pt-online-schema-change and gh-ost for zero-downtime schema changes
  • Configuring parallel replication to reduce steady-state replication lag

Interview questions

  • Why does a single large transaction cause a replica lag spike, and what is the correct fix?
  • How do you implement read-your-writes consistency when using RDS read replicas?
  • What is the difference between pt-online-schema-change and gh-ost, and when should you use each?

Sign up free to read the full topic

More Troubleshooting topics

Start free on Cariara · Coding problems · System design studio