Retro: Modular and efficient retrospection in a database Ross Shaull Liuba Shrira Brandeis University

Analyzing Past States Answering questions about past states of data is important – trend detection – anomaly detection – intrusion analysis – error recovery Some commercial databases have support for snapshots, but this support is not widely available, especially in light-weight data stores Rolling your own solution is difficult and hard to optimize

Retro The idea to save database snapshots has been around for a long time Good performance has required extensive modifications to database internals or new database designs Our goal is to make it possible to add snapshots to any data store without sacrificing performance

Retro We resolve the tension between performance and implementation complexity with a design that emphasizes portability by relying on standard database layers and protocols Retro is a source-level database augmentation suitable for integration with a variety of data stores

Retro WAL recovery MVCC Page cache Transactionally consistent, low-cost snapshots

Snapshot representation Page level Metadata and snapshot pages organized on separate disk (split snapshots) Previous work looked in depth at how to organize snapshot data and metadata Database diskRetro disk

Programmer's model Retro extends the database interface with two primitives Programmer can declare snapshot at any time Any read-only code can be executed as of Agnostic to query language or API select * from table where pk = key get(table, key); Current state queries are unchanged by Retro As of queries are delimited with a snapshot identifier as of snapshot S begin_as_of(S); end_as_of();

Retro: portable performance Wrapper to extend database software stack Extend database protocols to create snapshot protocols – Save consistent snapshots – As of queries without blocking current-state – Make snapshots recoverable Formal model of snapshot system – To argue correctness of extensions

Software structure Snapshot Layer Application Database Interface Access methods / indexes Page cacheWAL snap nowas of Database diskRetro disk MVCC

Snapshots Incrementally save snapshot pages – "copy-on-update" When a snapshot is declared, it shares its pages with the current state As updates commit, snapshot pages are saved and later written to the Retro disk

OWS(History) Snapshot Overwrite Sequence History Snapshot S1 Update P Snapshot S2 Update P Update Q Not the first update to P since S1 was declared Database diskRetro disk P P P P Q Q P P R R Q Q S1 S2

Retrospection (querying as of) Extend space of logical page names – to include snapshot pages – leverage page cache for snapshot pages But: avoid changing logical page names – so that access methods and indexes function correctly with retrospection Solution: "virtualize" logical page names to refer to either current-state or snapshot pages

Retrospection (querying as of) Snapshot Layer Access methods / indexes Page cache Page name translation Database diskRetro disk Interface as of Look up (DBFile, Get (DBFile, P) Get (RetroFile,

Current state queries Snapshot Layer Access methods / indexes Page cache Page name translation Database diskRetro disk Interface Get (DBFile, P)

Non-blocking retrospection Recent snapshots share pages with the current state MVCC supports concurrent queries and updates Retro leverages MVCC for retrospection Retro introduces new internal contention on internal metadata structures – We solve this with a novel mechanism that caches key metadata in page headers in the cache

Recoverable snapshots Avoid creating entirely new recovery protocol – Leverage work database already does using WAL Suffix of OWS gets recreated during normal replay of REDO records Retro runs during recovery like during normal operation, capturing pre-states as REDO records are applied in the page cache

Recoverable snapshots WALPage cache Snapshot S1 T1: P.r = 2 DB DiskRetro Disk T1: commit P P r=1 P P P P r=2

Ensuring recoverability The database flushes pages to disk periodically Pre-states of a page that gets flushed will not necessarily be recreated by recovery Retro enforces write-ordering invariants to ensure that snapshot pages are made durable before the database takes an action that will make them non-recoverable

Current status Formal model for protocol extensions Performance model that characterizes retrospection in terms of unmodified database performance Provably correct Retro extensions Prototyped in Berkeley DB

Current status Only ~250 LOC were added or modified in the BDB source files (rest of Retro implemented outside BDB) Imposes small (2%) overhead on updates Retrospection takes a performance penalty (up to 3x when snapshot pages are cached) Our current prototype can take advantage of available parallelism in Berkeley DB

Thanks NED Summit Sponsors And organizers! Questions?