[SERVER-45906] Initial stable checkpoint not triggered properly when enableMajorityReadConcern=false Created: 31/Jan/20  Updated: 29/Oct/23  Resolved: 31/Jan/20

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 4.2.4, 4.3.4

Type: Bug Priority: Major - P3
Reporter: William Schultz (Inactive) Assignee: William Schultz (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v4.2
Steps To Reproduce:

let rst = new ReplSetTest({
    nodes: 1,
    nodeOptions: {
        enableMajorityReadConcern: "false",
        // Prevent frequent checkpoints by background thread.
        syncdelay: 60,
        setParameter: {logComponentVerbosity: tojson({storage: 2})}
    }
});
rst.startSet();
rst.initiate();
 
let primary = rst.getPrimary();
let coll = primary.getDB("test")["test"];
assert.commandWorked(coll.insert({x: 1}));
 
jsTestLog("Kill and restart the node.");
rst.stop(0, 9, {allowedExitCode: MongoRunner.EXIT_SIGKILL}, {forRestart: true});
rst.start(0, undefined, true /* restart */);
 
jsTestLog("Wait for primary.");
let timeout = 20 * 1000;
primary = rst.getPrimary(timeout);
 
rst.stopSet();

Participants:
Linked BF Score: 30

 Description   

When enableMajorityReadConcern is false, we set the stable timestamp to the lastApplied timestamp, instead of requiring that it is behind the majority commit point. This means that on replica set initiation we will set the stable timestamp to the lastApplied optime when we first write down an "initiating set" oplog entry. After this, we then set our initialDataTimestamp to the same lastApplied value. Since we set our stableTimestamp=lastApplied before setting initialDataTimestamp=lastApplied, the condition here for triggering an initial checkpoint will never become true. The condition checks to see if we advanced the stable timestamp from a timestamp less than the IDT to a value greater than the IDT.

Since we never trigger an initial checkpoint, the first checkpoint will be taken after the normal syncdelay frequency, which is 1 minute by default. If we shut down uncleanly after creating initial replication collections like local.system.replset but before our first checkpoint, we may lose this data causing a node to think it is no longer a part of a set it initiated. We should make sure an initial checkpoint is triggered when we first set a stable timestamp with EMRC=false.



 Comments   
Comment by Githook User [ 12/Feb/20 ]

Author:

{'username': 'will62794', 'name': 'William Schultz', 'email': 'william.schultz@mongodb.com'}

Message: SERVER-45906 Ensure initial stable checkpoint is triggered properly when enableMajorityReadConcern=false

(cherry picked from commit d9bd7a1be843ddb38473506ea2aa4802be6d9993)

create mode 100644 jstests/replsets/trigger_initial_stable_checkpoint.js
Branch: v4.2
https://github.com/mongodb/mongo/commit/b0d9915f32c056b674d79e46f5e3a711b9a83b0e

Comment by Githook User [ 31/Jan/20 ]

Author:

{'name': 'William Schultz', 'username': 'will62794', 'email': 'william.schultz@mongodb.com'}

Message: SERVER-45906 Ensure initial stable checkpoint is triggered properly when enableMajorityReadConcern=false
Branch: master
https://github.com/mongodb/mongo/commit/d9bd7a1be843ddb38473506ea2aa4802be6d9993

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