[SERVER-51882] Oplog Fetcher should use ASSERT_MIN_TS_HAS_NOT_FALLEN_OFF_OPLOG to detect falling off oplog Created: 29/Oct/20 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Matthew Russotto | 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 |
|
Currently the OplogFetcher checks to see that it hasn't fallen off the oplog by checking if the minTs it requests is in the response. This is OK for unfiltered oplog fetching but kind of messy for filtered oplog fetching (since we must explicitly include that first timestamp, then exclude it according to the filter). We have a query option, ASSERT_MIN_TS_HAS_NOT_FALLEN_OFF_OPLOG, that can be used, we might want to use that instead, either in filtered mode or always. |