replSetReconfig (original) (raw)

replSetReconfig

The replSetReconfig administrative command 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. You must run this command on the admindatabase of the primary replica set member.

Tip

In mongosh, this command can also be run through the rs.reconfig() helper method.

Helper methods are convenient for mongosh users, but they may not return the same level of information as database commands. In cases where the convenience is not needed or the additional return fields are required, use the database command.

This command is available in deployments hosted in the following environments:

• MongoDB Atlas: The fully managed service for MongoDB deployments in the cloud

Important

This command is not supported in M0, M2, M5, M10+, and Flex clusters. For more information, see Unsupported Commands.

• MongoDB Enterprise: The subscription-based, self-managed version of MongoDB
• MongoDB Community: The source-available, free-to-use, and self-managed version of MongoDB

The command has the following syntax:

db.adminCommand(

   {

     replSetReconfig: <new_config_document>,

     force: <boolean>,

     maxTimeMS: <int>

    }

 )

The command takes the following optional field:

You may also run replSetReconfig with the shell'srs.reconfig() method.

Starting in MongoDB 5.0, you must explicitly set the global defaultwrite concern before attempting to reconfigure areplica set with aconfigurationthat would change the implicit default write concern. To set the global default write concern, use the setDefaultRWConcern command.

The term field is set by the primary replica set member. The primary ignores the term field if set explicitly in thereplSetReconfig operation.

replSetReconfig by default allows adding or removing no more than 1 votingmember at a time. For example, a new configuration can make at most_one_ of the following changes to the cluster membership:

• Adding a new voting replica set member.
• Removing an existing voting replica set member.
• Modifying the votes for an existing replica set member.

To add or remove multiple voting members, issue a series ofreplSetReconfig operations to add or remove one member at a time.

Issuing a force reconfiguration immediately installs the new configuration even if it adds or removes multiple voting members. Force reconfiguration can cause unexpected behavior, such as the rollback of "majority"committed write operations.

replSetReconfig waits until a majority of voting replica set members install the new replica configuration before returning success. A voting member is any replica set member wheremembers[n].votes is 1, including arbiters.

Replica set members propagate their replica configuration viaheartbeats. Whenever a member learns of a configuration with a higher version andterm, it installs the new configuration. The reconfiguration process has two distinct 'waiting' phases:

1. Wait for the current configuration to be committed before installing the new configuration.

The "current" configuration refers to the replica configuration in use by the primary at the time replSetReconfig is issued.

A configuration is committed when:

• A majority of voting replica set members have installed the current configuration, and
• All writes which were "majority" committed in the previous configuration have also replicated to a majority in the current configuration.

Typically, the current configuration has already been installed on a majority of voting replica set members. However, the majority committed writes in the previous configuration may not all be committed in the current configuration. Delayed members or members that arelagging behind the primary can increase the time spent in this phase.

If the operation was issued with amaxTimeMS limit _and_the operation exceeds the limit while waiting, the operation returns an error and discard the new configuration. The limit is cumulative and does not reset after proceeding to the next phase.

1. Wait for a majority of voting members in the new configuration to install the new configuration.

The "new" configuration refers to the replica configuration specified to replSetReconfig.

The primary installs and begins using the new replica configuration before propagating the configuration to the remaining replica set members. The operation only waits for a majority of voting members to install the new configuration, and does not require waiting for the new configuration to becommitted.

If the operation was issued with a maxTimeMS limit_and_ the operation exceeds the limit while waiting, the operation returns an error but continues using and propagating the new configuration.

Issuing a force reconfiguration immediately installs the new configuration regardless of the commitment status of the previous configuration. Force reconfiguration can cause unexpected behavior, such as the rollback of "majority" committed write operations.

To check the commitment status of the current replica configuration, issue replSetGetConfig with thecommitmentStatus parameter on the replica set primary.

Starting in MongoDB 5.0, a newly added secondary does not count as a voting member and cannot be elected until it has reached theSECONDARY state.

When a new voting node is added to a replica set,replSetReconfig will internally add a newlyAddedfield to the node's configuration. Nodes with the newlyAdded field do not count towards the current number of voting nodes. When initial sync completes and the node reaches SECONDARY state, thenewlyAdded field is automatically removed.

Note

• Configurations that attempt to add a field named newlyAddedwill error even if run with { force: true }.
• If an existing node has a newlyAdded field, usingrs.reconfig() to change the configuration will not remove the newlyAdded field. The newlyAdded field will be appended to the user provided configuration.
• replSetGetConfig will remove any newlyAdded fields from its output. If you would like to see any newlyAddedfields, you can query the local.system.replset collection directly.

To run the command on deployments that enforce access control, the user must havereplSetConfigure privilege action on the cluster resource. The clusterManager built-in role, available in the admin database, provides the required privileges for this command.

replSetReconfig obtains a special mutually exclusive lock to prevent more than onereplSetReconfig operation from occurring at the same time.

Warning

Avoid reconfiguring replica sets that contain members of different MongoDB versions as validation rules may differ across MongoDB versions.

A majority of the set's members must be operational for the changes to propagate properly.

replSetReconfig can trigger the current primary to step down in some situations. Primary step-down triggers an election to select a newprimary:

• When the new primary steps up, it increments the term field to distinguish configuration changes made on the new primary from changes made on the previous primary.
• When the primary steps down, it no longer closes all client connections; however, writes that were in progress are killed. For details, see Behavior.

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 thesettings.electionTimeoutMillis replication 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. MongoDB drivers can detect the loss of the primary and automaticallyretry certain write operations a single time, providing additional built-in handling of automatic failovers and elections:

Compatible drivers enable retryable writes by default

To further reduce potential impact to a production cluster, reconfigure only during scheduled maintenance periods.

Warning

MongoDB does not synchronize a forced replica set reconfiguration between the replica sets in a cluster. Using { force: true } can lead to a rollback of majority-committed writes and an inconsistent sharded cluster. Exercise caution when you use this option.

Using replSetReconfig to remove a replica set member does not automatically drop open outgoing connections from other replica set members to the removed member.

By default, replica set members wait for 5 minutes before dropping connections to the removed member. In sharded replica sets, you can modify this timeout using theShardingTaskExecutorPoolHostTimeoutMS server parameter.

To immediately drop all outgoing connections from the replica set to the removed member, run the dropConnectionsadministrative command on each remaining member on the replica set:

db.adminCommand(

  {

    "dropConnections" : 1,

    "hostAndPort" : [

      "<hostname>:<port>"

    ]

  }

)

Replace <hostname> and <port> with those of the removed member.

Warning

• Members with priority greater than 0 cannot have 0 votes.
• Non-voting (i.e. votes is 0) members must havepriority of 0.

Replica Set Configuration Fields,Self-Managed Replica Set Configuration, rs.reconfig(), andrs.conf().