[SERVER-69144] Add a command to allow querying local.oplog.rs through mongos for the head of oplog timestamp Created: 25/Aug/22 Updated: 21/Aug/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Huan Li | Assignee: | Backlog - Replication Team |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | former-quick-wins | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Assigned Teams: |
Replication
|
||||
| Participants: | |||||
| Description |
|
There is a need for Mongosync to query the earliest timestamp on the source cluster, from which it can open a change stream. In the sharding cluster case, it would require Mongosync to know max(<ts of oldest oplog entry> for each shard) After a discussion with Max and Bernard here , we found there is currently no good way to do it. We will need a special command to allow mongos to return this value. |
| Comments |
| Comment by Huan Li [ 25/Aug/22 ] |
|
arun.banala@mongodb.com If we have an option to allow change stream to start at the earliest timestamp, I guess the first returned change event should carry this earliest timestamp? We could add option like {pipeline: [{$changeStream: 1}, {$limit: 1}], cursor: {batchSize: 1}} to make the change stream query more performant if it works.
|
| Comment by Huan Li [ 25/Aug/22 ] |
|
arun.banala@mongodb.com We wanna provide a way for the user to be aware of the window that the replication would fail because of the oplog roll over. The error return of ChangeStreamHistoryLost during change stream opening won't be good enough because that will only happen when we have finished all the collection copy. wenbin.zhu@mongodb.com We could notify the user in this way if the falling off happens during collection copy, but that could only fail the replicator earlier instead of preventing it from happening. For instance, during live migration, the TSE used to increase the oplog size when they found the mongomirror has a potential risk to fell off the oplog. |
| Comment by Wenbin Zhu [ 25/Aug/22 ] |
|
arun.banala@mongodb.com Since the current mongosync design only starts change stream after initial sync finishes, we want warn customers as early as possible if mongosync has fallen off the oplog while initial sync is still on-going. huan.li@mongodb.com Instead of querying the oldest oplog, can we just periodically starts a dummy change stream at startAtTs in the background, and see if it returns ChangeStreamHistoryLost error to indicate we have fallen off oplog? |