How Aurora Achieves 5× MySQL Speed: Inside AWS’s Distributed Database Architecture

What is Aurora

Aurora’s core structure consists of a stateless database layer (handling SQL and transactions) and a storage service built on Amazon S3. The design follows a service‑centric architecture where all data resides in the storage service, while compute nodes remain without persistent state.

The system separates compute from storage, modifying MySQL 5.6 code to achieve this split. This introduces network latency as the primary bottleneck, as highlighted in the original SIGMOD paper.

How Persistence Works

Aurora uses a quorum mechanism (4+3>6) across three Availability Zones (AZs). Each AZ stores two replicas, providing resilience even if an entire AZ fails or a storage node becomes unavailable. The older 2+2>3 quorum is considered unsafe because simultaneous failures can prevent a majority from forming, jeopardizing consistency.

Fast Recovery

Data is divided into 10 GB Protection Groups (PGs), each containing six 10 GB segments spread across the three AZs. By keeping the Mean Time To Failure (MTTF) lower than the Mean Time To Repair (MTTR) for any component, Aurora ensures that even multiple concurrent failures do not violate the quorum requirement. Repairing a single PG typically takes about 10 seconds on a 10 Gbps network.

The Log Is the Database

Each redo log entry carries a monotonically increasing Log Sequence Number (LSN) generated by the database layer. Storage nodes maintain their own redo‑log streams and use a gossip protocol to fill gaps, similar to Multi‑Paxos. The storage service tracks the highest LSN that is guaranteed to be persisted (VCL).

Database nodes truncate logs based on Consistency Point LSNs (CPL). The largest CPL smaller than VCL is the Volume Durable LSN (VDL), analogous to a global commit index. Each segment records a Segment Complete LSN (SCL), functioning like a per‑node commit index.

Transaction commit is considered complete when VDL ≥ the transaction’s commit LSN, at which point a dedicated thread notifies the client. If a transaction fails, recovery is performed per PG: the storage node reads a quorum of replicas, determines the VDL, discards redo logs beyond VDL, and restores the PG’s state.

Aurora’s Characteristics

Derived directly from MySQL 5.6 source, ensuring protocol compatibility.

Compute and storage are decoupled, following modern distributed‑system patterns.

Leverages mature AWS services, similar to Spanner’s use of a stable NoSQL foundation for NewSQL workloads.

Each Protection Group acts as a state machine with its redo log stored in S3, enabling replay‑based recovery.

Redo logs are applied lazily, allowing fast reads and rapid recovery without waiting for log application.

Distributed transactions avoid two‑phase commit, relying on gossip and quorum mechanisms with unique LSNs, resembling Raft‑style consistency.

Conclusion

The article does not delve into the SQL‑layer changes required by this storage‑compute separation, such as handling range queries that now involve multiple storage nodes. For a deeper exploration, see the “Spanner: Becoming a SQL System” paper.