Lecture 10: Cloud Replicated DB, Aurora

What this lecture covers

The lecture explains how Amazon's Aurora database achieves a large performance win over naive replicated MySQL on AWS infrastructure, and it doubles as a tutorial on how transactional databases work internally (write-ahead logging, undo/redo recovery) and on quorum-based replication. It follows the chain replication and CRAQ material by showing a third replication design, one that is optimized specifically for a database workload rather than being a general-purpose storage layer.

After watching, you should be able to explain why sending data pages over the network is expensive compared to sending log records, describe how Aurora's quorum system (6 replicas, write to 4, read from 3) tolerates a dead availability zone plus another dead server, and explain how sharding, fast re-replication, and read-only replicas fit into the design.

Key ideas

• EC2 and EBS background: EC2 instances originally used locally attached disks that vanished on hardware failure; EBS added fault tolerance by chain-replicating each volume to a pair of servers, but only within one availability zone.
• Write-ahead logging: before modifying a data page, a database writes log entries recording the old and new values, so a crash can be recovered by redoing committed transactions and undoing uncommitted ones.
• RDS's bottleneck: mirroring a database across availability zones by shipping full data-page writes (often 8KB each) over the network saturated bandwidth, motivating Aurora's redesign.
• Aurora's key idea: only log records, not data pages, are sent across the network to storage replicas; storage servers apply log entries to pages themselves, lazily, only when a page is actually requested.
• Quorum replication: with N replicas, writes must reach W of them and reads must consult R of them, with R + W > N guaranteeing overlap; version numbers (not voting) let a reader pick the freshest value.
• Aurora's specific quorum: 6 replicas across 3 availability zones, W=4, R=3, chosen to tolerate one dead availability zone for writes, and one dead zone plus one more server for reads.
• Sharding and fast recovery: databases larger than one server's capacity are split into 10GB "protection groups," each independently replicated six ways; recovering a failed server is parallelized across many machines to avoid a slow single-link transfer.
• Read-only replicas: separate read replica instances apply the primary's log stream to their own caches and serve reads directly from storage, lagging slightly but offloading most read traffic from the writer.

Walkthrough

Motivation and history: EC2, EBS, and their limits (0:00)

Aurora is introduced as a successful, application-specific redesign that claims a 35x throughput improvement over an unspecified baseline. The lecture traces the backstory: EC2 instances first used locally attached disks that were lost if the hardware died, which was fine for stateless web servers but bad for databases. EBS fixed this by chain-replicating each volume to a pair of servers, but for cost reasons kept both replicas in the same availability zone, so an entire data center outage could still lose data.

How transactional databases work (13:21)

Because Aurora is a redesign of MySQL's storage layer, the lecture walks through standard transaction processing: a transaction locks the data it touches, the database journals old and new values to a write-ahead log before modifying cached pages, and only after the log (and a commit record) is durable can the transaction be acknowledged to the client. Later, modified pages are lazily written back to disk; on crash recovery, committed transactions are redone from the log and uncommitted ones are undone using the old values.

RDS and the mirroring bottleneck (23:44)

An intermediate design, RDS, mirrored a full MySQL instance's log and data-page writes across availability zones by forwarding every write to a second EBS-backed pair in a different data center. This gave good fault tolerance but was slow, because full 8KB (or larger) data-page writes had to cross the network for every transaction, not just the few dozen bytes of log data actually needed to describe the change.

Aurora's design: log-only replication and quorums (30:52)

Aurora's storage system understands only MySQL log records, not generic disk blocks: the database server sends log entries to six replicas spread across three availability zones, and each storage server applies those entries to its own cached copy of a page only when a read actually needs that page. Because log entries are tiny compared to data pages, more replicas can be used without a proportional bandwidth cost. Aurora's fault-tolerance goals—write despite one dead availability zone, read despite one dead zone plus one more server, tolerate transient slowness—are met with a classic quorum scheme (N=6, W=4, R=3), where version numbers let a reader pick the most recent value among possibly-conflicting replies, and R+W>N guarantees any read quorum overlaps any write quorum.

Storage server internals and crash recovery (52:33)

Storage servers store old page versions plus the log entries that apply to them, materializing updated pages only on demand. Because the database server tracks how far each storage server's log has progressed, ordinary reads go to a single up-to-date replica rather than requiring a quorum read; quorum reads are only needed during database-server crash recovery, to find the first missing log entry and discard any uncommitted transaction's later entries.

Sharding, fast re-replication, and read replicas (1:01:53)

Databases larger than one machine's capacity are split into 10GB protection groups, each replicated six ways independently, with log entries routed only to the protection groups whose pages they touch. Because each physical storage server holds segments from many customers' protection groups, recovering from a server failure is parallelized across roughly as many other servers as there are segments, cutting recovery time from thousands of seconds to about ten. Finally, read-heavy workloads are served by up to fifteen read-only replica databases that apply the primary's log stream to their own caches and read pages directly from storage, trading a small amount of staleness for offloading the primary almost entirely.

Before you watch

• Review chain replication and CRAQ from the previous lecture, since Aurora's storage layer borrows chain-replication ideas for propagating writes.
• Be comfortable with the general idea of a write-ahead log from the Zookeeper/Raft discussions, since the lecture builds directly on it.
• Some familiarity with basic database terms (transaction, commit, B-tree) helps but the lecture explains what it needs.

Check your understanding

1. Why does write-ahead logging require storing both the old and new value for each modified field, not just the new value?
2. Why was RDS's mirrored-writes approach slow, and what specifically did Aurora change to fix it?
3. Explain why R + W > N guarantees that a read quorum always overlaps a write quorum, and why version numbers (not majority voting) are needed to pick the correct value.
4. Why does Aurora's database server usually avoid quorum reads during normal operation, and when does it need them?
5. How does splitting a failed storage server's data across many replacement servers speed up recovery compared to a single-server-to-single-server copy?