-
Type:
Bug
-
Resolution: Duplicate
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Catalog and Routing
-
ALL
-
None
-
None
-
None
-
None
-
None
-
None
-
None
If a document is inserted into a brand new database + collection directly on a replica set after it has been added as a shard, then a find for that document run via the mongos will return that the document does not exist when it does.
You can run this test to reproduce the issue:
const st = new ShardingTest({shards: 0});
const rs = new ReplSetTest({nodes: 3});
rs.startSet();
rs.initiate();
// Restart the replica set with --shardsvr and add the replica set as a shard.
const secondaries = rs.getSecondaries();
secondaries.forEach(secondary => { rs.restart(secondary, {shardsvr: ''}); });
let primary = rs.getPrimary();
rs.restart(primary, {shardsvr: ''});
rs.awaitNodesAgreeOnPrimary();
assert.commandWorked(st.s.adminCommand({addShard: rs.getURL()}));
// Insert a document directly on the shard replica set.
db = rs.getPrimary().getDB("wenqin");
assert.commandWorked(db.coll.insert({x: 1}));
// findOne run on the mongos returns that the document doesn't exist when it does!
assert.commandWorked(st.s.getDB("wenqin").coll.findOne({x: 1}));
rs.stopSet();
st.stop();
Note: this scenario is feasible because as part of the replica set -> sharded cluster procedure, the user is permitted to change connection strings in a rolling fashion. As a result, some users will run operations direct to shard, while some will run them through the mongos.
- duplicates
-
-
- Closed
-