Docs Home → MongoDB Ops Manager
Convert a Standalone to a Replica Set![](/docs/ops-manager/master/assets/link.svg)
Overview![](/docs/ops-manager/master/assets/link.svg)
Ops Manager provides the ability to convert a standalone instance to a replica set. When converted, the replica set will have the former standalone instance as its primary.
Procedure![](/docs/ops-manager/master/assets/link.svg)
Navigate to the Clusters view for your deployment.![](/docs/ops-manager/master/assets/link.svg)
If it is not already displayed, select the organization that contains your desired project from the Organizations menu in the navigation bar.
If it is not already displayed, select your desired project from the Projects menu in the navigation bar.
If it is not already displayed, click Deployment in the sidebar.
Click the Clusters view.
Enter the replica set name.![](/docs/ops-manager/master/assets/link.svg)
Enter the replica set name and click the Convert button.
Important
The replica set name is immutable once deployed. This setting
corresponds to the _id
replica
configuration option.
Ops Manager displays the Editing Replica Set view. The following steps describe the contents of each section in that view.
Configure Cluster-Wide Settings![](/docs/ops-manager/master/assets/link.svg)
The Replica Set Configuration section contains the following cluster-wide configuration settings. Settings whose values are grey and non-interactive are immutable.
Setting | Description |
---|---|
Replica Set Id | Enter the name of your replica set deployment. You cannot change
this once set. This setting corresponds to the
|
Auth Schema Version | Select the schema for storing the user for storing the user data for your deployment. If you are upgrading from a MongoDB version older than 3.0, MongoDB 3.0+ uses a different schema for user data than previous versions. For compatibility information, see the Security Changes in the MongoDB 3.0 release notes. |
Feature Compatibility Version | Select the Feature Compatibility Version of the deployment. Ops Manager displays this field if your deployment runs MongoDB version 3.4 or later. |
Replica Set Settings | Displays an table of each process associated with the replica set. You can configure the MongoDB server version, data directory, and log path of each process. |
Process Name | Hostname and port of a mongod process. This hostname can be a hostname, an FQDN, an IPv4 address, or an IPv6 address. Ops Manager initially groups each process under the replica set name. Click the to the left of the replica set name to display all mongod processes in the replica set. Ops Manager applies any settings configured for the replica set to all of its associated processes. |
Version | Select the MongoDB server version of the ~bin.mongod process. NoteAvailable VersionsOps Manager lists only the MongoDB versions that are available for your deployment. To disable this filtering, see
|
Data Directory | Specify the directory where the ~bin.mongod process stores
data files. This setting corresponds to the
Each ~bin.mongod process must have its own database directory. If deploying multiple ~bin.mongod processes on the same host, ensure each process has its own distinct directory. |
Log File | Specify the full path to the ~bin.mongod log file, including the
log file name and extension. This setting corresponds to the
ExampleSpecifying The ~bin.mongod have its own unique log file. If deploying multiple ~bin.mongod processes to the same host, ensure each ~bin.mongod has its own distinct logfile. |
Configure each Replica Set Member.![](/docs/ops-manager/master/assets/link.svg)
Ops Manager lists each replica set member under the MongoD Settings heading of the Member Configuration section. Each replica set member has the following options:
Setting | Description |
---|---|
Member | Select one of the following replica set member roles from the menu:
|
Hostname | Select from the menu the host to which Ops Manager Automation deploys the replica set member. The menu only lists hosts under Ops Manager Automation. For complete documentation on adding servers to Ops Manager Automation, see Provision Servers for Automation. This hostname can be a hostname, an FQDN, an IPv4 address, or an IPv6 address. |
Port | Specify the IANA port
number for the ~bin.mongod process. This setting
corresponds to the The ~bin.mongod must have exclusive access to the specified port. If deploying multiple ~bin.mongod processes to a single host, you must select a unique unused port for each process. |
Votes | Specify the number of votes that the replica set member has during
elections. This setting corresponds to the
|
Priority | Specify the priority of the member during elections. Replica set
members with a priority of |
Delay | Specify the number of seconds "behind" the primary member this
member should "lag". This setting corresponds to the
|
Build Indexes | Specify |
Tags | Specify the tag or tags associated to the replica set.
This setting corresponds to the
For complete documentation on replica set tags, see Replica Set Tags |
Add a Mongod | Adds an additional ~bin.mongod process as a replica set member. Adding a new ~bin.mongod process also updates the list of processes in the Replica Set Configuration section. You must configure the Version, Data Directory, and Log File of the new process. |
Configure the Replica Set Settings.![](/docs/ops-manager/master/assets/link.svg)
The Replication Settings section contains the following configuration options for the replica set:
Setting | Description |
---|---|
Protocol Version | Select the replication protocol version used by the replica set.
This setting corresponds to the
For more information, see Replica Set Protocol Versions. |
Chaining Allowed | Specify |
Write Concern Majority Journal Default | Determines the behavior of
|
Heartbeat Timeout (secs) | Specify the number of seconds that the replica set members wait for
a successful heartbeat from each other. This setting corresponds to
the |
Election Timeout (ms) | Specify the time limit in milliseconds for detecting when a replica
set's primary is unreachable. This setting corresponds to
the |
CatchUp Timeout (ms) | Specify the time limit in milliseconds for a newly elected
primary to sync, or catch up, with the other replica
set members that may have more recent writes. This setting
corresponds to the
|
CatchUp Takeover Delay (ms) | Specify the time in milliseconds a node waits to initiate a
catchup takeover after determining it is ahead of the
current primary. This setting corresponds to the
|
Last Error Defaults | Specify the default write concern for the replica set. The replica set uses this write concern only when write operations or getLastError specify no other write concern. If this option is not set, the default write concern for the replica set only requires confirmation from the primary. Specify this option in the form of a document, i.e., |
Force Reconfigure | Specify that you want to force a reconfiguration of the replica
set. When set to WarningForcing a replica set reconfiguration might lead to a rollback of majority-committed writes. Proceed with caution. Contact MongoDB Support if you have questions about the potential impacts of this operation. TipSee also:Reconfigure a Replica Set with Unavailable Members in the MongoDB Server Manual. |
Set any advanced configuration options for your MongoDB replica set.![](/docs/ops-manager/master/assets/link.svg)
The Advanced Configuration Options section allows you to set MongoDB runtime options for each MongoDB process in your deployment.
To add an option:
Click Add Advanced Options.
Click Select a Startup Option and select the configuration option.
Ops Manager displays a context-sensitive input for configuring an acceptable value for the selected option.
Click Add to add the selected option and its corresponding value to every process of the selected process type in the cluster.
Ops Manager lists each process in the cluster grouped logically. Click the grey arrow to the left of the logical grouping to display its sub-groupings and processes. You can modify the advanced options for each process individually as necessary.
For descriptions of the available Advanced Configuration Options, see Advanced Options for MongoDB Deployments.