History

Aurora was announced on Nov. 12, 2014 in Amazon's re:Invent conference in Las Vegas. It's officially released and ready to use as a service in AWS on July 27, 2015 by being added into Amazon Relational Database Service. A major patch of Aurora was added in October 24, 2017, where Aurora was extended with PostgreSQL compatibilities.

Checkpoints[03]

As claimed in the Aurora paper, the system doesn't need checkpointing to do fast recovery. The system has the following features to make that possible: + Using a distributed replication of backend storage. This makes it possible to use quorum based read for recovery. + The database engine only propagates logs to the backend storage, where the backend storage keeps processing these logs asynchronously to bring the database to its latest state. These designs make fast logging recovery very easy in Aurora, since the system can easily be brought to a consistent state that is not far from the time of crushing, by utilizing read quorums among all replicated backend storages.

Concurrency Control[04][03]

Aurora decouples the storage engine from its database engine, and the concurrency control protocol is entirely decided by the database engine it used. In the paper that introduced Aurora, the concurrency control model was stated to be exactly the same as the database engine it inherited from. So Aurora has the same concurrency control protocol, MVCC, as MySQL/InnoDB does.

Data Model[05]

Aurora is stated to be a relational database engine. That can also be inferred from its full inheritance of MySQL/InnoDB's database engine and storage layout.

Foreign Keys