rs.reconfig()
Definition
rs.
reconfig
(configuration, force)- Reconfigures an existing replica set, overwriting the existingreplica set configuration. To run the method, you must connect tothe primary of the replica set.
ParameterTypeDescriptionconfiguration
documentA document that specifiesthe configuration of a replica set.force
documentOptional. If set as { force: true }
, this forces the replica set toaccept the new configuration even if a majority of the members arenot accessible. Use with caution, as this can lead torollback situations.
To reconfigure an existing replica set, first retrieve thecurrent configuration with rs.conf()
, modify theconfiguration document as needed, and then pass the modifieddocument to rs.reconfig()
.
rs.reconfig()
provides a wrapper around thereplSetReconfig
command.
The force
parameter allows a reconfiguration command to be issuedto a non-primary node.
Consideration
Access Control
To run the method on deployments that enforce accesscontrol, the user must havereplSetConfigure
privilege action on the clusterresource. The clusterManager
built-in role, available inthe admin
database, provides the required privileges for thiscommand.
Locking Behavior
rs.reconfig()
obtains a special mutuallyexclusive lock to prevent more than oners.reconfig()
operation from occurring at the sametime.
Mixed Version Replica Set
Warning
Avoid reconfiguring replica sets that contain members of differentMongoDB versions as validation rules may differ across MongoDB versions.
Availability
The rs.reconfig()
shell method can trigger the current primaryto step down in some situations. Primary step-down triggers anelection to select a new primary:
- Starting in MongoDB 4.2, when the primary steps down, it no longercloses all client connections and writes that were in progress arekilled. For details, see Behavior.
- In MongoDB 4.0 and earlier, when the primary steps down, it closesall client connections.
The median time before a cluster elects a new primary should nottypically exceed 12 seconds, assuming default replicaconfiguration settings
. This includes time required tomark the primary as unavailable andcall and complete an election.You can tune this time period by modifying thesettings.electionTimeoutMillis
replication configurationoption. Factors such as network latency may extend the time requiredfor replica set elections to complete, which in turn affects the amountof time your cluster may operate without a primary. These factors aredependent on your particular cluster architecture.
During the election process, the cluster cannotaccept write operations until it elects the new primary.
Your application connection logic should include tolerance for automaticfailovers and the subsequent elections. Starting in MongoDB 3.6, MongoDB driverscan detect the loss of the primary and automaticallyretry certain write operations a single time,providing additional built-in handling of automatic failovers and elections:
- MongoDB 4.2-compatible drivers enable retryable writes by default
- MongoDB 4.0 and 3.6-compatible drivers must explicitly enableretryable writes by including
retryWrites=true
in the connection string.
To further reduce potential impact to a production cluster,reconfigure only during scheduled maintenance periods.
{ force: true }
Warning
Using rs.reconfig()
with { force: true }
can lead torollback of majority-committed writes. Exercise caution whenusing this option.
Member Priority and Votes
Changed in version 3.2.
Drop Outgoing Connections After Removing a Member
Using rs.reconfig()
to remove a replica set member does notautomatically drop open outgoing connections from other replica setmembers to the removed member.
By default, replica set members wait for 5 minutes before droppingconnections to the removed member. In sharded replica sets, you canmodify this timeout using theShardingTaskExecutorPoolHostTimeoutMS
server parameter.
New in version 4.2: To immediately drop all outgoing connections from the replica set tothe removed member, run the dropConnections
administrative command on each remaining member on the replica set:
- db.adminCommand(
- {
- "dropConnections" : 1,
- "hostAndPort" : [
- "<hostname>:<port>"
- ]
- }
- )
Replace <hostname>
and <port>
with those of the removedmember.
Examples
A replica set named rs0
has the following configuration:
- {
- "_id" : "rs0",
- "version" : 1,
- "protocolVersion" : NumberLong(1),
- "members" : [
- {
- "_id" : 0,
- "host" : "mongodb0.example.net:27017",
- "arbiterOnly" : false,
- "buildIndexes" : true,
- "hidden" : false,
- "priority" : 1,
- "tags" : {
- },
- "slaveDelay" : NumberLong(0),
- "votes" : 1
- },
- {
- "_id" : 1,
- "host" : "mongodb1.example.net:27017",
- "arbiterOnly" : false,
- "buildIndexes" : true,
- "hidden" : false,
- "priority" : 1,
- "tags" : {
- },
- "slaveDelay" : NumberLong(0),
- "votes" : 1
- },
- {
- "_id" : 2,
- "host" : "mongodb2.example.net:27017",
- "arbiterOnly" : false,
- "buildIndexes" : true,
- "hidden" : false,
- "priority" : 1,
- "tags" : {
- },
- "slaveDelay" : NumberLong(0),
- "votes" : 1
- }
- ],
- "settings" : {
- "chainingAllowed" : true,
- "heartbeatIntervalMillis" : 2000,
- "heartbeatTimeoutSecs" : 10,
- "electionTimeoutMillis" : 10000,
- "catchUpTimeoutMillis" : 2000,
- "getLastErrorModes" : {
- },
- "getLastErrorDefaults" : {
- "w" : 1,
- "wtimeout" : 0
- },
- "replicaSetId" : ObjectId("58858acc1f5609ed986b641b")
- }
- }
The following sequence of operations updates themembers[n].priority
of the second member.The operations are issued through a mongo
shell connected tothe primary.
- cfg = rs.conf();
- cfg.members[1].priority = 2;
- rs.reconfig(cfg);
The first statement uses the
rs.conf()
method to retrievea document containing the current configuration for the replica set and sets thedocument to the local variablecfg
.The second statement sets a
members[n].priority
value to thesecond document in themembers
array.For additional settings, see replica set configuration settings.
To access the member configuration document in the array, thestatement uses the array index and not the replica set member’smembers[n]._id
field.
- The last statement calls the
rs.reconfig()
method with themodifiedcfg
to initialize this new configuration. Uponsuccessful reconfiguration, the replica set configuration willresemble the following:
- {
- "_id" : "rs0",
- "version" : 2,
- "protocolVersion" : NumberLong(1),
- "members" : [
- {
- "_id" : 0,
- "host" : "mongodb0.example.net:27017",
- "arbiterOnly" : false,
- "buildIndexes" : true,
- "hidden" : false,
- "priority" : 1,
- "tags" : {
- },
- "slaveDelay" : NumberLong(0),
- "votes" : 1
- },
- {
- "_id" : 1,
- "host" : "mongodb1.example.net:27017",
- "arbiterOnly" : false,
- "buildIndexes" : true,
- "hidden" : false,
- "priority" : 2,
- "tags" : {
- },
- "slaveDelay" : NumberLong(0),
- "votes" : 1
- },
- {
- "_id" : 2,
- "host" : "mongodb2.example.net:27017",
- "arbiterOnly" : false,
- "buildIndexes" : true,
- "hidden" : false,
- "priority" : 1,
- "tags" : {
- },
- "slaveDelay" : NumberLong(0),
- "votes" : 1
- }
- ],
- "settings" : {
- "chainingAllowed" : true,
- "heartbeatIntervalMillis" : 2000,
- "heartbeatTimeoutSecs" : 10,
- "electionTimeoutMillis" : 10000,
- "catchUpTimeoutMillis" : 2000,
- "getLastErrorModes" : {
- },
- "getLastErrorDefaults" : {
- "w" : 1,
- "wtimeout" : 0
- },
- "replicaSetId" : ObjectId("58858acc1f5609ed986b641b")
- }
- }
See also