Deploy a Sharded Cluster
On this page
- OAuth 2.0 authentication for programmatic access to Cloud Manager is available as a Preview feature.
- The feature and the corresponding documentation might change at any time during the Preview period. To use OAuth 2.0 authentication, create a service account to use in your requests to the Cloud Manager Public API.
Sharded clusters provide horizontal scaling for large data sets and enable high throughput operations by distributing the data set across a group of servers.
To learn more about sharding, see Sharding Introduction in the MongoDB manual.
Use this procedure to deploy a new sharded cluster that Cloud Manager manages. Later, you can use Cloud Manager to add shards and perform other maintenance operations on the cluster.
To learn how to deploy a sharded cluster using a Kubernetes object, see Deploy a Sharded Cluster in the MongoDB Enterprise Kubernetes Operator documentation.
Note
New in Cloud Manager
You can use Kubernetes to deploy MongoDB instances with Cloud Manager.
To deploy MongoDB clusters, you must provision hosts to serve those clusters. Cloud Manager requires access to these hosts.
Important
If you run MongoDB Enterprise and provision your own Linux hosts, then you must manually install a set of dependencies to each server before installing MongoDB. The MongoDB manual provides the appropriate command to install the dependencies.
To learn more about the specifics for an operating system, see the following:
Considerations
Unique Names for Sharded Clusters
Use unique names for the new cluster and its shards.
Important
Replica set, sharded cluster, and shard names within the same project must be unique. Failure to have unique names for the deployments will result in broken backup snapshots.
Configuration Server Deployment Architecture
If you select MongoDB 3.4 or later for your configuration server
mongod
processes, Cloud Manager deploys your configuration servers as a
replica set.
To learn more about CSRS and mirrored configuration servers (SCCC), see Config Servers.
Removing a Shard
When you remove a shard, any unsharded databases in that shard are moved to a remaining shard using the movePrimary command.
All sharded collections remain online and available during the shard
removal process. However, read and write operations sent to unsharded
collections during the movePrimary
operation can result in
unexpected behavior, including failure of the migration or loss of
data.
We recommend moving the primary shard for any databases containing unsharded collections before removing the shard.
To learn more about removing shards, see Remove Shards from an Existing Sharded Cluster.
Procedure
In MongoDB Cloud Manager, go to the Deployment page for your project.
If it is not already displayed, select the organization that contains your desired project from the Organizations menu in the navigation bar.
If it's not already displayed, select your desired project from the Projects menu in the navigation bar.
If the Deployment page is not already displayed, click Deployment in the sidebar.
The Deployment page displays.
Configure Cluster-Wide Settings.
The Cluster Configuration section contains the following cluster-wide configuration settings. Settings marked with an * asterisk in the Cloud Manager UI are required.
Setting | Description |
---|---|
Cluster Name | Specify the name of your sharded cluster deployment. You cannot change this once set. |
Config Server Replica Set Name | Specify the name of your Config Server Replica Set. You cannot
change this once set. This setting corresponds to the
Cloud Manager only displays this option if you selected MongoDB 3.2 or later as the Version of your configuration servers. |
Shard Name Prefix | Specify the prefix of each shard in the cluster. Cloud Manager
names each shard in the cluster using the |
Process Name | Hostname and port of a Cloud Manager groups For clusters running MongoDB 3.0 or earlier, Cloud Manager groups
the config server |
Version | |
Data Directory | Specify the directory where the Each |
Log File | Specify the full path to the For example, specifying The |
Configure Each Shard in Your Cluster.
From the Member Configuration section, click
Shard Settings to open the shard configuration
options. Cloud Manager lists each shard in the cluster and the
mongod
processes associated to that shard.
Each shard process 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 Cloud Manager Automation deploys the replica set member. The menu only lists hosts under Cloud Manager Automation. For complete documentation on adding servers to Cloud 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 The |
Votes | |
Priority | |
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 |
To add additional shards to the cluster:
Click Add a Shard.
Under the Cluster Configuration section, set the following parameters for each
mongod
in the shard:Version
Data Directory
Log File
Configure Each Configuration Server in Your Cluster.
Cloud Manager displays a different heading for your configuration server settings depending on the MongoDB version you selected for your configuration servers.
- MongoDB 3.2 or Later:
From the Member Configuration section, click Config Server Replica Set Settings to open the CSRS configuration options. Each config server replica set member has the following options:
SettingDescriptionMemberSelect one of the following replica set member roles from the menu:
Default
A data-bearing member of the replica set that can become the primary and vote in elections.
A non-data bearing member of the replica set that can vote in elections. Corresponds to the
arbiterOnly
replica configuration option.A data-bearing member of the replica set that can vote in elections. Corresponds to the
hidden
replica configuration option.A data-bearing member of the replica set that can vote in elections. Corresponds to the
secondaryDelaySecs
andhidden
replica configuration options.
HostnameSelect from the menu the host to which Cloud Manager Automation deploys the replica set member. The menu only lists hosts under Cloud Manager Automation. For complete documentation on adding servers to Cloud Manager Automation, see Provision Servers for Automation.
This hostname can be a hostname, an FQDN, an IPv4 address, or an IPv6 address.
PortSpecify the IANA port number for the
mongod
process. This setting corresponds to thenet.port
configuration file option. Defaults to27017
.The
mongod
must have exclusive access to the specified port. If deploying multiplemongod
processes to a single host, you must select a unique unused port for each process.VotesPriorityDelaySpecify the number of seconds "behind" the primary member this member should "lag". This setting corresponds to the
secondaryDelaySecs
mongod
replica set configuration option.Build IndexesSpecify
true
to direct themongod
to build indexes. This setting corresponds to thebuildIndexes
mongod
replica set configuration option.TagsSpecify the tag or tags associated to the replica set. This setting corresponds to the
tags
mongod
replica set configuration option.For complete documentation on replica set tags, see Replica Set Tags
Add a Mongod- MongoDB 3.0 or Earlier
From the Member Configuration section, click Config Server Settings to open the configuration server options. Each configuration server has the following options:
SettingDescriptionHostnameSelect from the menu the host to which Cloud Manager Automation deploys the replica set member. The menu only lists hosts under Cloud Manager Automation. For complete documentation on adding servers to Cloud Manager Automation, see Provision Servers for Automation.
This hostname can be a hostname, an FQDN, an IPv4 address, or an IPv6 address.
PortSpecify the IANA port number for the
mongod
process. This setting corresponds to thenet.port
configuration file option. Defaults to27017
.The
mongod
must have exclusive access to the specified port. If deploying multiplemongod
processes to a single host, you must select a unique unused port for each process.
Configure Each mongos
in Your Cluster.
From the Member Configuration section, click
Mongos Settings to open the mongos
configuration options. Each mongos
process has the
following options:
Setting | Description |
---|---|
Hostname | Select from the menu the host to which Cloud Manager Automation deploys the
This hostname can be a hostname, an FQDN, an IPv4 address, or an IPv6 address. |
Port | Specify the IANA port
number for the The |
Add a Mongos | Click to add an additional |
Configure Each Replica Set in your Cluster.
The Replication Settings section contains the following configuration options for each replica set in the cluster:
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 WARNING: Forcing 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. To learn more, see Reconfigure a Replica Set with Unavailable Members in the MongoDB Server Manual. |