2

I am trying to set up a 3 node MongoDB cluster.

1) Started mongodb in all 3 nodes with the below config file.

 net:
       bindIp: 0.0.0.0
       port: 10901
    setParameter:
       enableLocalhostAuthBypass: false
    systemLog:
       destination: file
       path: "<LOG_PATH>"
       logAppend: true

processManagement:
   fork: true
storage:
   dbPath: "<DB_PATH>/data"
   journal:
      enabled: true
security:
   keyFile : "<KEY_FILE_PATH>"
    sharding:
      clusterRole: "configsvr"
    replication:
      replSetName: "configReplSet"

2) Created Admin user in one of the config node; confirmed I am able to log in with the admin user:

mongo --port 10901 -u "admin" -p "adminpwd" --authenticationDatabase "admin" --host <IP>

now the console says user:PRIMARY>

3) Initiated the replica set using the below command.

rs.initiate(
  {
    _id: "configReplSet",
    configsvr: true,
    members: [
      { _id : 0, host : "<IP1>:10901" },
      { _id : 1, host : "<IP2>:10901" },
      { _id : 2, host : "<IP3>:10901" }
    ]
  }
)

4) Executed rs.status() and got the proper output.

5) Started the mongod shard nodes with the below config in all 3 instances.

net:
   bindIp: 0.0.0.0
   port: 10903
setParameter:
   enableLocalhostAuthBypass: false
systemLog:
   destination: file
   path: "<LOG_PATH>"
   logAppend: true
processManagement:
   fork: true
storage:
   dbPath: "<DB_PATH>/shard_data/"
   journal:
      enabled: true
security:
   keyFile : "<KEY_FILE>"
sharding:
  clusterRole: "shardsvr"
replication:
  replSetName: "shardReplSet"

6) Created Admin user in one of the shard nodes also, and confirmed I am able to login with the admin user:

mongo --port 10903 -u "admin" -p "adminpwd" --authenticationDatabase "admin" --host <IP>

7) Initiated the shard replica set using the below command:

rs.initiate(
  {
    _id: "shardReplSet",
    members: [
      { _id : 0, host : "<IP1>:10903" },
      { _id : 1, host : "<IP2>:10903" },
      { _id : 2, host : "<IP3>:10903" }
    ]
  }
)

8) Started the mongos router with the below config:

# where to write logging data.
systemLog:
  destination: file
  logAppend: true
  path: <LOG_PATH_FOR_MONGOS>

# network interfaces
net:
  port: 10902

security:
  keyFile: <KEY_FILE>

processManagement:
  fork: true

sharding:
  configDB: configReplSet/<IP1>:10901,<IP2>:10901,<IP3>:10901

9) Connected to mongos using the mongo client:

mongo --port 10902 -u "admin" -p "adminpwd" --authenticationDatabase "admin" --host <IP>

Now, I see the below in my terminal.

MongoDB server version: 3.4.2
mongos>

10) Added the shard in the mongos interface:

sh.addShard("shardReplSet/<IP1>:10903, <IP2>:10903, <IP3>:10903")

Issues :-

1) I am unable to connect to mongos from a remote machine

I am able to connect to mongos on each of the three nodes:

From Node1:

mongo --port 10902 -u "user" -p "password" --authenticationDatabase "admin" --host <Node1>

mongo --port 10902 -u "user" -p "password" --authenticationDatabase "admin" --host <Node2>

mongo --port 10902 -u "user" -p "password" --authenticationDatabase "admin" --host <Node3>

All the above 3 connections are working from Node1, from Node2, and from Node3.

But if I try from my localhost to connect to these instances, I get timeout errors; even though I am able to ssh to these servers.

2) I am running the config nodes on port 10901, shard nodes on port 10903, and the mongos router on port 10902. Each host is running a config mongod node, a shard mongod node and a mongos router. Is this OK?

3) On each host, the DB path for the config node and the shard node are different. I have to create the admin user on each service (config, shard, router). Is this correct?

4) I have created a replica set for config and a replica set for the shard, but not for the mongos router - is this OK?

5) I am unable to connect to these instances from a remote MongoChef tool. This connection was on the router port - is this correct? If so, do I need to run the mongos router on each node?

6) Do we need to connect to the port 10903 or 10902 or 10901 to create new databases, and to create new users for databases?

7) Is there anything else important to be added here?

-1
  1. Are you saying that when you have logged in at Node1, you can connect that mongos service with --host node1 but not --host localhost? If so, check your /etc/hosts for address localhost

    But if you mean that you are at your application node and try to connect to localhost.. Of course it will not work.

  2. Yes, it's OK.
  3. Yes, admin users at config server replica set primary and shard replica sets primary is created for situation when you need to make changes directly on those replica sets.
  4. Yes, that's correct. You cannot create replica set at mongos.
  5. First, you don't need mongos process at every node. One mongos is enough. You could put that mongos to your application node too. BUT.. If you have connection problems outside of your nodes, check firewalls. I mean, even you can SSH to your nodes (what are in the cloud?!) it don't mean that those ports 1090x are open from outside world. If your nodes are in the cloud, firewall is not (only) in those nodes, your provider have own firewalls too.
  6. You MUST connect to your mongos (10902) instance when you are creating new databases, users or adding new replica sets (shards) to cluster.
  7. Take care that every mongod node can connect to every config-server and vice versa. Every mongos must be able to connect every replica set node at your cluster and of course to every config-server replica set node. How ever, none of mongod processes (shard or config) don't need to connect your mongos...

    Check your log files (mongos, config-server, shard) for errors..

    grep -iP 'error|fail' /var/log/mongodb/*.log

  • Hi, I hope, all clinets or applications will be connected thru the MongoS port. If we run only one mongoS, what will happen when it goes down. – user1578872 Apr 4 '17 at 19:30
  • Of course, if "only" mongoS is down, nobody has connection to DB. But normally mongoS don't go down itself. You could have f.ex. two mongoS and half of applications connect to first one, rest to the other one. It's not a problem if you have multiple mongoS, but you can operate, even you have only one. – JJussi Apr 4 '17 at 19:38
  • I had to vote this down because of 2., as it is totally not ok for various and rather severe reasons. First and foremost, if heavy load is put on the cluster, the mongos, the configserver and the mongos will compete for RAM and IO - hardly a desired state. A mongos should either be a standalone or be placed at the client applications server. And while a config server only needs limited resources, you do not want your work horse to compete for RAM with it while under load. Second, and even more severe: the upgrade process: you are required to upgrade all config servers first, then upgrade all – Markus W Mahlberg Jul 25 '18 at 8:31
  • data bearing nodes and then all mongos. Hard to do that with only one installation of MongoDB per node. Third, disaster recovery. Say two nodes fail. Not only does the actual data need to be restored, but also the config data. Additional stress in an already stressful situation. And more downtime, Presumably. @user1578872 For the reasons above, I'd rather suggest 3 physical data bearing nodes, 3 cheapo VMs for the config servers and to put the mongos either 3 small physical nodes or your application servers, depending on your load. – Markus W Mahlberg Jul 25 '18 at 8:39

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.