[SERVER-5625] New sharded connections to a namespace trigger setShardVersion on all shards Created: 16/Apr/12  Updated: 11/Jul/16  Resolved: 20/Dec/13

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

Type: Bug Priority: Major - P3
Reporter: Greg Studer Assignee: Greg Studer
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File new_conn_shards.js    
Issue Links:
Depends
Duplicate
is duplicated by SERVER-4498 Creating a ShardConnection calls chec... Closed
is duplicated by SERVER-7257 mongos log message seems wrong / refe... Closed
Related
is related to SERVER-6134 stale mongod view of shards causes m/... Closed
is related to SERVER-7246 Mongos cannot do slaveOk queries when... Closed
is related to SERVER-9646 MongoS checkVersion fails if any shar... Closed
Operating System: ALL
Participants:
Linked BF Score: 0

 Description   
Issue Status as of January 8th, 2014

ISSUE SUMMARY
New sharded connections may fail to connect if any shard primary is down.

This issue is part of 4 related issues which impact cluster availability when there is no primary available for a shard. See SERVER-7246, SERVER-5625, SERVER-11971 and SERVER-12041 for more details.

USER IMPACT
When any replica set in a sharded cluster has no available primary, new connections may fail to perform secondary reads due to an initial heuristic shard version check, or initial authorization check.

It is present in versions of MongoDB prior to and including v2.4.8.

SOLUTION
Ignore failures of initial version check during connection and allow authorization against secondaries (primary is preferred when available).

In v2.4.9 only (this is set by default in v2.6.0 and later), it is necessary to use the following two startup parameters for mongos:

--setParameter ignoreInitialVersionFailure=true
--setParameter authOnPrimaryOnly=false

WORKAROUNDS
There is no workaround.

PATCHES
Production release v2.4.9 contains the fix for this issue, and production release v2.6.0 will contain the fix as well.

Original Description

... if a shard is down, we get a socket exception or no master exception. Issue is in _check in s/shardConnection.cpp



 Comments   
Comment by Githook User [ 02/Dec/13 ]

Author:

{u'username': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}

Message: SERVER-5625 SERVER-7426 allow all connections in all states to tolerate downed shards and primaries
Branch: master
https://github.com/mongodb/mongo/commit/024a6739ac52ce669bff42b8782484f27a8cbc34

Comment by Githook User [ 02/Dec/13 ]

Author:

{u'username': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}

Message: SERVER-5625 SERVER-7426 allow all connections in all states to tolerate downed shards and primaries
Branch: v2.4
https://github.com/mongodb/mongo/commit/45662915c2f4e7e19b8333dc93d0d2526d8a34c5

Comment by Githook User [ 20/Nov/13 ]

Author:

{u'username': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}

Message: SERVER-5625 don't throw on problem setting shard version on initial connect
Branch: v2.4
https://github.com/mongodb/mongo/commit/38b3b8f7395d6717efd570a62dc1c2c085d1b049

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