replSetReconfigcommand modifies the configuration of an existing replica set. You can use this command to add and remove members, and to alter the options set on existing members. Use the following syntax:
Be aware of the following
replSetReconfig behaviors and considerations:
Avoid reconfiguring replica sets that contain members of different MongoDB versions as validation rules may differ across MongoDB versions.
You must issue this command against the admin database of the current primary member of the replica set.
You can optionally force the replica set to accept the new configuration by specifying
force: true. Use this option if there is no current primary in the replica set.
Use the force option to restore a replica set to new servers with different hostnames.
A majority of the set’s members must be operational for the changes to propagate properly.
replSetReconfigcan trigger the current primary to step down in some situations. When the primary steps down, it forcibly closes all client connections. Primary step-down triggers an election to select a new primary.
The median time before a cluster elects a new primary should not typically exceed 12 seconds, assuming default
replica configuration settings. This includes time required to mark the primary as unavailable and call and complete an election. You can tune this time period by modifying the
settings.electionTimeoutMillisreplication configuration option. Factors such as network latency may extend the time required for replica set elections to complete, which in turn affects the amount of time your cluster may operate without a primary. These factors are dependent on your particular cluster architecture.
During the election process, the cluster cannot accept write operations until it elects the new primary.
Your application connection logic should include tolerance for automatic failovers and the subsequent elections.
New in version 3.6: MongoDB 3.6+ drivers can detect the loss of the primary and automatically retry certain write operations a single time, providing additional built-in handling of automatic failovers and elections.
To further reduce potential impact to a production cluster, reconfigure only during scheduled maintenance periods.
Changed in version 3.2.
- Members with
prioritygreater than 0 cannot have 0
- Non-voting members must have
- Before changing the
protocolVersion, ensure that at least one oplog entry (generated from the current protocol version) has replicated from the primary to all secondaries. For details, see Modify Replica Set Protocol Version.