-
Type:
New Feature
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Replication
-
None
-
Monarch
-
Fully Compatible
-
None
-
None
-
None
-
None
-
None
-
None
-
None
We have a procedure which involves seeding from the contents of a $backupCursor. The procedure involves tailing the oplog like any other initial sync to keep up on changes which are occurring while the copying of data files is in progress.
In our procedure, the oplog is tailed from an arbitrary mongod and may differ from the mongod the $backupCursor is opened on. To ensure our initial sync is valid, the oplog tailing must start reading from a timestamp at or prior to the checkpoint timestamp of the $backupCursor. Moreover, it is more convenient for us that the oplog tailing can proceed even before the $backupCursor is opened.
Our current approach to learn the minimum possible checkpoint timestamp a $backupCursor may be opened at among the replica set members requires contacting each replica set member and running the replSetGetStatus command. However, it is possible one node could not immediately be contacted when oplog tailing attempted to learn its lastStableRecoveryTimestamp. This particular node may still later be chosen as the one to open a $backupCursor on. As a solution to either (a) needing to wait until all cluster members are healthy or (b) coordinating among our oplog tailing and $backupCursor subroutines, we are interested in replSetGetStatus returning a node's stale knowledge of all nodes' lastStableRecoveryTimestamp. The amount of staleness is relatively bounded and will not lead our oplog tailing to unnecessarily copy much unused oplog.