blob: 9b939ad4a479674f544ae4908b4aed60a99bf447 (
plain)
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
|
/*! @arch_page arch-backup Backup
# Overview #
Backup in WiredTiger can be performed using the \c "backup:" cursor. WiredTiger
supports four types of backups.
1. Full database
2. Block-based incremental backup
3. Log-based incremental backup
4. Target backup
The following page describes how backup works inside the WiredTiger. Please refer to
@ref backup for details on how to use each of these types of backups.
# Full database #
When the application opens the backup cursor, internally WiredTiger generates a list of all
files in the database that are necessary for the backup. WiredTiger takes both the checkpoint
and schema locks to block database file modifications while generating the list files. There
is a contract that all files that exist at the time the backup starts exist for the entire time
the backup cursor is open. This contract applies to all files in the database, not just files
that are included in the generated list.
WiredTiger log files are also part of the generated file list for backup. There is a contract
that the log files do not contain or make visible operations that are added to the log after
the backup started that could have adverse affects during recovery and restore. Therefore
WiredTiger forces a log file switch when opening the backup cursor. To fulfill the earlier
contract that all files must exist during backup, WiredTiger does not use any pre-allocated
log files nor does it remove log files during the time the backup cursor is open.
Once the backup is opened successfully, any checkpoints that exist on the database before
backup starts must be retained until the backup cursor is closed. All the newer checkpoints
that are created during the backup in progress are cleaned whenever a newer checkpoint is
created.
# Block-based incremental backup #
Block-based incremental backup is performed by tracking the modified blocks in the checkpoint.
Whenever a new checkpoint occurs on a file, any new or modified blocks in this checkpoint are
recorded as a bit string. This bit string information is updated with every new checkpoint.
Whenever the incremental backup cursor is opened to perform the backup, WiredTiger returns all
the file offsets and sizes that are modified from the previous source backup identifier.
WiredTiger returns the full file information to be copied for all the new files that are created,
renamed or imported into the database after the incremental backup cursor is opened. Refer to
@ref backup_incremental-block for more information on how to use the block-based incremental backup.
# Log-based incremental backup #
When the backup cursor is opened with the \c target configuration string as \c "target=(\"log:\\")"
the log-based incremental backup is performed by adding all the existing log files in the database
to the list of files that needs to be copied. Applications wanting to use log files for incremental
backup must first disable automatic log file removal using the \c log=(remove=false) configuration
to ::wiredtiger_open. By default, WiredTiger automatically removes log files no longer required
for recovery. Refer to @ref backup_incremental for more information on how to use the log-based
incremental backup.
# Target backup #
When the backup cursor is opened with the \c target configuration string as \c "target=",
WiredTiger internally generates a list of targeted files instead of all files like the full backup.
If the targeted object is a table, all the indexes and column groups of the table are also backed up.
Note: There can only be one backup cursor open at a time unless using duplicate backup
cursors. The duplicate backup cursors are used for catching up with the log files or with
block-based incremental backup. Please refer to @ref backup_duplicate for more details.
*/
|
