On this page本页内容
You can access the configuration of a replica set using the 可以使用rs.conf() method or the replSetGetConfig command.rs.conf()方法或replSetGetConfig命令访问副本集的配置
To modify the configuration for a replica set, use the 要修改副本集的配置，请使用rs.reconfig() method, passing a configuration document to the method. rs.reconfig()方法，将配置文档传递给该方法。See 更多信息请参见rs.reconfig() for more information.rs.reconfig()。
Warning
Avoid reconfiguring replica sets that contain members of different MongoDB versions as validation rules may differ across MongoDB versions.避免重新配置包含不同MongoDB版本成员的副本集，因为不同MongoDB版本的验证规则可能不同。
The following document provides a representation of a replica set configuration document. 以下文档提供了副本集配置文档的表示形式。The configuration of your replica set may include only a subset of these settings:副本集的配置可能仅包括以下设置的子集：
_id¶Type: string
The name of the replica set. Once set, you cannot change the name of a replica set.副本集的名称。一旦设置，就不能更改副本集的名称。
_id must be identical to the replication.replSetName or the value of –replSet
specified to mongod on the command line.
See
replSetName or --replSet for information on setting the replica set name.
version¶Type: int
An incrementing number used to distinguish revisions of the replica set configuration document from previous iterations of the configuration.一个递增的数字，用于区分副本集配置文档的修订版本与以前的配置迭代版本。
Changed in version 4.4.在版本4.4中更改。Replica set members use term and version to achieve consensus on the “newest” replica configuration. When members compare replica configuration documents, the configuration document with a larger term is considered the “newest”. If term is the same or absent, the configuration document with the larger version is considered “newest”.
term¶Type: int
New in version 4.4.版本4.4中的新功能。
Only available with featureCompatibilityVersion (fCV) “4.4” or later.
An incrementing number used to distinguish revisions of the replica set configuration document from previous iterations of the configuration. The term of a configuration document matches the term of the replica set primary which performed the reconfiguration. The primary increments its term each time it steps up after winning an election. The primary ignores the term field if set explicitly in the replSetReconfig operation.
Issuing a force reconfiguration removes the term field. When the primary next issues replSetReconfig without force, it sets the term to its own term.
Replica set members use term and version to achieve consensus on the “newest” replica configuration. When members compare replica configuration documents, the configuration document with a larger term is considered the “newest”. If term is the same or absent, the configuration document with the larger version is considered “newest”.
configsvr¶New in version 3.2.版本3.2中的新功能。
Type: boolean
Default: false
Indicates whether the replica set is used for a sharded cluster’s config servers. 指示复制集是否用于分片群集的配置服务器。Set to true if the replica set is for a sharded cluster’s config servers.
See also参阅
protocolVersion¶New in version 3.2.版本3.2中的新功能。
Type: number
Default: 1
Starting in 4.0, MongoDB only supports protocolVersion: 1 and no longer supports protocolVersion: 0.
See also参阅
writeConcernMajorityJournalDefault¶New in version 3.2.6.
Type: boolean
Default: true
Determines the behavior of { w: "majority" } write concern if the write concern does not explicitly specify the journal option j.
The following table lists the writeConcernMajorityJournalDefault values and the associated { w: "majority" } behavior:
| Value | { w: "majority" } Behavior |
|---|---|
| true |
Important All voting members of the replica set must run with journaling when If any voting member of a replica set uses the in-memory storage engine, you must set If any voting member of a replica set uses the in-memory storage engine and Starting in version 4.2 (and 4.0.13 and 3.6.14 ), if a replica set member uses the in-memory storage engine (voting or non-voting) but the replica set has |
| false |
Warning If any voting member of a replica set uses the in-memory storage engine, you must set Starting in version 4.2 (and 4.0.13 and 3.6.14 ), if a replica set member uses the in-memory storage engine (voting or non-voting) but the replica set has You cannot run transactions on a sharded cluster that has a shard with |
See also参阅
members¶members¶Type: array
An array of member configuration documents, one for each member of the replica set. 一组成员配置文档，副本集的每个成员对应一个。The members array is a zero-indexed array.members数组是一个零索引数组。
Each member-specific configuration document can contain the following fields:每个特定于成员的配置文档可以包含以下字段：
members[n]._id¶Type: integer
An integer identifier of every member in the replica set. Values must be between 0 and 255 inclusive. Each replica set member must have a unique _id. Avoid re-using _id values even if no members[n] entry is using that _id in the current configuration.
Once set, you cannot change the _id of a member.
Note
When updating the replica configuration object, access the replica set members in the members array with the array index. The array index begins with 0. Do not confuse this index value with the value of the members[n]._id field in each document in the members array.
members[n].host¶Type: string
The hostname and, if specified, the port number, of the set member.集合成员的主机名和端口号（如果指定）。
The hostname name must be resolvable for every host in the replica set.主机名必须可解析为副本集中的每个主机。
Warning
members[n].host cannot hold a value that resolves to localhost or the local interface unless all members of the set are on hosts that resolve to localhost.
members[n].arbiterOnly¶Optional.
Type: boolean
Default: false
A boolean that identifies an arbiter. 标识仲裁器的布尔值。A value of 值为true indicates that the member is an arbiter.true表示该成员是仲裁者。
When using the rs.addArb() method to add an arbiter, the method automatically sets members[n].arbiterOnly to true for the added member.
For the following MongoDB versions, pv1 increases the likelihood of w:1 rollbacks compared to pv0 (no longer supported in MongoDB 4.0+) for replica sets with arbiters:
members[n].buildIndexes¶Optional.
Type: boolean
Default: true
A boolean that indicates whether the mongod builds indexes on this member. You can only set this value when adding a member to a replica set. You cannot change members[n].buildIndexes field after the member has been added to the set. To add a member, see rs.add() and rs.reconfig().
Do not set to false for mongod instances that receive queries from clients.
Setting buildIndexes to false may be useful if all
the following conditions are true:
mongodump, andEven if set to false, secondaries will build indexes on the _id field in order to facilitate operations required for replication.
Warning
If you set members[n].buildIndexes to false, you must also set members[n].priority to 0. If members[n].priority is not 0, MongoDB will return an error when attempting to add a member with members[n].buildIndexes equal to false.
To ensure the member receives no queries, you should make all instances that do not build indexes hidden.
Other secondaries cannot replicate from a member where members[n].buildIndexes is false.
Optional.
Type: boolean
Default: false
When this value is true, the replica set hides this instance and does not include the member in the output of db.isMaster() or isMaster. This prevents read operations (i.e. queries) from ever reaching this host by way of secondary read preference.
Hidden members can acknowledge write operations issued with Write Concern. For write operations issued with "majority" write concern, the member must also be a voting member (i.e. votes is greater than 0).
See also参阅
members[n].priority¶Changed in version 3.6:Starting in MongoDB 3.6, arbiters have the priority 0. If an arbiter has a priority of 1, MongoDB 3.6 reconfigures the arbiter to have a priority of 0.
Optional.
Type: Number between 0 and 1000 for primary/secondary; 0 or 1 for arbiters.
Default: 1.0 for primary/secondary; 0 for arbiters.
A number that indicates the relative eligibility of a member to become a primary.
Specify higher values to make a member more eligible to become primary, and lower values to make the member less
eligible. A member with a members[n].priority of 0 is ineligible to become primary.
Members with priority greater than 0 cannot have 0 votes.
Changing the balance of priority in a replica set will trigger one or more elections. If a lower priority secondary is elected over a higher priority secondary, replica set members will continue to call elections until the highest priority available member becomes primary.
Members with priority of 0 can acknowledge write operations issued with Write Concern. For write operations issued with "majority" write concern, the member must also be a voting member (i.e. votes is greater than 0).
See also参阅
Optional.
Type: document
Default: none
A tags document contains user-defined tag field and value pairs for the replica set member.
settings.getLastErrorModes and settings.getLastErrorDefaults.For more information, see Configure Replica Set Tag Sets.
members[n].slaveDelay¶Optional.
Type: integer
Default: 0
The number of seconds “behind” the primary that this replica set member should “lag”.
Use this option to create delayed members. Delayed members maintain a copy of the data that reflects the state of the data at some time in the past.
Delayed members can contribute to acknowledging write operations issued with Write Concern. However, they return write acknowledgment no earlier than the configured delay value. For write operations issued with "majority" write concern, the member must also be a voting member (i.e. votes is greater than 0).
See also参阅
members[n].votes¶Optional.
Type: integer
Default: 1
The number of votes a server will cast in a replica set election. The number of votes each member has is either 1 or 0, and arbiters always have exactly 1 vote.
Members with priority greater than 0 cannot have 0 votes.
A replica set can have up to 50 members but only 7 voting members. If you need more than 7 members in one replica set, set members[n].votes to 0 for the additional non-voting members.
Non-voting (i.e. votes is 0) members must have priority of 0.
Non-voting members cannot acknowledge write operations issued with a "majority" write concern.
settings¶settings¶Optional.
Type: document
A document that contains configuration options that apply to the whole replica set.
The settings document contain the following fields:
settings.chainingAllowed¶Optional.
Type: boolean
Default: true
When settings.chainingAllowed is true, the replica set allows secondary members to replicate from other secondary members. When settings.chainingAllowed is false, secondaries can replicate only from the primary.
See also参阅
settings.getLastErrorDefaults¶Optional.
Type: document
A document that specifies the write concern for the replica set. The replica set will use this write concern only when write operations or getLastError specify no other write concern.
If settings.getLastErrorDefaults is not set, the default write concern for the replica set only requires confirmation from the primary.
Important
Starting in version 4.4, MongoDB deprecates specifying a settings.getLastErrorDefaults value other than the default of { w: 1, wtimeout: 0 }. MongoDB 4.4 honors any write concern value that you specify, however future MongoDB versions might not honor values other than the default. Instead, use the setDefaultRWConcern command to set the default read or write concern configuration for a replica set or sharded cluster.
settings.getLastErrorModes¶Optional.
Type: document
A document used to define a custom write concern through the use of members[n].tags. The custom write concern can provide data-center awareness.
The <number> refers to the number of different tag values required to satisfy the write concern. For example, the following settings.getLastErrorModes defines a write concern named datacenter that requires the write to propagate to two members whose dc tag values differ.
To use the custom write concern, pass in the write concern name to the w Option, e.g.
See Configure Replica Set Tag Sets for more information and example.
settings.heartbeatTimeoutSecs¶Optional.
Type: int
Default: 10
Number of seconds that the replica set members wait for a successful heartbeat from each other. If a member does not respond in time, other members mark the delinquent member as inaccessible.
Note
For pv1, settings.electionTimeoutMillis has a greater influence on whether the secondary members call for an election than the settings.heartbeatTimeoutSecs.
settings.electionTimeoutMillis¶New in version 3.2.版本3.2中的新功能。
Optional.
Type: int
Default: 10000 (10 seconds)
The time limit in milliseconds for detecting when a replica set’s primary is unreachable:
The setting only applies when using protocolVersion: 1.
Note
Changed in version 4.0.2:If the parameter enableElectionHandoff is true (default), when a primary steps down from rs.stepDown() (or the replSetStepDown command without the force:
true), the stepped-down primary nominates an eligible secondary to call an election immediately. Otherwise, secondaries can wait up to settings.electionTimeoutMillis before calling an election. The stepped down primary does not wait for the effects of the handoff. For more information, see enableElectionHandoff.
settings.catchUpTimeoutMillis¶New in version 3.4.版本3.4中的新功能。
Optional.
Type: int
Changed in version 3.6:
Default: -1, infinite catchup time.
Time limit in milliseconds for a newly elected primary to sync (catch up) with the other replica set members that may have more recent writes. Infinite or high time limits may reduce the amount of data that the other members would need to roll back after an election but may increase the failover time.
The newly elected primary ends the catchup period early once it is fully caught up with other members of the set. During the catchup period, the newly elected primary is unavailable for writes from clients. Use replSetAbortPrimaryCatchUp to abort the catchup then complete the transition to primary.
The setting only applies when using protocolVersion: 1.
Note
To downgrade a replica set initiated in version 3.6 to 3.4, change catchUpTimeoutMillis from -1 to a positive number. Failure to change this value to a positive number causes nodes running version 3.4 to neither restart nor join the replica set.
settings.catchUpTakeoverDelayMillis¶New in version 3.6.版本3.6中的新功能。
Optional.
Type: int
Default: 30000 (30 seconds)
Time in milliseconds a node waits to initiate a catchup takeover after determining it is ahead of the current primary. During a catchup takeover, the node ahead of the current primary initiates an election to become the new primary of the replica set.
After the node initiating the takeover determines that it is ahead of the current primary, it waits the specified number of milliseconds and then verifies the following:
Once determining that all of these conditions are met, the node initiating the takeover immediately runs for election.
For more information on Replica Set Elections, see Replica Set Elections.
Note
Setting catchUpTakeoverDelayMillis to -1 disables catchup takeover. Setting catchUpTimeoutMillis to 0 disables primary catchup and consequently also catchup takeover.
settings.heartbeatIntervalMillis¶New in version 3.2.版本3.2中的新功能。
Internal use only.
The frequency in milliseconds of the heartbeats.
settings.replicaSetId¶New in version 3.2.版本3.2中的新功能。
Type: ObjectId
The ObjectId associated with the replica set and automatically created during rs.initiate() or replSetInitate. You cannot change the replicaSetId.