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

Improve logging when config server does not support CSRS

    • Type: Icon: Improvement Improvement
    • Resolution: Won't Fix
    • Priority: Icon: Minor - P4 Minor - P4
    • None
    • Affects Version/s: None
    • Component/s: Logging, Sharding
    • None
    • Sharding
    • Sharding 2016-11-21, Sharding 2016-12-12, Sharding 2017-01-02, Sharding 2017-02-13, Sharding 2017-03-06

      See comment below for additional details

      Original Description

      If a SCCC, MMAPv1-using config server is restarted with a replicaset name but lacks the configsvrMode: "sccc" it will be a replicaset node, but will not take up primary role because MMAPv1 does not support read concern. So it goes into REMOVED state as the first and only rsstate change.

      Without waiting for a primary to appear in the new CSRS the shard mongod nodes and mongos that connect to that config server switch over the replicaset-using CatalogManager and kill their legacy CatalogManager. There is no valid primary to read from, so they enter SERVER-23192.

      Another way of describing this is: If a person follows the SCCC -> CSRS migration documentation (link) and makes the one mistake at step #3 of failing to:

      [set] the --configsvrMode option to the legacy config server mode Sync Cluster Connection Config (sccc),

      Then they will silently enter SERVER-23192 after 30 secs, and that will stick until the mongod and mongos nodes are restarted. Even if they restart the config server with --configsvrMode="sccc" once.

            Assignee:
            backlog-server-sharding [DO NOT USE] Backlog - Sharding Team
            Reporter:
            akira.kurogane Akira Kurogane
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: