[SERVER-8380] db.stats reports different replicaset information for shard after rs.remove Created: 29/Jan/13  Updated: 14/Apr/16  Resolved: 12/Jun/15

Status: Closed
Project: Core Server
Component/s: Admin
Affects Version/s: 2.2.2
Fix Version/s: None

Type: Bug Priority: Minor - P4
Reporter: Jeff lee Assignee: Daniel Alabi
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Tested on Mac also reported on linux


Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:

 Description   

After removing a replicaset member from a sharded server setup, db.stats continues to report the old replicaset information for the shard.

Initially reported here: https://groups.google.com/forum/?fromgroups=#!topic/mongodb-user/jRmxV0rujvc

mongos> use test
switched to db test
mongos> db.stats()
{
   "raw" : {
      "s01/localhost:10010,localhost:10020,localhost:10030" : {
         "db" : "test",
         "collections" : 0,
         "objects" : 0,
         "avgObjSize" : 0,
         "dataSize" : 0,
         "storageSize" : 0,
         "numExtents" : 0,
         "indexes" : 0,
         "indexSize" : 0,
         "fileSize" : 0,
         "nsSizeMB" : 0,
         "ok" : 1
      }
   },
   "objects" : 0,
   "avgObjSize" : NaN,
   "dataSize" : 0,
   "storageSize" : 0,
   "numExtents" : 0,
   "indexes" : 0,
   "indexSize" : 0,
   "fileSize" : 0,
   "ok" : 1
}
mongos> sh.status()
--- Sharding Status ---
  sharding version: { "_id" : 1, "version" : 3 }
  shards:
   {  "_id" : "s01",  "host" : "s01/localhost:10010,localhost:10020,localhost:10030" }
   {  "_id" : "s02",  "host" : "s02/localhost:20010,localhost:20020,localhost:20030" }
  databases:
   {  "_id" : "admin",  "partitioned" : false,  "primary" : "config" }
   {  "_id" : "test",  "partitioned" : true,  "primary" : "s01" }
 
mongos>
bye
 
08:22:20 [jlee@Jeffs-MacBook-Air.local] - /Users/jlee
$ mongo localhost:10010/admin --eval "rs.remove('localhost:10030')"
MongoDB shell version: 2.2.2
connecting to: localhost:10010/admin
Tue Jan 29 08:22:55 DBClientCursor::init call() failed
Tue Jan 29 08:22:55 query failed : admin.$cmd { replSetReconfig: { _id: "s01", version: 2, members: [ { _id: 0, host: "localhost:10010" }, { _id: 1, host: "localhost:10020" } ] } } to: localhost:10010
Tue Jan 29 08:22:55 Error: error doing query: failed src/mongo/shell/collection.js:155
 
08:22:55 [jlee@Jeffs-MacBook-Air.local] - /Users/jlee
$ mongo
MongoDB shell version: 2.2.2
connecting to: test
mongos> sh.status()
--- Sharding Status ---
  sharding version: { "_id" : 1, "version" : 3 }
  shards:
   {  "_id" : "s01",  "host" : "s01/localhost:10010,localhost:10020" }
   {  "_id" : "s02",  "host" : "s02/localhost:20010,localhost:20020,localhost:20030" }
  databases:
   {  "_id" : "admin",  "partitioned" : false,  "primary" : "config" }
   {  "_id" : "test",  "partitioned" : true,  "primary" : "s01" }
 
mongos> db.stats()
{
   "raw" : {
      "s01/localhost:10010,localhost:10020,localhost:10030" : {
         "db" : "test",
         "collections" : 0,
         "objects" : 0,
         "avgObjSize" : 0,
         "dataSize" : 0,
         "storageSize" : 0,
         "numExtents" : 0,
         "indexes" : 0,
         "indexSize" : 0,
         "fileSize" : 0,
         "nsSizeMB" : 0,
         "ok" : 1
      }
   },
   "objects" : 0,
   "avgObjSize" : NaN,
   "dataSize" : 0,
   "storageSize" : 0,
   "numExtents" : 0,
   "indexes" : 0,
   "indexSize" : 0,
   "fileSize" : 0,
   "ok" : 1
}



 Comments   
Comment by Daniel Alabi [ 12/Jun/15 ]

Tested 3.0.0 and 3.1.4. After removing a node from a replica set shard, "db.stats()" correctly reports the replica set configuration for the sharded cluster.

Comment by Greg Studer [ 01/Feb/13 ]

The problem has to do with the fact that the chunk manager used to compute the targeted shards for stats uses a copy of the shard object. This may get better with refactoring going on there, one workaround is to use flushRouterConfig (which should update the chunk managers).

There's probably a fix too at the command level which could be implemented in a low-ish impact way, though I'd be wary of race conditions looking up old shards by name.

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