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
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
|
/*! @m_page{{c,java},checkpoint,Checkpoint durability}
WiredTiger supports checkpoint durability by default, and optionally
commit-level durability when logging is enabled. In most applications,
commit-level durability impacts performance more than checkpoint
durability; checkpoints offer basic operation durability across
application or system failure without impacting performance (although
the creation of each checkpoint is a relatively heavy-weight operation).
See @ref durability for information on commit-level durability.
Checkpoints with transactional logging enabled allow logging to archive
older log files (if configured to do so) while still retaining
commit-level durability and the ability to run recovery.
A checkpoint is automatically created whenever a modified data source
is closed. Additionally, checkpoints of one or more data sources, or
the entire database, can be explicitly created using the
WT_SESSION::checkpoint method. Checkpoints can also be scheduled
periodically based on elapsed time or data size with the \c checkpoint
configuration to ::wiredtiger_open.
All transactional updates committed before a checkpoint are made durable
by the checkpoint, therefore the frequency of checkpoints limits the
volume of data that may be lost due to application or system failure.
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.
@section checkpoint_server Automatic checkpoints
WiredTiger will automatically checkpoint the entire database when the
\c checkpoint configuration parameter to ::wiredtiger_open is set. When
this configuration is used, an internal server thread is created.
The period between checkpoints can be defined either in seconds via \c
wait, or, if logging is enabled, as the number of bytes written to the log
since the last checkpoint via \c log_size, or both. If both periods are
defined then the checkpoint occurs as soon as either threshold has occurred
and both are reset once the checkpoint is complete. If using \c log_size,
we recommend that the size selected be a multiple of the log file size for
archiving purposes.
@section checkpoint_cursors Checkpoint cursors
Cursors are normally opened in the most recent version of a data source.
However, a checkpoint configuration string may be provided to
WT_SESSION::open_cursor, opening a read-only, static view of the data
source. This provides a limited form of time-travel, as the static view
is not changed by subsequent checkpoints, and will persist until the
checkpoint cursor is closed.
@section checkpoint_naming Checkpoint naming
Additionally, checkpoints that do not include LSM trees may optionally
be given names by the application. Checkpoints named by the application
persist until explicitly discarded or the application creates a new
checkpoint with the same name (which replaces the previous checkpoint
of that name). If the previous checkpoint cannot be replaced, either
because a cursor is reading from the previous checkpoint, or backups are
in progress, the checkpoint will fail. Because named checkpoints
persist until discarded or replaced, they can be used to periodically
snapshot data for later use.
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 when it
becomes possible.
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.
@section checkpoint_compaction Checkpoints and file compaction
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.
Because checkpoints named by the application are not discarded until
explicitly discarded or replaced, they may prevent WT_SESSION::compact
from accomplishing anything due to shared file blocks.
*/
|
