[SERVER-18786] printShardingStatus/sh.status should give info of active mongoses Created: 02/Jun/15  Updated: 03/Apr/19  Resolved: 24/Sep/15

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

Type: Improvement Priority: Major - P3
Reporter: Kevin Pulo Assignee: Kevin Pulo
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
is documented by DOCS-6243 Update sh.status output to include un... Closed
Related
Backwards Compatibility: Fully Compatible
Sprint: Sharding 6 07/17/15, Sharding 7 08/10/15, Sharding 8 08/28/15, Sharding 9 (09/18/15), Sharding A (10/09/15)
Participants:
Linked BF Score: 0

 Description   

In the output of printShardingStatus() / sh.status(), it would be good if there was a "mongos" section (eg. next to "shards"). This would show info about the "active" mongoses (as found by applying some appropriate threshold to the ping time values in config.mongos, eg. 2 mins before the most recent ping).

For example, if verbose is false, then just a basic count and list of the mongos versions found:

 > sh.status()
 --- Sharding Status ---
   sharding version: {
         "_id" : 1,
         "minCompatibleVersion" : 5,
         "currentVersion" : 6,
         "clusterId" : ObjectId("552720847d69a9cc3ebd4313")
 }
   shards:
         {  "_id" : "shard1",  "host" : "shard1/s11:27018,s12:27018" }
         {  "_id" : "shard2",  "host" : "shard2/s21:27018,s22:27018" }
+  active mongoses:
+        "3.0.3" : 4
+        "3.0.2" : 2
   balancer:
         ...
   databases:
         ...

Or, if verbose is true, then one line for each active mongos (sorted by ping):

 > sh.status(true)
 --- Sharding Status ---
   sharding version: {
         "_id" : 1,
         "minCompatibleVersion" : 5,
         "currentVersion" : 6,
         "clusterId" : ObjectId("552720847d69a9cc3ebd4313")
 }
   shards:
         {  "_id" : "shard1",  "host" : "shard1/s11:27018,s12:27018" }
         {  "_id" : "shard2",  "host" : "shard2/s21:27018,s22:27018" }
+  active mongoses:
+        { "_id" : "mongos5:27017", "ping" : ISODate("2015-06-01T07:09:40.274Z"), "up" : 986036, "waiting" : true, "mongoVersion" : "3.0.3" }
+        { "_id" : "mongos2:27017", "ping" : ISODate("2015-06-01T07:09:24.989Z"), "up" : 986256, "waiting" : true, "mongoVersion" : "3.0.3" }
+        { "_id" : "mongos6:27017", "ping" : ISODate("2015-06-01T07:09:20.812Z"), "up" : 986116, "waiting" : true, "mongoVersion" : "3.0.3" }
+        { "_id" : "mongos3:27017", "ping" : ISODate("2015-06-01T07:09:19.483Z"), "up" : 985982, "waiting" : true, "mongoVersion" : "3.0.3" }
+        { "_id" : "mongos2:27017", "ping" : ISODate("2015-06-01T07:09:13.066Z"), "up" : 4445957, "waiting" : true, "mongoVersion" : "3.0.2" }
+        { "_id" : "mongos1:27017", "ping" : ISODate("2015-06-01T07:09:12.989Z"), "up" : 4507109, "waiting" : true, "mongoVersion" : "3.0.2" }
   balancer:
         ...
   databases:
         ...



 Comments   
Comment by Githook User [ 24/Sep/15 ]

Author:

{u'username': u'devkev', u'name': u'Kevin Pulo', u'email': u'kevin.pulo@mongodb.com'}

Message: SERVER-18786: printShardingStatus/sh.status give info of active mongoses
Branch: master
https://github.com/mongodb/mongo/commit/d7a875cd10a49a3174cc4ce90ae290de701323ad

Comment by Githook User [ 20/Sep/15 ]

Author:

{u'username': u'devkev', u'name': u'Kevin Pulo', u'email': u'kevin.pulo@mongodb.com'}

Message: Revert "SERVER-18786: printShardingStatus/sh.status give info of active mongoses"

This reverts commit 0e99282e10daa663c0744a5462348c497ee9cad2.

Conflicts:
jstests/sharding/printShardingStatus.js
Branch: master
https://github.com/mongodb/mongo/commit/6c3e5661ecc19e4a95e6b776bdb7866739a49689

Comment by Kevin Pulo [ 02/Jun/15 ]

Yeah. But the mongos clock skew already has to be under the reasonable maximum imposed by maxClockSkew in distlock (around 30s). So I expect it should be possible to pick an appropriate value for this.

Comment by Randolph Tan [ 02/Jun/15 ]

The caveat for this to work is that the mongos clocks are reasonably synchronized.

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