Why should the slave library of one shard count the libraries in another shard

  mongodb, question

Mongo cluster

mongos> sh.status()
 databases:
 {  "_id" : "foo",  "primary" : "shard1",  "partitioned" : false }
 {  "_id" : "bar",  "primary" : "shard0",  "partitioned" : false }

Access to shard1 slave

mongo 127.0.0.1:28010

Execute the following command in mongo shell

shard1:SECONDARY> db.currentOp(    {      "active" : true,      "secs_running" : { "$gt" : 10 }    } )
 
 {
 "desc": "conn1041165",
 "threadId": "139624352057088",
 "connectionId": 1041165,
 "client": "192.168.0.1:54368",
 "active": true,
 "opid": 61729430,
 "secs_running": 42746,
 "microsecs_running": NumberLong("42746814047"),
 "op": "command",
 "ns": "bar",
 "query": {
 "dbstats": 1
 },
 "numYields": 0,
 "locks": {
 "Global": "r"
 },
 "waitingForLock": false,
 "lockStats": {
 "Global": {
 "acquireCount": {
 "r": NumberLong(1)
 }
 }
 }
 }
 ],
 "ok": 1
 }
 ...

It is strange to find that there are many above-mentioned queries about shard1. why do you want to count shard0 libraries? And why is the execution time so long, almost 12 hours

"dbstats":1Is it corresponding to the following command

> db.stats()
 {
 "db" : "test",
 "collections" : 73,
 "objects" : 246794,
 "avgObjSize" : 2915.7151713574885,
 "dataSize" : 719581010,
 "storageSize" : 787140608,
 "numExtents" : 0,
 "indexes" : 85,
 "indexSize" : 11505664,
 "ok" : 1
 }

About{dbstats: 1}Meaning:

  • The query criteria are{dbstats: 1}({"query": {"dbstats": 1}})
  • The library name isbar({ns: 'bar'})
  • What is being carried out iscommandOperations ({op: 'command'})

Therefore, the statement executed is:

db.runCommand({dbstats: 1});

It is actuallydb.stats()The internal operation of the method:

rs0:PRIMARY> db.stats
 function (scale) {
 return this.runCommand({dbstats: 1, scale: scale});
 }
mongos> sh.status()
 databases:
 {  "_id" : "foo",  "primary" : "shard1",  "partitioned" : false }
 {  "_id" : "bar",  "primary" : "shard0",  "partitioned" : false }

This output means that there are now two sets.foo/bar, they are not fragmented ({"partitioned" : false}), because there are no fragments, so what actually carries them is only one fragment. Respectivelyshard1/shard0On{"primary" : "shard1"}/{"primary" : "shard0"}), not the statistics you understand, another library in shard. Moreover, this command is executed from mongos, which is already connected with all the fragments, and there is no so-called “another shard” for statistics.

It is true that the final execution time is too long.db.stats()It shouldn’t take so long. This problem may have something to do with a specific version of the bug, or it may have something to do with your environment, requiring specific analysis of the log. It is suggested to open a ticket in jira.mongodb.org to inquire about the situation.

Related Posts: