[SERVER-15719] sh.status/printShardingStatus should show config servers (ie. configdb) Created: 18/Oct/14  Updated: 06/Dec/22  Resolved: 15/Nov/21

Status: Closed
Project: Core Server
Component/s: Diagnostics, Shell
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor - P4
Reporter: Kevin Pulo Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Sharding
Participants:

 Description   

sh.status() lists useful config db metadata, such as config version, shards, databases, chunks, etc. However, it doesn't say where this data is actually coming from.

In the case where configDB isn't passed to printShardingStatus and defaults to "config", it would be useful to also run db.serverCmdLineOpts() and pull out parsed.sharding.configDB (or parsed.configdb if that doesn't exist (for pre-2.6)), and then if this exists display it alongside the other sharding-related info, eg:

 --- Sharding Status ---
   sharding version: { "_id" : 1, "version" : 3 }
+  configdb:
+    host.local:27020,host.local:27021,host.local:27022
   shards:
     {  "_id" : "shard0000",  "host" : "host.local:27018" }
     {  "_id" : "shard0001",  "host" : "host.local:27019" }
   databases:
     {  "_id" : "admin",  "partitioned" : false,  "primary" : "config" }
     {  "_id" : "test",  "partitioned" : true,  "primary" : "shard0000" }
         test.test
             shard key: { "x" : 1 }
             chunks:
                 shard0000   1
             { "x" : { "$minKey" : 1 } } -->> { "x" : { "$maxKey" : 1 } } on : shard0000 Timestamp(1, 0)



 Comments   
Comment by Kevin Pulo [ 04/Jun/15 ]

A likely better way to do this is to use netstat or getShardVersion to get the actual in-memory configdb string that is in use, since this will also work on configsvrs (where sh.status() already works just fine) (compared to getting the parsed server option, which will only work on mongoses).

There could also be an additional note indicating if sh.status() is being run on a configsvr (since that is a little weird), eg.

 > sh.status()
 --- Sharding Status ---
   sharding version: {
         "_id" : 1,
         "minCompatibleVersion" : 6,
         "currentVersion" : 7,
         "clusterId" : ObjectId("556f97135efa42f9f4eaedd1")
 }
+  config server connection string (connected to configsvr):
+        genique:11113
   shards:
         {  "_id" : "shard01",  "host" : "genique:11112" }
   balancer:
         Currently enabled:  yes
         Currently running:  no
         Failed balancer rounds in last 5 attempts:  0
         Migration Results for the last 24 hours:
                 No recent migrations
   databases:
         {  "_id" : "admin",  "primary" : "config",  "partitioned" : false }
         {  "_id" : "config",  "primary" : "config",  "partitioned" : false }

This could be achieved by using the distinction that the netstat command only works on mongos, and so if that fails but getShardVersion (with a known-good ns eg. config.version) works, then we must be on a configsvr.

mongos> db.adminCommand("netstat")
{ "configserver" : "genique:11113", "isdbgrid" : 1, "ok" : 1 }
mongos> db.adminCommand({"getShardVersion":"config.version"})
{ "ok" : 0, "errmsg" : "ns not sharded." }

configsvr> db.adminCommand("netstat")
{
        "ok" : 0,
        "errmsg" : "no such command: netstat",
        "code" : 59,
        "bad cmd" : {
                "netstat" : 1
        }
}
configsvr> db.adminCommand({"getShardVersion":"config.version"})
{
        "configServer" : "genique:11113",
        "global" : Timestamp(0, 0),
        "inShardedMode" : false,
        "mine" : Timestamp(0, 0),
        "ok" : 1
}

This could be a lot cleaner with better server-side support, but it's hard to say if that'd be worth the effort. eg. allowing getShardVersion to short-circuit and return just configServer if the ns == "" or 1, and then using isdbgrid — or by implementing netstat on mongods, but returning isdbgrid: 0.

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