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.
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.

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).

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).

A tag set document containing mappings of arbitrary keys and
values. These documents describe replica set members in order to customize
write concern and read preference and thereby allow configurable data
center awareness.

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).

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.

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:

It is still ahead of the current primary,

It is the most up-to-date node among all available nodes,

The current primary is currently catching up to it.

Once determining that all of these conditions are met, the node
initiating the takeover immediately runs for election.