[SERVER-45086] Record the last committed optime in the previous config on reconfig Created: 12/Dec/19 Updated: 29/Oct/23 Resolved: 21/Jan/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.3 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Siyuan Zhou | Assignee: | William Schultz (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | safe-reconfig-cmd | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Repl 2020-01-27 | ||||||||
| Participants: | |||||||||
| Description |
|
Record the last committed optime in the previous config. The optime should be updated on reconfig. |
| Comments |
| Comment by Githook User [ 21/Jan/20 ] |
|
Author: {'username': 'will62794', 'name': 'William Schultz', 'email': 'william.schultz@mongodb.com'}Message: |
| Comment by William Schultz (Inactive) [ 15/Jan/20 ] |
|
siyuan.zhou Yes, it does. I just had to think about it for a bit to see how those two values would be combined into one. Thanks for clarifying! |
| Comment by Siyuan Zhou [ 15/Jan/20 ] |
|
william.schultz, exactly! Does the proposal make sense to you? |
| Comment by William Schultz (Inactive) [ 15/Jan/20 ] |
|
siyuan.zhou I just wanted to clarify the meaning of "allowed committed OpTime" in the description. For checking the Oplog Commitment condition we need to make sure that the last optime committed in the previous config (lastCommittedInPrevConfig) is now committed in our current config. If the term of lastCommittedInPrevConfig is not the same as our current term, then we will need to wait on firstOpTimeOfMyTerm to be committed in our current config. If I understand your intention correctly, since the optime we wait on will be max(lastCommittedInPrevConfig, firstOpTimeOfMyTerm), we could combine these two optimes into a single entity, and use that for checking the config oplog commitment condition in addition to checking that we do not commit an op before we have committed something in our own term. Does that align with your thinking? |