I have setup mongodb for cluster environment. My config server and router is running on one machine, whereas sharding is running on three different machine. I want to know if any command available which I can run on terminal(On which configsvr and router is running) and it will display all routername,configserver(associated with it),Other sharded databases(associated with it).
To simplify it more.
Suppose I run mycommand/piece of code, it display.
router1---> configserver1----> Shardeddb1
----> Shardeddb2
-----> shardeddb3
Modifying to make it more clear.
My router1 and configserver1 are running on single machine(say ip 19.0.0.123), Shardeddb1(say ip 19.0.0.124),Shardeddb2(say ip 19.0.0.125),Shardeddb3(say ip 19.0.0.126).
I want to make Shardeddb1 as a primary and (Shardeddb2,Shardeddb3) as secondary. If I run sh.status(); it show me details but not about which database belong to which machine. So is there any script which can show me more details?
sharding version: {
"_id" : 1,
"version" : 4,
"minCompatibleVersion" : 4,
"currentVersion" : 5,
"clusterId" : ObjectId("545b632e9be3f019d6ef788f")
}
shards:
{ "_id" : "ps1", "host" : "ps1/19.0.0.123:27017","draining" : true }
{ "_id" : "ps2", "host" : "ps2/19.0.0.124:27017" }
{ "_id" : "shard0000", "host" : "19.0.0.125:27017" }
{ "_id" : "shard0001", "host" : "19.0.0.126:27017" }
databases:
{ "_id" : "admin", "partitioned" : false, "primary" : "config" }
{ "_id" : "test", "partitioned" : true, "primary" : "shard0000" }
{ "_id" : "demo", "partitioned" : true, "primary" : "shard0000" }
{ "_id" : "db", "partitioned" : false, "primary" : "ps1" }
{ "_id" : "mongotestDB", "partitioned" : true, "primary" : "ps1" }
mongotestDB.logcoll
shard key: { "id" : 1 }
chunks:
shard0000 4
shard0001 9
ps2 7
ps1 5
too many chunks to print, use verbose if you want to force print
Since your diagram shows otherwise:
mongos
instances have the exact same string for the configdb parameter. And this string has to hold all config servers in the same order. Otherwise, you risk metadata corruption.mongos'
and configservers on the same machine is possible - as long as you keep an eye on the load. If things get rough, and the configservers have delays in updating the metadata because themongos
consume all the IO, you might worsen things. If chunk splits are delayed (and they are more likely under high load), this might cause JumboChunks, which have to be split manually and - until this is done - can't be migrated. Therefor, it is a Very Bad Idea™ to have mongos instances run on the configservers, imvho. A far better solution is to have the mongos instances run on the application servers, one on each.