2

I'm trying to create an replicated sharded cluster in mongodb. Initially I've created two shards and there are a replica set with three members in each shard. And all the shards and replicasets run in a single machine. I followed

http://docs.mongodb.org/manual/tutorial/convert-replica-set-to-replicated-shard-cluster/

to deploy this structure and that worked perfectly.

But as I'm running my mongodb in an AWS instance for a business application and I'm connecting my node.js server with the database, I want to load balance the database within multiple aws instance so that the database works fine even in huge traffic load and even if one instance becomes unhealthy or unavailable, I'll be able to access the database from the replicaset running in other instances.

Depending on the suggestions of different users in my previous question

http://stackoverflow.com/questions/24671205/mongodb-load-balancing-in-multiple-aws-instances

I'm trying to divide the database in shards and each shard will have a replicaSet with 3 or more members running in separate aws instances. To create this structure, I tried to deploy it locally at first.

I've two replicasets firstset & secondset

The firstset has three members 192.168.1.10:27018(Primary), 192.168.1.11.27018(Secondary) & 192.168.1.9:27018(arbiter)

And the secondset has three members 192.168.1.6:27019(Primary), 192.168.1.9:27019(Secondary) & 192.169.1.11:27019(arbiter)

To create the firstset replica I've written

mongod --dbpath /replica-data --port 27018 --replSet firstset --oplogSize 10

in 192.168.1.10, 192.168.1.11 & 192.168.1.9

Then to initiate the replica set I've written

mongo --port 27018

in 192.168.1.10 and then,

use admin

db.runCommand({
 "replSetInitiate": {
    "_id": "firstset",
    "members": [{
         "_id": 1,
         "host": "192.168.1.10:27018",
         "priority": 10
         }, {
         "_id": 2,
         "host": "192.168.1.11:27018",
         "priority": 2
         }, {
         "_id": 3,
         "host": "192.168.1.9:27018",
         "priority": 1,
         "arbiterOnly": true
         }]
         }
    });

I've created the secondset replica is similar way and it worked.

Then I tried to create three configsvrs in three separate machine so that even if one machine shuts down the other configsvrs will be running. The configsvs will run in 192.168.1.10:27020, 192.168.1.11:27020 & 192.168.1.6:27020

So I've written

mongod --configsvr --dbpath /shard-data -port 27020

in 192.168.1.10, 192.168.1.11 & 192.168.1.6.

Then I tried to run the mongos in 192.168.1.10 in 27030 port with the three running configdb. So, I've written

mongos --configdb 192.168.1.10:27020,192.168.1.11:27020,192.168.1.6:27020 --port 27030 --chunkSize 1

Then I got in mongos log:

2014-07-11T13:52:34.502+0530 [mongosMain] MongoS version 2.6.3 starting:     pid=4195 port=27030 64-bit host=innofied-lappy (--help for usage)
2014-07-11T13:52:34.502+0530 [mongosMain] db version v2.6.3
2014-07-11T13:52:34.502+0530 [mongosMain] git version: 255f67a66f9603c59380b2a389e386910bbb52cb
2014-07-11T13:52:34.502+0530 [mongosMain] build info: Linux build12.nj1.10gen.cc 2.6.32-431.3.1.el6.x86_64 #1 SMP Fri Jan 3 21:39:27 UTC 2014 x86_64 BOOST_LIB_VERSION=1_49
2014-07-11T13:52:34.502+0530 [mongosMain] allocator: tcmalloc
2014-07-11T13:52:34.502+0530 [mongosMain] options: { net: { port: 27030 }, sharding: { chunkSize: 1, configDB: "192.168.1.10:27020,192.168.1.7:27020,192.168.1.8:27020" } }
2014-07-11T13:52:34.518+0530 [mongosMain] SyncClusterConnection connecting to [192.168.1.10:27020]
2014-07-11T13:52:34.524+0530 [mongosMain] SyncClusterConnection connecting to [192.168.1.7:27020]
2014-07-11T13:52:34.527+0530 [mongosMain] SyncClusterConnection connecting to [192.168.1.8:27020]
2014-07-11T13:52:34.618+0530 [mongosMain] scoped connection to 192.168.1.10:27020,192.168.1.7:27020,192.168.1.8:27020 not being returned to the pool
2014-07-11T13:52:45.956+0530 [mongosMain] waited 11s for distributed lock configUpgrade for upgrading config database to new format v5
2014-07-11T13:52:57.613+0530 [mongosMain] waited 22s for distributed lock configUpgrade for upgrading config database to new format v5

And also could not found any mongos process at the specific port. So, when I run

mongo --port 27030

it's showing me

errno:111 conncetion refused.

But previously it working perfectly when I was testing it in a single machine.

Please help me why I'm getting this error and how to solve it.

  • Your log says that the mongos is running on port 27030, not 27017 - are you connecting to the right port? – Adam C Jul 14 '14 at 11:11
  • Sorry for my mistake. I have connected on port 27030. At first I test on 27017. So, copy it from there and forgot to edit. I faced the same problem in both cases. – Kaushick Gope Jul 14 '14 at 12:27
  • This is very likely an issue with security groups, something not allowing the connection on that port like bindIP, or similar then, since you are getting connection refused. I could try to replicate, but I'd need to know what AMI you are using (and any changes you might have made to the security group) to be sure. As an immediate test, try specifying the full host:port to make sure you use the loopback interface: mongo --host 127.0.0.1:27030 – Adam C Jul 14 '14 at 16:31
  • I did not made any changes in security groups. mongo --host 127.0.0.1:27030 will not work as no process is running on 27030 port(I have checked the running process list in sudo netstat -nltp). – Kaushick Gope Jul 15 '14 at 6:26
  • The point was to try the full host:port version to connect rather than having the OS resolve localhost - just run it on whatever port you are actually running a mongos/mongod process on instead. You also have not mentioned the AMI you are using, what version of MongoDB you are using yet - if you could (and mention how you got the MongoDB binaries too - straight download, package install?) that would be great – Adam C Jul 15 '14 at 9:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.