[SERVER-17840] MONGOS 3.0.1 LOG bypassing setShardVersion Created: 01/Apr/15  Updated: 15/May/15  Resolved: 15/May/15

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

Type: Question Priority: Major - P3
Reporter: Dmitry Assignee: Randolph Tan
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:

 Description   

Hello.

What's mean in mongos log

2015-04-01T16:15:52.695+0200 W SHARDING [Balancer] multiVersion cluster detected, my version is 3.0.1
2015-04-01T16:15:52.695+0200 I SHARDING [Balancer] attr0001 is at version 2.6.9
2015-04-01T16:15:52.695+0200 I SHARDING [Balancer] events0001 is at version 2.6.9
2015-04-01T16:15:52.695+0200 I SHARDING [Balancer] events0002 is at version 2.6.9
2015-04-01T16:15:52.695+0200 I SHARDING [Balancer] events0003 is at version 2.6.9
2015-04-01T16:15:52.695+0200 I SHARDING [Balancer] goods0000 is at version 2.6.9
2015-04-01T16:15:52.695+0200 I SHARDING [Balancer] killmail0001 is at version 3.0.1
2015-04-01T16:15:52.695+0200 I SHARDING [Balancer] photo0001 is at version 2.6.9
2015-04-01T16:15:52.695+0200 I SHARDING [Balancer] photo0002 is at version 2.6.9
2015-04-01T16:15:52.695+0200 I SHARDING [Balancer] webscan0001 is at version 3.0.1
 
 
2015-04-01T16:01:23.803+0200 W NETWORK  [conn828122] Primary for photo0001/db0012.xxxxx.com:xxxx,db0013.xxxx.com:xxxx,db0014.xxxx.com:xxxx was down before, bypassing setShardVersion. The
local replica set view and targeting may be stale.iew and targeting may be stale.

for all rs nodes once in 5 minutes ffter upgrading 2.6.8 to 3.0.1 ?

In one rs I see in log connections from another rs, such as:

2015-03-28T22:47:02.033+0100 [conn28] scoped connection to db0012.xxxx.com:xxxx not being returned to the pool
2015-03-28T22:47:03.448+0100 [conn32] scoped connection to db0012.xxxx.com:xxxx not being returned to the pool
2015-03-28T22:47:03.769+0100 [conn53] scoped connection to db0012.xxxx.com:xxxx not being returned to the pool
2015-03-28T22:47:04.094+0100 [conn4461] scoped connection to db0014.xxxx.com:xxxx not being returned to the pool
2015-03-28T22:47:04.212+0100 [conn4461] scoped connection to db0012.xxxx.com:xxxx not being returned to the pool
2015-03-28T22:47:04.792+0100 [conn1489] scoped connection to db0014.xxxx.com:xxxx not being returned to the pool

Looks like not OK.



 Comments   
Comment by Ramon Fernandez Marina [ 15/May/15 ]

esp1974, since the SERVER project is for reporting bugs or feature suggestions for the MongoDB server I'm going to resolve this issue. For MongoDB-related support discussion please post on the mongodb-user group or Stack Overflow with the mongodb tag, where your question will reach a larger audience. A question like your last one involving more discussion would be best posted on the mongodb-user group.

Regards,
Ramón.

Comment by Dmitry [ 01/Apr/15 ]

Hello Randolph.
Thank you for answer.
Is in normal behavior for mongos, if not, how to fix it? Im sure primary was available for mongos whole time. In my opinion setShardVersion never was set at all.

WBW,
Dmitry.

Comment by Randolph Tan [ 01/Apr/15 ]

It means that the primary was temporarily unavailable and mongos decided to skip the shard version handshake (since it can't with no primary) and proceed to talk with the secondary (this is only possible if the query/command has the right read preference). This means that reads can potentially be stale depending on how up to date the secondaries are.

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