[SERVER-27967] Choose whether to do oplog catch up based on local last fetched optime rather than last applied optime Created: 09/Feb/17 Updated: 13/Feb/17 Resolved: 13/Feb/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Judah Schvimer | Assignee: | Judah Schvimer |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: |
| Description |
|
When a node decides if it's up to date, it compares the highest last applied optime of other nodes to it's own last applied optime: https://github.com/mongodb/mongo/blob/r3.4.2/src/mongo/db/repl/replication_coordinator_impl.cpp#L2781-L2788 We could go into drain mode faster and skip catch up more often if nodes compared the highest last applied optime of other nodes to their own last fetched optime instead. |
| Comments |
| Comment by Judah Schvimer [ 13/Feb/17 ] |
|
While this would be more true to what we actually need to do for catchup, there's no negative to going into catchup when we do not need to. We will simply spend less time in drain mode and more time in catchup mode, but those will balance out. We also do not have the last fetched OpTime available so this would not be a simple fix. Closing as "Won't Fix". |