[SERVER-20502] Cached chunk version is not updated on mongod when useClusterClientCursor=false Created: 18/Sep/15  Updated: 14/Apr/16  Resolved: 24/Sep/15

Status: Closed
Project: Core Server
Component/s: Querying, Sharding
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor - P4
Reporter: Misha Tyulenev Assignee: Misha Tyulenev
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

run this via resmoke or in mongo shell:

var st = new ShardingTest({ shards: 2, mongos: 4 });
st.stopBalancer();
 
var testDB_s0 = st.s.getDB('test');
testDB_s0.adminCommand({ enableSharding: 'test' });
testDB_s0.adminCommand({ movePrimary: 'test', to: 'shard0001' });
testDB_s0.adminCommand({ shardCollection: 'test.user', key: { x: 1 }});
 
var checkShardMajorVersion = function(conn, expectedVersion) {
    var shardVersionInfo = conn.adminCommand({ getShardVersion: 'test.user' });
    assert.eq(expectedVersion, shardVersionInfo.global.getTime());
};
 
///////////////////////////////////////////////////////
// Test shard with empty chunk
 
// shard0: 0|0|a
// shard1: 1|0|a, [-inf, inf)
// mongos0: 1|0|a
 
var testDB_s1 = st.s1.getDB('test');
assert.writeOK(testDB_s1.user.insert({ x: 1 }));
assert.commandWorked(testDB_s1.adminCommand({ moveChunk: 'test.user',
                                              find: { x: 0 },
                                              to: 'shard0000' }));
 
// Official config:
// shard0: 2|0|a, [-inf, inf)
// shard1: 0|0|a
//
// Shard metadata:
// shard0: 0|0|a
// shard1: 0|0|a
// mongos0: 1|0|a
 
// Set mongos2 to version 2|0|a
var testDB_s2 = st.s2.getDB('test');
assert.neq(null, testDB_s2.user.findOne({ x: 1 }));
 
///////////////////////////////////////////////////////
// Test 2 shards with 1 chunk
// mongos versions: s0: 0|0|0, s2, s3: 2|0|a
 
testDB_s1.user.drop();
testDB_s1.adminCommand({ shardCollection: 'test.user', key: { x: 1 }});
testDB_s1.adminCommand({ split: 'test.user', middle: { x: 0 }});
 
// shard0: 0|0|b,
// shard1: 1|1|b, [-inf, 0), [0, inf)
 
testDB_s1.user.insert({ x: 1 });
testDB_s1.user.insert({ x: -11 });
assert.commandWorked(testDB_s1.adminCommand({ moveChunk: 'test.user',
                                              find: { x: -1 },
                                              to: 'shard0000' }));
 
// Official config:
// shard0: 2|0|b, [-inf, 0)
// shard1: 2|1|b, [0, inf)
//
// Shard metadata:
// shard0: 0|0|b
// shard1: 2|1|b
//
// mongos2: 2|0|a
 
checkShardMajorVersion(st.d0, 0);
checkShardMajorVersion(st.d1, 2);
 
// mongos2 still thinks that { x: 1 } belong to shard0000, but should be able to
// refresh it's metadata correctly.
assert.neq(null, testDB_s2.user.findOne({ x: 1 }));
 
checkShardMajorVersion(st.d0, 2);
st.stop();

the test.user version on st.d0 (shard0) should be 2 but with useClusterClientCursor=false its 0

However, if the code after

 // Set mongos2 to version 2|0|a 

is not executed the test.user version is 0 for both code paths.

Sprint: Sharding A (10/09/15)
Participants:

 Description   

mongos with useClusterClientCursor=true and legacy show different behavior.



 Comments   
Comment by Misha Tyulenev [ 24/Sep/15 ]

The old behavior is expected. No need to fix.

Comment by Randolph Tan [ 23/Sep/15 ]

I don't think this is a bug, this is behavior works as expected for the setShardVersion protocol.

I think what was happening before, is:
1. s2 sends query to d0, gets stale config.
2. s2 refreshes config, sees that query needs to be sent to d1.
3. s2 sends query to d1.

Note that the shard never trusts the versions info from setShardVersion. So, unless the command has authoritative set to true, the shard will never check the config server to cross check. So, it looks like the new implementation behaves as if authoritative is set to true. Also note that in the old case, s2 didn't not need to send a setShardVersion with authoritative true to d0 after step#2 since it doesn't need to talk to it to serve the query.

Comment by David Storch [ 23/Sep/15 ]

Are there any user-facing consequences of this on the 3.0 or 2.6 branch? If not, I propose closing this ticket as Won't Fix (or maybe Gone Away), since the code path containing the bug is going away soon in master.

Generated at Thu Feb 08 03:54:24 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.