- Replication >
- Member Configuration Tutorials >
- Convert a Secondary to an Arbiter
Convert a Secondary to an Arbiter¶
On this page
If you have a secondary in a replica set that no longer needs to hold data but that needs to remain in the set to ensure that the set can elect a primary, you may convert the secondary to an arbiter using either procedure in this tutorial. Both procedures are operationally equivalent:
You may operate the arbiter on the same port as the former secondary. In this procedure, you must shut down the secondary and remove its data before restarting and reconfiguring it as an arbiter.
For this procedure, see Convert Secondary to Arbiter and Reuse the Port Number.
Run the arbiter on a new port. In this procedure, you can reconfigure the server as an arbiter before shutting down the instance running as a secondary.
For this procedure, see Convert Secondary to Arbiter Running on a New Port Number.
Note
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:
- MongoDB 3.4.1
- MongoDB 3.4.0
- MongoDB 3.2.11 or earlier
Convert Secondary to Arbiter and Reuse the Port Number¶
If your application is connecting directly to the secondary, modify the application so that MongoDB queries don’t reach the secondary.
Shut down the secondary.
Remove the secondary from the replica set by calling the
rs.remove()
method. Perform this operation while connected to the current primary in themongo
shell:Verify that the replica set no longer includes the secondary by calling the
rs.conf()
method in themongo
shell:Move the secondary’s data directory to an archive folder. For example:
Optional
You may remove the data instead.
Create a new, empty data directory to point to when restarting the
mongod
instance. You can reuse the previous name. For example:Restart the
mongod
instance for the secondary, specifying the port number, the empty data directory, and the replica set. You can use the same port number you used before. Issue a command similar to the following: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.
In the
mongo
shell convert the secondary to an arbiter using thers.addArb()
method:Verify the arbiter belongs to the replica set by calling the
rs.conf()
method in themongo
shell.The arbiter member should include the following:
Convert Secondary to Arbiter Running on a New Port Number¶
If your application is connecting directly to the secondary or has a connection string referencing the secondary, modify the application so that MongoDB queries don’t reach the secondary.
Create a new, empty data directory to be used with the new port number. For example:
Start a new
mongod
instance on the new port number, specifying the new data directory and the existing replica set. Issue a command similar to the following: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.
In the
mongo
shell connected to the current primary, convert the newmongod
instance to an arbiter using thers.addArb()
method:Verify the arbiter has been added to the replica set by calling the
rs.conf()
method in themongo
shell.The arbiter member should include the following:
Shut down the secondary.
Remove the secondary from the replica set by calling the
rs.remove()
method in themongo
shell:Verify that the replica set no longer includes the old secondary by calling the
rs.conf()
method in themongo
shell:Move the secondary’s data directory to an archive folder. For example:
Optional
You may remove the data instead.