You can add members to an existing shard in a sharded cluster. You might want to add a member to a shard for the same reasons you'd want to add a member to any replica set. For example, increasing the number of members provides additional candidates to replace a primary in the event of a failover. Additional members also increase data redundancy and replica set availability.
For more information, refer to Replica Set Deployment Architectures.
Before MongoDB 5.0, a newly added secondary still counts as a voting
member even though it can neither serve reads nor become primary until
its data is consistent. If you are running a MongoDB version earlier
than 5.0 and add a secondary with its
priority settings greater than zero, this can
lead to a case where a majority of the voting members are
online but no primary can be elected. To avoid such situations,
consider adding the new secondary initially with
priority :0 and
votes :0. Then, run
rs.status() to ensure the
member has transitioned into
SECONDARY state. Finally, use
rs.reconfig() to update its priority and votes.
To add a member to a shard replica set, you need:
An active sharded cluster replica set.
A new host server for the new member. The new host server must be able to support your sharded data set and be accessible by the active replica set through the network.
Prepare the new member's data directory using one of the following strategies:
Have the new member automatically sync data from an existing member. This process takes time but does not require administrator intervention.
Make sure the new member's data directory does not contain data. The new member will copy the data from an existing member.
Manually copy the data directory from an existing member. The new member becomes a secondary member and will catch up to the current state of the replica set. Copying the data over may shorten the amount of time it takes for the new member to sync with the other replica set members.
Ensure that you can copy the data directory to the new member and begin replication within the window allowed by the oplog. Otherwise, the new instance will have to perform an initial sync, which completely resynchronizes the data, as described in Resync a Member of a Replica Set.
To check the current state of replica set members with regards to the oplog, use
For background on replication deployment patterns, see the Replica Set Deployment Architectures document.
Start the new
Specify the data directory
and the replica set name. The following example specifies the
/srv/mongodb/db0 data directory and the
rs0 replica set:
mongod --dbpath /srv/mongodb/db0 --replSet rs0 --bind_ip localhost,<ip address of the mongod host>
For more information on configuration options, see the
mongod manual page.
You can only add members while connected to the primary. To connect to
the primary, use
mongosh. Replace the
with relevant values for your deployment:
mongosh --host mongodb0.example.com --port 28015
If you do not know which member is the primary, connect to any member
of the replica set and issue the
rs.reconfig()shell method can force the current primary to step down, which causes an election. When the primary steps down, the
mongodcloses all client connections. While this typically takes 10-20 seconds, try to make these changes during scheduled maintenance periods.
Avoid reconfiguring replica sets that contain members of different MongoDB versions as validation rules may differ across MongoDB versions.
rs.conf() returns the configuration document for
mongodb3.example.net:27017 as the fifth element in the
members array, to update its priority and votes to
1, use the following sequence of operations:
var cfg = rs.conf(); cfg.members.priority = 1 cfg.members.votes = 1 rs.reconfig(cfg)