> For the complete MongoDB documentation index, see www.mongodb.com/docs/llms.txt # Configure High Availability and Workload Isolation **Tip:** On Atlas Core clusters, you can create multi-cloud MongoDB deployments in Atlas using any combination of cloud providers: AWS (Amazon Web Services), Azure (Microsoft Azure), and Google Cloud. Atlas Infinite clusters don't support multi-cloud clusters in public preview. On Atlas Core clusters, you can set the nodes in your cluster to use different: - **Cloud providers**: Deploy nodes on AWS (Amazon Web Services), Azure (Microsoft Azure), or Google Cloud. You can deploy all nodes in one cloud provider or deploy a multi-cloud cluster with nodes across different cloud providers. - **Geographic regions**: Deploy nodes in one or more cloud provider regions, and set which region Atlas prioritizes for primary eligibility. The regions can be in the same cloud provider or across different cloud providers. - **Workload purposes**: Deploy electable, read-only, analytics, and Search Nodes. On Atlas Infinite clusters in public preview, Atlas deploys all nodes in one region on AWS (Amazon Web Services). You can deploy read-only and analytics nodes to isolate workloads from your primary node. To learn more, see [Workload Isolation on Atlas Infinite clusters.](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-atlas-infinite-workload-isolation) To configure cloud provider, region, and workload isolation options for your Atlas Core cluster, see the following procedure: 1. In Atlas, go to the Clusters page for your project. If it's 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. In the sidebar, click Clusters under the Database heading. The [Clusters](https://cloud.mongodb.com/go?l=https%3A%2F%2Fcloud.mongodb.com%2Fv2%2F%3Cproject%3E%23%2Fclusters) page displays. 2. For the relevant cluster, click Edit configuration. 3. Click Edit additional configuration in the lower-right corner. 4. Expand Cloud Provider & Region, and toggle Multi-Cloud, Multi-Region & Workload Isolation (M10+ clusters) to On. ## Considerations The considerations that reference multiple regions, multiple cloud providers, or sharded clusters apply to Atlas Core clusters only. Atlas Infinite clusters don't support these configurations in public preview. To learn which workload isolation options apply to Atlas Infinite clusters, see [Workload Isolation on Atlas Infinite clusters.](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-atlas-infinite-workload-isolation) - Atlas does not guarantee that host names remain consistent with respect to node types during topology changes. **Example:** If you have a cluster named `foo123` containing an analytics node `foo123-shard-00-03-a1b2c.mongodb.net:27017`, Atlas does not guarantee that specific host name will continue to refer to an analytics node after a topology change, such as [scaling a cluster](https://www.mongodb.com/docs/atlas/scale-cluster.md#std-label-modify-cluster) to modify its number of nodes or regions. - In sharded clusters that use a [dedicated config server](https://www.mongodb.com/docs/atlas/cluster-additional-settings.md#std-label-config-server-types), Atlas distributes the three config server nodes based on the number of electable regions in the cluster. If the cluster has: - Only one electable region, Atlas deploys all three config nodes in that region. - Two electable regions, Atlas deploys two config nodes in the highest priority region and one config node in the second highest priority region. - Three or more electable regions, Atlas deploys one config node in each of the three highest priority regions. - Having a large number of regions or having nodes spread across long distances may lead to long election times or replication lag. - A cluster change that adds, removes, or modifies voting members will take longer, since Atlas adds, removes, or modifies [voting members](https://www.mongodb.com/docs/manual/core/replica-set-elections.md#std-label-replica-set-voting-members) one at a time on a [rolling basis.](https://www.mongodb.com/docs/atlas/reference/faq/deployment.md#std-label-high-availability) - Gen1 clusters can span regions and cloud service providers. Gen2 clusters do not offer cross-cloud support, but they can span multiple regions so long as all regions support Gen2 clusters for a given cloud provider. To learn more, see: - [AWS Gen2 Supported Regions](https://www.mongodb.com/docs/atlas/reference/amazon-aws.md#std-label-aws-reference-gen2-regions) - [GCP Gen2 Supported Regions](https://www.mongodb.com/docs/atlas/reference/google-gcp.md#std-label-gcp-reference-gen2-regions) Atlas limits the total number of nodes in other regions in one project to a total of 100, **not** including: - Google Cloud regions communicating with each other - Free clusters - Flex clusters Sharded clusters include additional nodes. The electable nodes on the dedicated Config Server Replica Set (CSRS) count towards the total number of allowable nodes. Each sharded cluster has an additional electable node per region as part of the dedicated CSRS. To learn more, see [Replica Set Config Servers.](https://www.mongodb.com/docs/manual/core/sharded-cluster-config-servers.md#std-label-replset-config-servers) The total number of nodes between any two regions must meet this constraint. **Example:** If an Atlas project has nodes in clusters spread across three regions: - 75 nodes in **Region A** - 10 nodes in **Region B** - 5 nodes in **Region C** You can only add 10 more nodes to **Region C** because: 1. If you exclude Region C, Region A + Region B = 85, \<= 100. 2. If you exclude Region B, Region A + Region C = 80, \<= 100. 3. If you exclude Region A, Region B + Region C = 15, \<= 100. 4. Each combination of regions with the added 10 nodes still meets the per-project constraint: - Region A + B = 85, \<= 100 - Region A + C = 90, \<= 100 - Region B + C = 25, \<= 100 You can't create a multi-region cluster in a project if it has one or more clusters spanning 100 or more nodes in other regions. Contact Atlas [support](https://www.mongodb.com/docs/manual/support/) for questions or assistance with raising this limit. - Atlas limits the number of nodes between any two regions in a project. To learn more, see [How many cross-region network permissions does Atlas support?.](https://www.mongodb.com/docs/atlas/reference/faq/networking.md#std-label-faq-cross-region) - Atlas provides built-in custom write concerns for multi-region clusters. Use these write concerns to ensure your write operations propagate to a desired number of regions, thereby ensuring data consistency across your regions. To learn more, see [Built-In Custom Write Concerns.](https://www.mongodb.com/docs/atlas/reference/replica-set-tags.md#std-label-built-in-custom-wc) - The number of availability zones, zones, or fault domains in a region has no effect on the number of MongoDB nodes Atlas can deploy. MongoDB Atlas clusters are always made of replica sets with a minimum of three MongoDB nodes. - If you use the [standard connection string format](https://www.mongodb.com/docs/manual/reference/connection-string-formats.md#std-label-connections-standard-connection-string-format) rather than the DNS (Domain Name System) seedlist format, removing an entire region from an existing cross-region cluster may result in a new connection string. To verify the correct connection string after deploying the changes: 1. In Atlas, go to the Clusters page for your project. If it's 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. In the sidebar, click Clusters under the Database heading. The [Clusters](https://cloud.mongodb.com/go?l=https%3A%2F%2Fcloud.mongodb.com%2Fv2%2F%3Cproject%3E%23%2Fclusters) page displays. 2. Click Connect. - If you plan on creating one or more VPC (Virtual Private Cloud) peering connections on your first `M10+` dedicated paid cluster for the selected region or regions, first review the documentation on [VPC Peering Connections.](https://www.mongodb.com/docs/atlas/security-vpc-peering.md#std-label-vpc-peering) - Atlas may use different cloud provider hardware for `M10` and `M20` clusters in specific [GCP](https://www.mongodb.com/docs/atlas/reference/google-gcp.md#std-label-google-gcp) regions. As a result, certain [GCP](https://www.mongodb.com/docs/atlas/reference/google-gcp.md#std-label-google-gcp) region combinations may not be supported by multi-region `M10` and `M20` clusters. ## Electable Nodes for High Availability If you add regions with electable nodes, you: - increase data availability - reduce the impact of data center outages On Atlas Core clusters, you can deploy nodes to multiple regions within the same cloud provider or across multiple cloud providers. Atlas Infinite clusters don't support multi-region or multi-cloud clusters in public preview. Atlas sets the node in the first row of the Electable nodes table as the Highest Priority region. Atlas prioritizes nodes in this region for [primary](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-primary) eligibility. Other nodes rank in the order that they appear. For more information, see [Member Priority.](https://www.mongodb.com/docs/manual/core/replica-set-elections.md#std-label-rs-election-priority) **Note:** This feature is not applicable to Atlas Infinite. To learn more about Atlas Infinite capabilities and behavior, see [MongoDB Atlas Infinite: Overview.](https://www.mongodb.com/docs/atlas/infinite/atlas-infinite-landing.md#std-label-atlas-infinite-edition) Each electable node can: - Participate in replica set elections - Become the [primary](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-primary) while the majority of nodes in the replica set remain available **Important:** When Global Writes are enabled, Global Clusters do not support dedicated search nodes. ### Add Electable Nodes You can add electable nodes in one cloud provider and region from the Electable nodes for high availability section. To add an electable node: 1. Click Add a provider/region. 2. Select the cloud provider from the Provider dropdown. 3. Select the region from the Region dropdown. When you change the Provider option, the Region changes to a blank option. If you don't select a region, Atlas displays an error when you click Create Cluster. 4. Specify the desired number of Nodes for the provider and region. The total number of electable nodes across all providers and regions in the cluster must equal **3**, **5**, or **7**. Atlas considers regions marked with a as recommended. These regions provide higher availability compared to other regions. To learn more, see: - [AWS Recommended Regions](https://www.mongodb.com/docs/atlas/reference/amazon-aws.md#std-label-amazon-aws-availability-zones) - [GCP Recommended Regions](https://www.mongodb.com/docs/atlas/reference/google-gcp.md#std-label-google-gcp-availability-zones) - [Azure Recommended Regions](https://www.mongodb.com/docs/atlas/reference/microsoft-azure.md#std-label-microsoft-azure-availability-zones) ### Remove Electable Nodes To remove a node from a region, click the icon to the right side of that region. You cannot remove a node in the Highest Priority region. To learn more, see [Multi-Region Cluster Backups.](https://www.mongodb.com/docs/atlas/backup/cloud-backup/dedicated-cluster-backup.md#std-label-multi-region-cloud-backup) **Warning:** When you migrate electable nodes from one region to another, Atlas immediately provisions new nodes and deprovisions old ones. Atlas does not wait for MongoDB Search indexes to finish building in the new region before deprovisioning old nodes, so you might experience MongoDB Search downtime during the creation of new indexes. To avoid downtime, complete the migration in two steps: 1. Add the new region and wait for all nodes to fully provision. If you use Search Nodes, ensure that MongoDB Search finishes building all indexes before proceeding. 2. Remove the old region. To further reduce downtime risk, use [read preference tags](https://www.mongodb.com/docs/manual/core/read-preference-tags.md#std-label-replica-set-read-preference-tag-sets) to route reads to regions where your indexes are ready. ### Change Electable Nodes to Read-Only Nodes You can change an electable node to a [read-only node](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-deploy-read-only-replicas) by adding a read-only node and removing an electable node at the same time. To learn more, see [Change Workload Purpose of Nodes.](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-change-workload-purpose) ### Improve the Availability of a Cluster To improve the redundancy and availability of a cluster, increase the number of electable nodes in that region. Every Atlas cluster has a Highest Priority region. If your cluster spans multiple regions, you can select which cloud provider region should be the Highest Priority. To prevent loss of availability and performance, consider the following scenarios: | Point of Failure | How to Prevent this Point of Failure | | --- | --- | | Cloud Provider | Minimum of one node set in all three cloud providers. More than one node per region. | | Region | Minimum of one node set in three or more different regions. More than one node per region. | | Node | Three or more electable nodes in a Recommended region *or*; Three or more electable nodes across two or more regions. | ### Change the Highest Priority Provider or Region If you change the Highest Priority provider or region in an active multi-region cluster, Atlas selects a new [primary](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-primary) node in the provider and region that you specify (assuming that the number of nodes in each provider and region remains the same and nothing else is modified). If Cloud Backup is enabled on your cluster when you change the primary region, Atlas takes an on-demand snapshot and stores it in the new primary region without waiting for the next scheduled snapshot. If the new primary region was previously a secondary backup region for [snapshot copy distribution](https://www.mongodb.com/docs/atlas/backup/cloud-backup/snapshot-distribution.md#std-label-snapshot-distribution), Atlas automatically updates your [backup policy](https://www.mongodb.com/docs/atlas/backup/cloud-backup/configure-backup-policy.md#std-label-configure-backup-policy) to distribute snapshot copies from the new primary region to the original primary region and other secondary regions. **Example:** If you have an active 5-node cluster with the following configuration: | Nodes | Provider | Region | Priority | | --- | --- | --- | --- | | 3 | AWS (Amazon Web Services) | **us-east-1** | Highest | | 2 | Google Cloud | **us-west3** | | To make the Google Cloud **us-west3** nodes the Highest Priority, drag its row to the top of your cluster's Electable nodes list. After this change, Atlas elects a new **PRIMARY** in **us-west3**. Atlas doesn't start an initial sync or re-provision hosts when changing this configuration. **Important:** Certain circumstances may delay an election of a new [primary.](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-primary) For example, a sharded cluster with heavy workloads on its [primary](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-primary) shard may delay the election. This results in not having all primary nodes in the same region temporarily. To minimize these risks, avoid modifying your primary region during periods of heavy workload. ## Read-Only Nodes for Optimal Local Reads Use read-only nodes to optimize local reads in the nodes' respective service areas. ### Add Read-Only Nodes You can add read-only nodes from the Read-Only Nodes for Optimal Local Reads section. To add a read-only node in one cloud provider and region: 1. Click Add a provider/region. 2. Select the cloud provider from the Provider dropdown. 3. Select the region from the Region dropdown. When you change the Provider option, the Region changes to a blank option. If you don't select a region, Atlas displays an error when you click Create Cluster. 4. Specify the desired number of Nodes for the provider and region. Atlas considers regions marked with a as recommended. These regions provide higher availability compared to other regions. Read-only nodes don't provide high availability because they don't participate in [elections](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-election). They can't become the [primary](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-primary) for their cluster. To direct queries to read-only nodes, use [pre-defined replica set tags.](https://www.mongodb.com/docs/atlas/reference/replica-set-tags.md#std-label-replica-set-tags) ### Remove Read-Only Nodes To remove all read-only nodes in one cloud provider and region, click the icon to the right of that cloud provider and region. ### Change Workload Purpose of Nodes You can change a node's workload purpose by adding and removing nodes at the same time. **Note:** You must add and remove the node within the same configuration change to reuse a node. If you remove the node, save the change, then add the node, Atlas provisions a new node instead. For example, to change a read-only node to an [electable node:](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-deploy-across-multiple-cloud-providers) 1. [Add an electable node.](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-add-electable-node) 2. [Remove a read-only node.](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-remove-read-only-node) 3. Click Review Changes. 4. Click Apply Changes. ## Analytics Nodes for Workload Isolation Use [analytics nodes](https://www.mongodb.com/docs/atlas/reference/faq/deployment.md#std-label-analytics-nodes-overview) to isolate queries which you do not wish to contend with your operational workload. Analytics nodes help handle data analysis operations, such as reporting queries from BI Connector for Atlas. To direct queries to analytics nodes, use [pre-defined replica set tags.](https://www.mongodb.com/docs/atlas/reference/replica-set-tags.md#std-label-replica-set-tags) **Note:** You can deploy analytics nodes for dedicated (`M10` or higher) clusters only. You can't add analytics nodes on Free clusters or Flex clusters. For Atlas Infinite clusters in public preview, specify the number of Nodes. Atlas deploys them in the same region as the Atlas Infinite cluster. For Atlas Core clusters, click Add a region to select a region, then specify the number of Nodes for that region. **Note:** The [readPreference](https://www.mongodb.com/docs/manual/reference/connection-string/#mongodb-urioption-urioption.readPreference) and [readPreferenceTags](https://www.mongodb.com/docs/manual/reference/connection-string/#mongodb-urioption-urioption.readPreferenceTags) connection string options are unavailable for the `mongo` shell. To learn more, see [cursor.readPref()](https://www.mongodb.com/docs/manual/reference/method/cursor.readPref/#mongodb-method-cursor.readPref) and [Mongo.setReadPref()](https://www.mongodb.com/docs/manual/reference/method/Mongo.setReadPref/#mongodb-method-Mongo.setReadPref) instead. ### Add Analytics Nodes You can add analytics nodes from the Analytics nodes for workload isolation section. To add analytics nodes in one cloud provider and region: 1. Click Add a provider/region. 2. Select the cloud provider from the Provider dropdown. 3. Select the region from the Region dropdown. When you change the Provider option, the Region changes to a blank option. If you don't select a region, Atlas displays an error when you click Create Cluster. 4. Specify the desired number of Nodes for the provider and region. Atlas considers regions marked with a as recommended. These regions provide higher availability compared to other regions. Analytics nodes don't provide high availability because they don't participate in [elections](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-election). They can't become the [primary](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-primary) for their cluster. ### Select a Cluster Tier for Your Analytics Nodes Your workloads can vary greatly between analytics and operational nodes. To help manage this issue, for `M10+` clusters, you can [select a cluster tier](https://www.mongodb.com/docs/atlas/manage-clusters.md#std-label-create-cluster-instance) appropriately sized for your analytics workload. You can select a cluster tier for your analytics nodes that's larger or smaller than the cluster tier selected for your electable and read-only nodes (operational nodes). This functionality helps to ensure that you get the performance required for your transactional and analytical queries without over or under provisioning your entire cluster for your analytical workload. The following considerations apply to the Analytics Tier tab and analytic nodes: **Important:** If you select a cluster tier on the Analytics Tier tab significantly below the cluster tier selected on the Base Tier tab, [replication lag](https://www.mongodb.com/docs/manual/tutorial/troubleshoot-replica-sets/#check-the-replication-lag) might result. The analytics node might fall off the [oplog](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-oplog) altogether. - On Atlas Core clusters, if you select a General cluster tier on the Analytics Tier tab and a Low-CPU cluster tier on the Base Tier tab, disk auto-scaling isn't supported for the cluster. Disk auto-scaling also isn't supported if you select a General cluster tier on the Base Tier tab and a Low-CPU cluster tier on the Analytics Tier tab. - On Atlas Core clusters, disk size and IOPS must remain the same across all node types. - On Atlas Core clusters, storage size must match between the Base Tier tab and Analytics Tier tab. You can set the storage size on the Base Tier tab. Atlas expands the storage of an Atlas Infinite cluster as your data grows, so you don't set a storage size. - On Atlas Core clusters, if you want to select the Local NVME SSD class on the Base Tier tab, the Analytics Tier tab must have the same tier level selected. Atlas Infinite clusters don't support locally attached NVMe (non-volatile memory express) SSD (Solid State Disk) storage in public preview. - On Atlas Core clusters, if a cluster tier appears grayed out, the cluster tier isn't compatible with the disk size of the cluster or the Local NVME SSD class. - A cluster tier selected on the Analytics Tier tab is priced the same as a cluster tier selected on the Base Tier tab. However, when an Analytics Tier is higher or lower than the Base Tier, the price adjusts accordingly on a prorated per-node basis. The pricing appears in the Atlas UI when you create or edit a cluster. To learn more, see, [Manage Billing.](https://www.mongodb.com/docs/atlas/billing.md#std-label-atlas-billing) After you [add your analytics nodes](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-add-analytics-node), you can [select a cluster tier](https://www.mongodb.com/docs/atlas/manage-clusters.md#std-label-create-cluster-instance) appropriately sized for your analytics workload. 1. In the Cluster Tier section, click the Analytics Tier tab. 2. Select the Cluster Tier. ### Remove Analytics Nodes To remove all analytics nodes in one cloud provider and region, click the icon to the right of that cloud provider and region. ## Search Nodes for Workload Isolation You can set the nodes in your cluster to run only the MongoDB Search `mongot` process. When you run the MongoDB Search `mongot` process separately, you improve the availability and workload balancing of the `mongot` process. To learn more, see [Node Architecture.](https://www.mongodb.com/docs/search/deployment/deployment-options.md#std-label-what-is-search-node) **Important:** Dedicated Search Nodes are not supported on Atlas Infinite clusters clusters during public preview. For the features supported in public preview, see [Public Preview Availability.](https://www.mongodb.com/docs/atlas/infinite/atlas-infinite-landing.md#std-label-atlas-infinite-availability) ### Considerations On `M10` or higher Atlas clusters running MongoDB v6.0 and higher, you can configure Search Nodes separately from the database nodes. Review the following before deploying MongoDB Search nodes separately. #### Cluster Tier You can deploy Search Nodes for dedicated (`M10` or higher) clusters only. You can't add Search Nodes on free (`M0`) tier clusters or Flex clusters. You can use the Atlas UI and the Atlas Administration API to provision Search Nodes for new and existing clusters on AWS (Amazon Web Services), Google Cloud, or Azure (Microsoft Azure). #### Cloud Provider You can host the Search Nodes on any cloud provider. You can't deploy Search Nodes separately for [global clusters.](https://www.mongodb.com/docs/atlas/global-clusters.md#std-label-global-clusters) #### Cloud Provider Regions Atlas deploys the Search Nodes in the same AWS (Amazon Web Services), Google Cloud, or Azure (Microsoft Azure) regions as your electable, read-only, and analytics nodes. Atlas supports deploying Search Nodes separately for workload isolation in only specific AWS (Amazon Web Services), Google Cloud, and Azure (Microsoft Azure) regions. The following Atlas UI behavior applies: - If you select any of the following AWS (Amazon Web Services) or Azure (Microsoft Azure) regions for your cluster nodes first, Atlas disables the Search nodes for workload isolation toggle. - If you enable Search nodes for workload isolation first, Atlas disables the following in the dropdown for regions under Electable nodes for high availability. Atlas doesn't support the following AWS (Amazon Web Services), Google Cloud, and Azure (Microsoft Azure) regions for search nodes. ### AWS | Region Name | AWS Region | | --- | --- | | Bahrain | `me-south-1` | | Melbourne | `ap-south-4` | To deploy Search Nodes separately, you must select a supported AWS (Amazon Web Services), Google Cloud, or Azure (Microsoft Azure) region from the Electable nodes for high availability dropdown. To learn more about the supported regions, see [Regions for Dedicated Search Nodes](https://www.mongodb.com/docs/atlas/cloud-providers-regions.md#std-label-create-cluster-cloud-provider-region). Atlas automatically uses the same region for read-only and analytics nodes on your cluster. After deployment, you can't change the cloud provider or cloud provider region for your Atlas cluster. ##### Multi-Region and Multi-Cloud Clusters Atlas supports deploying Search Nodes across multiple regions and cloud providers. When deploying Search Nodes for multi-region or multi-cloud clusters, consider the following: - All nodes across regions have the same [search tier.](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-select-tiers-for-search-nodes) - You can deploy a minimum of 2 and maximum of 32 search nodes per region per shard. - If you use the [Atlas Administration API](https://www.mongodb.com/docs/atlas/api/atlas-admin-api.md#std-label-atlas-admin-api) to add a new region to existing Search Nodes, Atlas deploys the same number of Search Nodes in the new region. However, if the new region does not support the current search tier, the request fails. ##### Sharded Clusters with Search Nodes Atlas requires a minimum of two Search Nodes for every region in a Atlas cluster. This requirement applies to all cluster types, including sharded clusters. When deploying sharded clusters that rely heavily on MongoDB Search or MongoDB Vector Search, understanding the Search Node topology requirements is crucial for ensuring high availability and optimal performance. The following topology requirements apply specifically to sharded clusters with Search Nodes: - **Multi-Region Deployments**: If your sharded cluster spans multiple regions, Atlas automatically deploys the specified number of Search Nodes in each region that contains database nodes. - **Minimum Number of Nodes**: Each region with database nodes must have at least two Search Nodes to maintain availability during maintenance operations or node failures. #### Search Tier You can select a search tier for your Search Nodes in the Search Tier tab. By default, Atlas deploys Search Nodes on `S20`. You can select a higher tier for faster queries and more complex aggregations, or a lower tier for smaller workloads. If you want to downsize to a lower tier, the search tier must accommodate any existing search indexes, along with additional disk space for bumper files and logs. `S10` is the lowest search tier and is right-sized for small workloads with index footprints under 10 GB, such as those on `M10` to `M30` clusters. Because `S10` provides less storage and fewer vCPUs than higher tiers, it isn't suited to large indexes or query-intensive workloads. For those workloads, select `S20` or higher. For Search Nodes deployed on AWS (Amazon Web Services), Atlas provides different search tiers in different regions. If the search tier that you selected is not available for your region, Atlas automatically deploys the search nodes in the next higher tier that is available in that region. To learn more, see [AWS Search Tiers.](https://www.mongodb.com/docs/atlas/reference/amazon-aws.md#std-label-amazon-aws-search-tiers) To learn more about search tiers for Search Nodes deployed on Google Cloud or Azure (Microsoft Azure), see: - [GCP Search Tiers](https://www.mongodb.com/docs/atlas/reference/google-gcp.md#std-label-google-gcp-search-tiers) - [Azure Search Tiers](https://www.mongodb.com/docs/atlas/reference/microsoft-azure.md#std-label-microsoft-azure-search-tiers) #### Enable Encryption at Rest By default, MongoDB and [search processes](https://www.mongodb.com/docs/search/query/query-ref.md#std-label-about-mongot) run on the same nodes. With this architecture, customer-managed encryption applies to your database data, but it does not apply to search indexes. When you enable [dedicated Search Nodes](https://www.mongodb.com/docs/search/deployment/deployment-options.md#std-label-what-is-search-node), search processes run on separate nodes. This allows you to enable [Search Node Data Encryption](https://www.mongodb.com/docs/atlas/security-kms-encryption.md#std-label-enable-search-node-encryption), so you can encrypt both database data and search indexes with the same customer-managed keys for comprehensive encryption coverage. Dedicated Search Nodes are not supported on Atlas Infinite clusters clusters during public preview. **Note:** Database nodes and Search Nodes use different encryption methods with the same customer-managed keys. Database nodes use the [WiredTiger Encrypted Storage Engine](https://www.mongodb.com/docs/manual/core/security-encryption-at-rest/#encrypted-storage-engine), while Search Nodes use encryption at the disk level. To learn more, see [Enable Customer Key Management for Search Nodes.](https://www.mongodb.com/docs/atlas/security-kms-encryption.md#std-label-enable-search-node-encryption) **Important:** This feature is available across KMS (Key Management Service) providers. #### Activity Feed Atlas logs search node create, update, and delete operations in the Project Activity Feed. Each entry identifies the user who performed the action. To view these events, see [View Activity Feed.](https://www.mongodb.com/docs/atlas/tutorial/activity-feed.md#std-label-activity-feed) ### Add Search Nodes To deploy Search Nodes, you must have [`Project Owner`](https://www.mongodb.com/docs/atlas/reference/user-roles.md#mongodb-authrole-Project-Owner) access to the project. To configure separate Search Nodes on your Atlas cluster, do the following: 1. Toggle Multi-Cloud, Multi-Region & Workload Isolation (M10+ clusters) to On. 2. Toggle Search nodes for workload isolation to On. 3. Specify the number of nodes to deploy. You can specify between a minimum of 2 and a maximum of 32 nodes. After deployment, you can modify the cluster to add and remove any additional Search Nodes. **Note:** For multi-region clusters, Atlas deploys the specified number of nodes in each region. To learn more, see [Multi-Region and Multi-Cloud Clusters.](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-multi-region-search-nodes) 4. Expand Cluster Tier to select a tier for your search nodes in the Search Tiers tab. To learn more about the different tiers for your Search Nodes, see [Search Tier.](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-select-tiers-for-search-nodes) To create a search node for a cluster using the Atlas CLI, run the following command: ```sh atlas clusters search nodes create [options] ``` To learn more about the command syntax and parameters, see the Atlas CLI documentation for [atlas clusters search nodes create.](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-clusters-search-nodes-create/) **Note:** You can add Search Nodes to existing Atlas cluster only if you currently don't have any and have never created MongoDB Search indexes on your cluster. To configure separate Search Nodes on your Atlas cluster, send a `POST` request to the [MongoDB Search](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/group/endpoint-atlas-search) resource `/deployment` [endpoint](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/operation/operation-creategroupclustersearchdeployment). You must specify the number of nodes and the [instance size](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-select-tiers-for-search-nodes). You can deploy between a minimum of 2 and a maximum of 32 nodes. To learn more, see [Create Search Nodes.](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/operation/operation-creategroupclustersearchdeployment) When you add Search Nodes to a cluster that doesn't have any search nodes, the existing `mongot` processes running alongside `mongod` tail writes to the database that happen after MongoDB Search completed the initial sync and the `mongot` processes on the new dedicated search nodes perform an initial sync on the required collections. This results in dual reads during the migration process. ### Remove Search Nodes #### Remove Some Search Nodes To remove some Search Nodes, adjust the Number of Search Nodes setting under Search nodes for workload isolation. You can deploy between 2 and 32 Search Nodes per region per shard on your cluster. #### Remove All Search Nodes **Important:** If you remove all Search Nodes, you lose Search Node encryption with [customer-managed keys](https://www.mongodb.com/docs/atlas/security-kms-encryption.md#std-label-enable-search-node-encryption). Your data will still use Atlas's default encryption, but your search workloads and indexes will no longer be encrypted with your customer-managed keys. To remove all Search Nodes on your Atlas cluster, do the following: 1. Toggle Search nodes for workload isolation to Off. You can now select any region from the available cloud providers. 2. Click Remove to confirm in the Are you sure you want to remove Search Nodes? modal. 3. Click Review Changes. 4. Click the checkbox to confirm that you understand and agree to the considerations for deleting a cluster with Search Nodes. There will be a brief interruption in processing your search query results. 5. Click Apply Changes. **Important:** If you remove all Search Nodes, you lose Search Node encryption with [customer-managed keys](https://www.mongodb.com/docs/atlas/security-kms-encryption.md#std-label-enable-search-node-encryption). Your data will still use Atlas's default encryption, but your search workloads and indexes will no longer be encrypted with your customer-managed keys. To delete a search node for a cluster using the Atlas CLI, run the following command: ```sh atlas clusters search nodes delete [options] ``` To learn more about the command syntax and parameters, see the Atlas CLI documentation for [atlas clusters search nodes delete.](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-clusters-search-nodes-delete/) #### Remove Some Search Nodes To add or remove Search Nodes or modify search tier on your Atlas cluster, send a `PATCH` request to the [MongoDB Search](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/group/endpoint-atlas-search) resource `/deployment` [Update Search Nodes](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/operation/operation-updateatlassearchdeployment) endpoint. You can specify the following: - The number of nodes to remove. If omitted, Atlas doesn't change the current number of deployed nodes. - The [instance size](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-select-tiers-for-search-nodes) to use to switch to a different search tier. If omitted, Atlas doesn't modify the current search tier for the deployed nodes. To learn more, see [Update Search Nodes.](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/operation/operation-updateatlassearchdeployment) #### Remove All Search Nodes **Important:** If you remove all Search Nodes, you lose Search Node encryption with [customer-managed keys](https://www.mongodb.com/docs/atlas/security-kms-encryption.md#std-label-enable-search-node-encryption). Your data will still use Atlas's default encryption, but your search workloads and indexes will no longer be encrypted with your customer-managed keys. To remove all Search Nodes on your Atlas cluster, send a `DELETE` request to the [MongoDB Search](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/group/endpoint-atlas-search) resource `/deployment` [endpoint](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/operation/operation-deleteatlassearchdeployment). To learn more, see [Delete Search Nodes.](https://www.mongodb.com/docs/api/doc/atlas-admin-api-v2/operation/operation-deleteatlassearchdeployment) If you delete all existing Search Nodes on your cluster, there will be an interruption in processing your search query results while Atlas migrates from `mongot` processes running separately on dedicated Search Nodes to `mongot` processes running alongside `mongod`. You can't run queries while indexes are building on the node that hosts both the `mongot` and `mongod` processes, and you will experience query downtime. ## Workload Isolation on Atlas Infinite clusters During public preview, Atlas Infinite clusters support the following workload isolation options: - [Read-only nodes](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-deploy-read-only-replicas) - [Analytics nodes](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-deploy-analytics-nodes) - [Cluster tier for your analytics nodes](https://www.mongodb.com/docs/atlas/cluster-config/multi-cloud-distribution.md#std-label-select-analytics-nodes-tier) To add these nodes to an Atlas Infinite cluster, specify the number of Nodes for each node type. Atlas deploys the nodes in the same region as the Atlas Infinite cluster, so you don't select a cloud provider or region for them. To learn which regions Atlas Infinite clusters support, see the Atlas Infinite Support column in the [Amazon Web Services (AWS) regions table.](https://www.mongodb.com/docs/atlas/reference/amazon-aws.md#std-label-atlas-infinite-aws-regions) ### Limitations For the full list of features that Atlas Infinite supports in public preview, see [Public Preview Availability](https://www.mongodb.com/docs/atlas/infinite/atlas-infinite-landing.md#std-label-atlas-infinite-availability). The following limitations apply to workload isolation: - Atlas Infinite clusters don't support multi-region clusters. - Atlas Infinite clusters don't support multi-cloud clusters. - Atlas Infinite clusters don't support adding additional electable nodes. - Atlas Infinite clusters don't support Search Nodes. ## Connections to Multi-Cloud Deployments **Note:** This feature is not applicable to Atlas Infinite. To learn more about Atlas Infinite capabilities and behavior, see [MongoDB Atlas Infinite: Overview.](https://www.mongodb.com/docs/atlas/infinite/atlas-infinite-landing.md#std-label-atlas-infinite-edition) If you're connecting to replica sets hosted in a multi-cloud deployment through a [private connection](https://www.mongodb.com/docs/atlas/reference/faq/connection-changes.md#std-label-conn-string-options), you can access only the nodes in the same cloud provider and the same region that you're connecting from. This cloud provider might not have the [primary](https://www.mongodb.com/docs/manual/reference/glossary.md#std-term-primary) node in its region. When this happens, you must specify the [secondary read preference](https://www.mongodb.com/docs/manual/core/read-preference/) mode in the connection string to access the deployment. If you need access to all nodes for your multi-cloud deployment from your current provider through a private connection, you must: - Configure a VPN in the current provider to each of the remaining providers. - Configure a [private endpoint](https://www.mongodb.com/docs/atlas/security-configure-private-endpoints.md#std-label-private-endpoint) to Atlas for each of the remaining providers. As an alternative, we suggest creating sharded clusters for multi-cloud deployments accessed through a [private endpoint](https://www.mongodb.com/docs/atlas/security-configure-private-endpoints.md#std-label-private-endpoint). When you deploy a sharded cluster, whether single shard or multiple shards, you can connect to the cluster through the local private endpoints and perform read and write operations. You are not required to specify the secondary read preference mode, even if the cluster primary node(s) are located in a different region. The `mongos` in the cloud provider region you connect to will route the request to the primary node in a different region if needed. To learn more, see [deploying a sharded cluster.](https://www.mongodb.com/docs/atlas/cluster-additional-settings.md#std-label-create-cluster-sharding)