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

Improve UX for the new config servers as replica sets

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.2.0-rc3
    • Component/s: Sharding
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Sprint:
      Sharding C (11/20/15)

      Description

      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: 127.0.0.1:27017/test
      2015-10-16T09:47:27.251+0100 W NETWORK [thread1] Failed to connect to 127.0.0.1:27017, reason: errno:61 Connection refused
      2015-10-16T09:47:27.251+0100 E QUERY [thread1] Error: couldn't connect to server 127.0.0.1:27017, connection attempt failed :
      connect@src/mongo/shell/mongo.js:216:14
      @(connect):1:6

      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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              kaloian.manassiev Kaloian Manassiev
              Reporter:
              john.page John Page
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              14 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: