On this page本页内容
Replica sets allow a MongoDB deployment to remain available during the majority of a maintenance window.
This document outlines the basic procedure for performing maintenance on each of the members of a replica set. Furthermore, this particular sequence strives to minimize the amount of time that the primary is unavailable and control the impact on the entire deployment.
Use these steps as the basis for common replica set operations, particularly for procedures such as upgrading to the latest version of MongoDB.
For each member of a replica set, starting with a secondary member, perform the following sequence of events, ending with the primary:
mongod
instance as a standalone.mongod
instance as a member of the replica set.At the operating system shell prompt restart mongod
as a standalone instance.
If you are using a configuration file, make the following configuration updates:
replication.replSetName
option.net.port
to a different port. Make a note of the original port setting as a comment.disableLogicalSessionCacheRefresh
to true
in the setParameter
section.mongod
is a shard or config server member, you must also:sharding.clusterRole
option.skipShardingConfigurationChecks
(also available for MongoDB 3.6.3+, 3.4.11+, 3.2.19+) to true
in the setParameter
section.For example, if performing maintenance on a shard/config server replica set member for maintenance, the updated configuration file will include content like the following example:
If using command-line options, make the following configuration updates to restart:
--replSetName
.--port
to a different port.disableLogicalSessionCacheRefresh
to true
in the --setParameter
option.mongod
is a shard or config server member, you must also:--shardsvr
if a shard member and --configsvr
if a config server member.skipShardingConfigurationChecks
(also available for MongoDB 3.6.3+, 3.4.11+, 3.2.19+) to true
in the setParameter
section.For example, to restart a replica set member that is not part of a sharded cluster:
For example, to restart a shard/config server replica set member for maintenance:
Warning
Before binding to a non-localhost (e.g. publicly accessible) IP address, ensure you have secured your cluster from unauthorized access. For a complete list of security recommendations, see Security Checklist. At minimum, consider enabling authentication and hardening network infrastructure.
Always start mongod
with the same user, even when restarting a replica set member as a standalone instance.
While the member is a standalone, use the mongo
shell to perform maintenance:
Important
While the member is a standalone, no writes are replicated to this member nor are writes on this member replicated to the other members of the replica set.
Ensure that any writes on this standalone do not conflict with oplog writes that will be applied to the member when it rejoins the replica set.
mongod
as a member of the replica set.¶After performing all maintenance tasks, use the following procedure to restart the mongod
as a member of the replica set on its usual port.
From the mongo
shell, shut down the standalone server after completing the maintenance:
Restart the mongod
instance as a replica set member with its original configuration; that is, undo the configuration changes made when starting as a standalone.
Tip
Be sure to remove the disableLogicalSessionCacheRefresh
parameter.
For shard or config server members, be sure to remove the skipShardingConfigurationChecks
parameter.
When it has started, connect the mongo
shell to the restarted instance.
The secondary takes time to catch up to the primary. From the mongo
shell, use the following command to verify that the member has caught up from the RECOVERING
state to the SECONDARY
state.
mongo
shell to the primary and use rs.stepDown()
to step down the primary and allow one of the secondaries to be elected the new primary. Specify a 300 second waiting period to prevent the member from being elected primary again for five minutes:
After the primary steps down, the replica set will elect a new primary.
mongod
as a standalone instance, making the following configuration updates.If you are using a configuration file, make the following configuration updates:
replication.replSetName
option.net.port
to a different port. Make a note of the original port setting as a comment.disableLogicalSessionCacheRefresh
to true
in the --setParameter
option.mongod
is a shard or config server member, you must also:sharding.clusterRole
option.skipShardingConfigurationChecks
(also available for MongoDB 3.6.3+, 3.4.11+, 3.2.19+) to true
in the setParameter
section.For example, if performing maintenance on a shard/config server replica set member for maintenance, the updated configuration file will include content like the following example:
Warning
Before binding to a non-localhost (e.g. publicly accessible) IP address, ensure you have secured your cluster from unauthorized access. For a complete list of security recommendations, see Security Checklist. At minimum, consider enabling authentication and hardening network infrastructure.
If using command-line options, make the following configuration updates:
--replSetName
.--port
to a different port.disableLogicalSessionCacheRefresh
to true
in the --setParameter
option.mongod
is a shard or config server member, you must also:--shardsvr
if a shard member and --configsvr
if a config server member.skipShardingConfigurationChecks
(also available for MongoDB 3.6.3+, 3.4.11+, 3.2.19+) to true
in the setParameter
section.For example, to restart a replica set member that is not part of a sharded cluster:
For example, to restart a shard/config server replica set member for maintenance:
Warning
Before binding to a non-localhost (e.g. publicly accessible) IP address, ensure you have secured your cluster from unauthorized access. For a complete list of security recommendations, see Security Checklist. At minimum, consider enabling authentication and hardening network infrastructure.
Important
While the member is a standalone, no writes are replicated to this member nor are writes on this member replicated to the other members of the replica set.
Ensure that any writes on this standalone do not conflict with oplog writes that will be applied to the member when it rejoins the replica set.
mongod
instance as a replica set member with its original configuration; that is, undo the configuration changes made when starting as a standalone.
Tip
Be sure to remove the disableLogicalSessionCacheRefresh
parameter.
For shard or config server members, be sure to remove the skipShardingConfigurationChecks
parameter.