-
Type: Task
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Labels:None
-
Storage Execution
When opening a backup cursor and copying data files, the size storer will not be consistent with the checkpoint timestamp. From what I understand, updates to the size storer table are untimestamped, meaning the size storer is always up to date with the latest writes. In the context of a backup, this means whatever writes occurred after opening the backup cursor and before copying the size storer file will be included in the backed up data files. This can lead to inaccurate fast counts.
I had also seen a related issue with updating fast counts for a PIT restore, filed under SERVER-87225.
- is related to
-
SERVER-87225 Fast count does not account for newly applied oplog entries in a PIT restore
- Open