...
For (1), potentially multiple unconfirmed versions have to be maintained (corresponding to multiple checkpoints, to avoid full snapshot on failure, see unconfirmed checkpoints)
Removed keys
Currently, entries are just “unlinked” on removal. Therefore, they wouldn’t be included in the snapshot, but will be present after recovery.
...
- An entry can be removed many times - keep (and write) it only once
- An entry can be re-added (and then re-removed)
- A snapshot with a removal can still be unconfirmed by JM by the time of the next checkpoint (see unconfirmed checkpoints)
- An entry key can be mutable, such as BinaryRowData (this doesn’t cause issues with non-incremental snapshots because removal takes place straight ahead, without tracking)
...
Once a snapshot is sent to the JM, its corresponding checkpoint ID is stored. Upon receiving a confirmation, it becomes a base for the next one.
Unconfirmed checkpoints Anchor unconfirmed-checkpoints unconfirmed-checkpoints
unconfirmed-checkpoints | |
unconfirmed-checkpoints |
If, at the time of a checkpoint N, the previous one N-1 is still unconfirmed:
...