Checkpoints

WiredTiger supports checkpoints, a read-only, static view of one or more data sources.

Checkpoints offer basic operation durability without transactional logging, across application or system failure. (Transactional logging offers fine-grained durability, but requires a recovery step when files are first opened, and impacts the performance of every operation; checkpoints offer durability without recovery or impacting performance, but the creation of a checkpoint is a relatively heavy-weight operation. WiredTiger does not yet support transactional logging.)

A checkpoint is automatically created whenever a modified data source is closed.

When WiredTiger data sources are first opened, they are opened in the state of the most recent checkpoint taken on the file, in other words, updates after the most recent checkpoint will not appear in the data source. If no checkpoint is found when the data source is opened, the data source will appear empty.

Checkpoints are created and discarded using the WT_SESSION::checkpoint method and read using the WT_SESSION::open_cursor method. Additionally, the -c option to the wt command line utility list command will list a data source's checkpoints, with time stamp, in a human-readable format.

Cursors are opened in the most recent version of a data source unless a checkpoint configuration string is provided to WT_SESSION::open_cursor. Cursors opened in the most recent version of a data source support write operations, cursors opened in a checkpoint are read-only.

Checkpoints share file blocks, and dropping a checkpoint may or may not make file blocks available for re-use, depending on whether the dropped checkpoint contained the last reference to a file block.

Checkpoints that do not include LSM trees may optionally be given names by the application. Checkpoints named by the application persist until explicitly dropped or the application creates a new checkpoint with the same name. Creating a new named checkpoint drops any previous checkpoint with the same name; if a previous checkpoint cannot be dropped (either because a cursor is reading from the previous checkpoint, or hot backups are in progress), the checkpoint will fail.

Because checkpoints named by the application are not discarded until explicitly removed or replaced, they may prevent WT_SESSION::compact from accomplishing anything.

Internal checkpoints (that is, checkpoints not named by the application) use the reserved name "WiredTigerCheckpoint". Applications can open the most recent of these checkpoints by specifying "WiredTigerCheckpoint" as the checkpoint name to WT_SESSION::open_cursor. Creating a new internal checkpoint drops all previous internal checkpoints, if possible; if a previous internal checkpoint cannot be dropped for any reason, the checkpoint will ignore the previous checkpoint and continue. Subsequent checkpoints will drop those ignored checkpoints as soon as they can be dropped.