[SERVER-27054] Slave can acknowledge write before initial sync is complete Created: 15/Nov/16  Updated: 06/Dec/22  Resolved: 21/Nov/16

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

Type: Bug Priority: Major - P3
Reporter: Tess Avitabile (Inactive) Assignee: Backlog - Replication Team
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-25618 Slave in master/slave deployment can ... Closed
related to SERVER-27033 Optype "db" not handled correctly by ... Closed
related to SERVER-27055 initial_sync_id_index.js should not u... Closed
Assigned Teams:
Replication
Operating System: ALL
Steps To Reproduce:

var rt = new ReplTest();
var master = rt.start(true);
 
var slave = rt.start(false);
 
for (var i = 1; i <= 20; i++) {
    master.getDB("test").createCollection("coll" + i);
}
 
assert.writeOK(master.getDB("test").coll0.insert({}, {writeConcern: {w: 2}}));
 
for (var i = 0; i <= 20; i++) {
    var res = slave.getDB("test").runCommand({listCollections: 1, filter: {name: "coll" + i}});
    // This fails for some collections.
    assert.eq(res.cursor.firstBatch.length, 1, "collection coll" + i + " not found");
}
 
rt.stop();

Participants:

 Description   

This behavior means that we cannot use {w:2} writes to tell whether a slave has completed initial sync.



 Comments   
Comment by Eric Milkie [ 16/Nov/16 ]

After some investigation, it looks like this may be working as "designed". Since slaves do not have the concept of "minvalid", they do not have an "oplog catch up" phase of initial sync; instead, they fully clone new databases "in the moment" while processing the oplog stream. In the repro test case above, the appearance of the "test" database after the slave's initial sync started was triggering a bug in processing 'db' ops (SERVER-27033), which was breaking the "clone database immediately" logic.

Generated at Thu Feb 08 04:14:02 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.