-
Notifications
You must be signed in to change notification settings - Fork 91
PITR: storage layout
All PITR related chunks are stored in pbmPitr
prefix/subfolder inside the pbm storage.
Each replset stores its chunks inside a separate subfolder. Inside chunks split by month and day prefix.
The chunk names follows pattern <yyyymmddhhiiss>
-<i>
.<yyyymmddhhiiss>
-<i>
.oplog
.<archive_fomat_suffix>
, for example 20200619190615-1.20200619191615-3.oplog.snappy
.
Where start_timestamp_unix and end_timestamp_unix is the cluster time' timestamp of respectively first and the last event captured by the the chunk.
So when sorted by name the layout makes a sequential timeline. Where the first TS of the current chunk is the last TS of the previous one. This means the first ts inside the oplog file will be different to the start time inside. It should be one timestamp counter increment in the same epoch second or, if the activity on the mongod was very quiet, a new epoch second but no more than 20s later because of the noop writer thread.
Q. How we can confirm we have a continuous range? And where does the continuous range of oplog segments extends to? A. The start and end timestamps in the name will 'link' in chain. If this algorithm halts, that is the end of the contiguous chain.
Q. How a delete will truncate the oplog files? (TODO see PBM-456)
For example, for the given config
...
storage:
type: s3
s3:
endpointUrl: http://127.0.0.1:9000
bucket: bkt
prefix: pbm
credentials:
...
the layout gonna be
...
pbm <-- prefix
|
--- pbmPitr <-- PITR subprefix (subfolder)
|
---configRs <-- repset name
|
--- rs0 <-- repset name
|
--- rs1 <-- repset name
|
--- 20200619
|
--- 20200619112430-1.20200619185614-2.oplog.snappy <-- oplog chunk
|
--- 20200619185614-2.20200619190615-15.oplog.snappy
|
--- 20200619190615-3.20200619191615-1.oplog.snappy
|
--- 20200620
. . .