1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
|
/*! @page checkpoints 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 -c option to the \c wt command line utility \c 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 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.
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.
*/
|
