[SERVER-16774] Better enforcement of configdb string consistency Created: 08/Jan/15  Updated: 13/Jul/15  Resolved: 13/Jul/15

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 2.8.0-rc4
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Randolph Tan Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-16733 mongos does not fail when different c... Closed
is related to SERVER-15879 Better error reporting when the mongo... Closed
Sprint: Sharding 8 08/28/15
Participants:

 Description   

This is currently enforced through the setShardVersion command. Some of the issues:

1. There is currently no single authoritative source of truth. The configdb string is passed to the mongod through the setShardVersion command and the first one to succeed wins for that shard. So it is possible for shards within the same cluster to have different configdb string.
2. The reliance on setShardVersion means that mongos will not detect if a different configdb string exists in the server if it never performed any operation on versioned namespaces. Note: majority of the writes in the sharding internals to the config are unversioned.

Mongos also sends the full config string for metadata changing commands performed by shards like moveChunk, splitChunk and mergeChunk. However, these are currently only used for initializing the sharding state in the shard and is never used for checking consistency if already initialized.



 Comments   
Comment by Andy Schwerin [ 13/Jul/15 ]

Config server replica sets have considerably different requirements for config string consistency. Since that's the direction we're moving, we're not going to improve enforcement.

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