[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:
Related
is related to SERVER-45087 Check Oplog Commitment condition on r... Closed
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: SERVER-45086 Record the last committed optime in the previous config on replication reconfig
Branch: master
https://github.com/mongodb/mongo/commit/80195b6a5c1e48dbffa6227002e6c89ec7a10e10

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?

Generated at Thu Feb 08 05:07:50 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.