Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-20962

Improve UX for the new config servers as replica sets



    • Improvement
    • Status: Closed
    • Major - P3
    • Resolution: Done
    • None
    • 3.2.0-rc3
    • Sharding
    • None
    • Fully Compatible
    • Sharding C (11/20/15)


      Attempting to set up a simple sharded cluster with MongoDB 3.1.9 for training and learning purposes is now far harder and more confusing than it was and appears to fail at first in may ways . This provides a very bad first impression of MongoDB. Here are some points as to why.

      3.1.9 requires a single node replica set - this itself causes issues as it's a breaking change and there are hundreds of getting started with MongoDB tutiorials that no longer work.

      If you do make this mistake then add --replSet config to your config server you get an uninitialised Replica set which you can't use - but it's not obvious why. Even logging on you get a blank prompt not a config[NOT YET REPLICA] or something similar.

      IF you try to start mongos with

      mongos --configdb localhost:27019 --port 27017

      You get

      BadValue Must have either 3 node legacy config servers, or a replica set config server
      try 'mongos --help' for more information

      but mongos --help gives you Zero help as it says

      Sharding options:
      --configdb arg 1 or 3 comma separated config servers

      There are no clues that you need

      mongos --configdb config/localhost:27109

      NOR does it infer 27019 as it did before or infer a default replica set name

      Worst part - and this is a BUG I think

      For approximately a minute after you get the mongos up, attempts to contact get

      MacPro:~ jlp$ mongo --port 27017
      MongoDB shell version: 3.1.9
      connecting to:
      2015-10-16T09:47:27.251+0100 W NETWORK [thread1] Failed to connect to, reason: errno:61 Connection refused
      2015-10-16T09:47:27.251+0100 E QUERY [thread1] Error: couldn't connect to server, connection attempt failed :

      exception: connect failed
      MacPro:~ jlp$

      in which time people stop it and try again as it appears to have failed

      If you wait approximately three minutes then you get the following in the mongos log

      2015-10-16T09:49:07.855+0100 W SHARDING [thread1] pinging failed for distributed lock pinger :: caused by :: findAndModify query predicate didn't match any lock document
      2015-10-16T09:49:08.273+0100 I SHARDING [Balancer] about to contact config servers and shards
      2015-10-16T09:49:08.273+0100 I NETWORK [mongosMain] waiting for connections on port 27017
      2015-10-16T09:49:08.274+0100 I SHARDING [Balancer] config servers and shards contacted successfully
      2015-10-16T09:49:08.274+0100 I SHARDING [Balancer] balancer id: MacPro.local:27017 started
      2015-10-16T09:49:08.308+0100 I SHARDING [Balancer] distributed lock 'balancer' acquired, ts : 5620ba04600c6c11c7053c0b
      2015-10-16T09:49:08.394+0100 I SHARDING [Balancer] distributed lock with ts: 5620ba04600c6c11c7053c0b' unlocked.

      and you can then connect.

      Just the kind of UX that would turn me and many others away from MongoDB in that golden 30 minutes when I first try it.


        Issue Links



              kaloian.manassiev@mongodb.com Kaloian Manassiev
              john.page@mongodb.com John Page
              0 Vote for this issue
              14 Start watching this issue