Commit 94bef65
committed
backup: re-enable fast incremental BACKUP via TBI
Within the current BACKUP/RESTORE feature offering, the way to reduce
RPO is to backup more often. For this to work for more frequent
durations, the cost of backing up what changed must scale with the size
what changed, as opposed to the total data size. This is exactly what
the time-bound iterator optimization is supposed to deliver -- by
recording the span of timestamps that appear in any given SSTable and
then installing a filter to only open sstables that contain relevant
times, we can ignore irrelevant data very cheaply.
However over 2017 and 2018, we encountered a few tricky correctness
issues in the interaction of the time-bound iterator and our MVCC logic
and handling intents, and generally lost confidence in this code,
ultimately disabling its use in the scans used by BACKUP. However #45785
resolved those concerns by ensuring that every key emitted by the
IncrementalIterator was actually read by a normal, non-TBI iterator even
when TBI is used. Thus it is now believed to be safe to re-enable TBI
for incremental backups.
Release note (enterprise change): Incremental BACKUP can quickly skip of unchanged data making frequent incremental BACKUPs 10-100x faster depending on data-size and frequency.
Release justification: low-risk and high-impact.1 parent 7e288ca commit 94bef65
1 file changed
Lines changed: 1 addition & 1 deletion
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
67 | 67 | | |
68 | 68 | | |
69 | 69 | | |
70 | | - | |
| 70 | + | |
71 | 71 | | |
72 | 72 | | |
73 | 73 | | |
| |||
0 commit comments