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
91
92
93
94
95
96
97
98
|
/*! @m_page{{c,java},durability,Commit-level 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 checkpoint for information on checkpoint durability.
Commit-level durability is implemented using a write-ahead log and is
enabled using the \c log=(enabled) configuration to ::wiredtiger_open.
When logging is enabled, WiredTiger writes records to the log for each
transaction.
Transactions define which updates are made durable together; see
@ref transactions for details. By default, log records are buffered in memory
when written by WT_SESSION::commit_transaction. See
@ref durability_group_commit for information about durability options.
When the transactional log is enabled, calling ::wiredtiger_open
automatically performs a recovery step when opening the database that
applies whatever changes from the log are required to bring the database
up to date with the most recent transactional state. This recovery step
may require extensions be available when it runs (for example, collators
and compression). Therefore, applications doing recovery must configure
extensions with the \c extensions keyword to ::wiredtiger_open consistently
whenever re-opening the database.
Recovery is required after the failure of any thread of control in the
application, where the failed thread might have been executing inside
of the WiredTiger library or open WiredTiger handles have been lost. In
most applications, if any thread of control exits unexpectedly, the
application will close and re-open the database.
@section durability_checkpoint Checkpoints
Checkpoints of the database should still be performed periodically when
commit-level durability is configured, either explicitly from the
application or periodically based on elapsed time or data size with the
\c checkpoint configuration to ::wiredtiger_open.
Database checkpoints are necessary for two reasons: First, log files can
only be archived after a checkpoint completes, and so the frequency of
checkpoints determines the disk space required by log files. Second,
checkpoints bound the time required for recovery to complete after
application or system failure by limiting the log records that need to
be processed.
@section durability_backup Backups
With logging enabled, partial backups (backups where not all of the
database objects are copied), may result in error messages during
recovery, because data files referenced in the logs might not be found.
Applications should either copy all objects and log files if
commit-level durability of the copied database is required, or
alternatively, copy only selected objects when backing up and not copy
log files at all, then fall back to checkpoint durability when switching
to the backup.
@section durability_bulk Bulk loads
@copydoc doc_bulk_durability
@section durability_archiving Log file archival
WiredTiger log files are named "WiredTigerLog.[number]" where "[number]"
is a 10-digit value, for example, WiredTigerLog.0000000001". The log
file with the largest number in its name is the most recent log file
written. The log file size can be set using the \c log configuration
to ::wiredtiger_open.
By default, WiredTiger automatically removes log files no longer
required for recovery. Applications wanting to archive log files
instead must disable log file removal using the \c log=(archive=false)
configuration to ::wiredtiger_open.
Log files may be removed or archived after a checkpoint has completed,
as long as there's not a backup in progress. Immediately after the checkpoint
has completed, only the most recent log file is needed for recovery, and all
other log files can be removed or archived. Note that there must always
be at least one log file for the database.
Open log cursors prevents WiredTiger from automatically removing log files.
Therefore, we recommend proactively closing log cursors when done with them.
Applications manually removing log files should take care that no log cursors
are opened in the log when removing files or errors may occur when trying
to read a log record in a file that was removed.
@section durability_tuning Tuning commit-level durability
@subsection durability_group_commit Group commit
@copydoc doc_tune_durability_group_commit
@subsection durability_flush_config Flush call configuration
@copydoc doc_tune_durability_flush_config
*/
|
