OPTIONS

Upgrade Config Servers to Replica Set

On this page

New in version 3.2: Starting in 3.2, config servers for a sharded cluster can be deployed as a replica set.

The following procedure upgrades three mirrored config servers to a config server replica set. Using a replica set for the config servers improves consistency across the config servers, since MongoDB can take advantage of the standard replica set read and write protocols for the config data. In addition, this allows a sharded cluster to have more than 3 config servers since a replica set can have up to 50 members.

Prerequisites

  • All binaries in the sharded clusters must be at least version 3.2. See Upgrade a Sharded Cluster to 3.2 for instructions to upgrade the sharded cluster.
  • The existing config servers must be in sync.

Procedure

Important

The procedure outlined in this tutorial requires downtime.

  1. Disable the balancer as described in Disable the Balancer.

  2. Connect a mongo shell to the first config server listed in the configDB setting of the mongos and run rs.initiate() to initiate the single member replica set.

    rs.initiate( {
       _id: "csReplSet",
       version: 1,
       configsvr: true,
       members: [ { _id: 0, host: "<host>:<port>" } ]
    } )
    
    • _id corresponds to the replica set name for the config servers.
    • version set to 1, corresponding to the initial version of the replica set configuration.
    • configsvr must be set be true.
    • members array contains a document that specifies:
      • members._id which is a numeric identifier for the member.
      • members.host which is a string corresponding to the config server’s hostname and port.
  3. Restart this config server as a single member replica set with:

    • the --replSet option set to the replica set name specified during the rs.initiate(),
    • the --configsvrMode option set to the legacy config server mode Sync Cluster Connection Config (sccc),
    • the --configsvr option, and
    • the --storageEngine option set to the storage engine used by this config server. For this upgrade procedure, the existing config server can be using either MMAPv1 or WiredTiger.

    Include additional options as specific to your deployment.

    mongod --configsvr --replSet csReplSet --configsvrMode=sccc --storageEngine <storageEngine> --port <port> --dbpath <path>
    

    Or if using a configuration file, specify the replication.replSetName:, sharding.clusterRole, sharding.configsvrMode and net.port.

    sharding:
       clusterRole: configsvr
       configsvrMode: sccc
    replication:
       replSetName: csReplSet
    net:
       port: <port>
    storage:
       dbpath: <path>
       engine: <storageEngine>
    
  4. Start the new mongod instances to add to the replica set. These instances must use the WiredTiger storage engine. Starting in 3.2, the default storage engine is WiredTiger for new mongod instances with new data paths.

    Important

    • Do not add existing config servers to the replica set.
    • Use new dbpaths for the new instances.

    The number of new mongod instances to add depends on the config server currently in the single-member replica set:

    • If the config server is using MMAPv1, start 3 new mongod instances.
    • If the config server is using WiredTiger, start 2 new mongod instances.

    Note

    The example in this procedure assumes that the existing config servers use MMAPv1.

    For each new mongod instance to add, include the --configsvr and the --replSet options:

    mongod --configsvr --replSet csReplSet --port <port> --dbpath <path>
    

    Or if using a configuration file:

    sharding:
       clusterRole: configsvr
    replication:
       replSetName: csReplSet
    net:
       port: <port>
    storage:
       dbpath: <path>
    
  5. Using the mongo shell connected the replica set config server, add the new mongod instances as non-voting, priority 0 members:

    rs.add( { host: <host:port>, priority: 0, votes: 0 } )
    
  6. Once all the new members have been added as non-voting, priority 0 members, ensure that the new nodes have completed the initial sync and have reached SECONDARY state. To check the state of the replica set members, run rs.status() in the mongo shell:

    rs.status()
    
  7. Shut down one of the other non-replica set config servers; i.e. either the second and third config server listed in the configDB setting of the mongos.

  8. Reconfigure the replica set to allow all members to vote and have default priority of 1.

    var cfg = rs.conf();
    
    cfg.members[0].priority = 1;
    cfg.members[1].priority = 1;
    cfg.members[2].priority = 1;
    cfg.members[3].priority = 1;
    cfg.members[0].votes = 1;
    cfg.members[1].votes = 1;
    cfg.members[2].votes = 1;
    cfg.members[3].votes = 1;
    
    rs.reconfig(cfg);
    
  9. Step down the first config server, i.e. the server started with --configsvrMode=sccc.

    rs.stepDown()
    
  10. Shut down the following members of the sharded cluster:

    • The mongos instances.
    • The shards.
    • The remaining non-replica set config servers.
  11. Shut down the first config server.

    If the first config server uses the MMAPv1 storage engine, remove the member from the replica set. Connect a mongo shell to the current primary and use rs.remove():

    Important

    If the first config server uses the WiredTiger storage engine, do not remove.

    rs.remove("<hostname>:<port>")
    
  12. If the first config server uses WiredTiger, restart the first config server in config server replica set (CSRS) mode; i.e. restart without the --configsvrMode=sccc option:

    Important

    If the first config server uses the MMAPv1 storage engine, do not restart.

    mongod --configsvr --replSet csReplSet --storageEngine wiredTiger --port <port> --dbpath <path>
    

    Or if using a configuration file, omit the sharding.configsvrMode setting:

    sharding:
       clusterRole: configsvr
    replication:
       replSetName: csReplSet
    net:
       port: <port>
    storage:
       dbpath: <path>
       engine: <storageEngine>
    
  13. Restart the shards.

  14. Restart mongos instances with updated --configdb or configDB setting.

    For the updated --configdb or configDB setting, specify the replica set name for the config servers and the members in the replica set.

    mongos --configdb csReplSet/<rsconfigsver1:port1>,<rsconfigsver2:port2>,<rsconfigsver3:port3>
    
  15. Re-enable the balancer as described in Enable the Balancer.

Was this page helpful?

Yes No

Thank you for your feedback!

We're sorry! You can Report a Problem to help us improve this page.