Multi-Cloud Replica Sets
Parent: MongoDB Atlas Multi-Cloud · Published reference · snapshot 2026-10-23 · skill mongodb-cohort-7cd1c9c93f1a-pending
↓ Facts as markdownall context files
Source-anchored research for Multi-Cloud Replica Sets. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Definitions
- Secondary read routing can exploit nearby replicas, but asynchronous replication means those reads can lag the primary. A nearby copy is not a guarantee of the freshest data. (high confidence) [source]
How it works
- For Atlas Core multi-cloud deployments, MongoDB documents that an application using a private connection to a replica set can access only nodes in the same cloud provider and region. To reach nodes in other providers, Atlas requires a VPN from the current provider to each remaining provider and an Atlas private endpoint for each. Atlas also describes a sharded alternative: applications connect through local private endpoints, and local mongos routes requests to a primary in another region. The MongoDB Server Discovery and Monitoring specification requires replica-set clients to discover and monitor the full set from a seed list of one or more members, and requires the member hostnames in the replica-set configuration to be reachable from the client. A Reddit commenter reports an AWS/GCP deployment that used cloud-specific mongos seed lists for its sharded topology and says replica-set clients still tried all members when given single-cloud seed hosts. Treat the forum account as a topology-specific report to validate against the exact deployment. (medium confidence) (verified as of 2026-10-24) [source]
Problems, failure modes and limitations
- A three-voter arrangement with two voters in provider A and one in provider B cannot retain a majority if A fails. One voter in each of three providers retains two of three votes after any one provider fails, assuming the survivors can communicate. These are deductions from the majority rule, not measured outage results. (high confidence) [source]
Comparisons and alternatives
- Atlas can place members of one cluster across AWS, Azure and Google Cloud; this distributes the replica set rather than creating a separately administered database per provider. (high confidence) (verified as of 2026-10-14) [source]
- VMware IT's May 2023 deployment explicitly chose a separate Atlas cluster instead of extending its on-premises replica set into AWS. Kafka connectors synchronized selected collections, and a messaging path returned writes to the on-premises database. This is an independent practitioner example of separate-cluster synchronization, not a native multi-cloud replica set. (low confidence) [source]
- Atlas documentation describes provider migration by adding a node in the destination cloud and letting Atlas replicate data to it. This uses replica-set replication rather than requiring an application-managed collection-copy pipeline. (low confidence) [source]
Facts and statements
- A replica set maintains one data set with a primary receiving writes and secondaries asynchronously applying its oplog. Placing members in different clouds does not create independent write primaries; at most one primary can confirm majority writes. (high confidence) [source]
- Atlas prioritizes electable nodes in the configured highest-priority provider/region. Read-only and analytics nodes provide workload placement but do not replace electable voters for automatic primary selection. (high confidence) [source]
- Geographic distance can increase replication lag and election time. Majority-write latency depends on where the required acknowledgements come from; cross-cloud acknowledgement is topology-dependent, not an unconditional property of every multi-cloud write. (high confidence) [source]
- MongoDB recommends a five-node, three-region 2+2+1 distribution to combine regional-outage resilience with less disruptive maintenance. Its cheaper 1+1+1 alternative can move the primary between regions during maintenance and produce latency spikes; neither recommendation is a universal failover-time guarantee. (high confidence) [source]
- Microsoft's Azure reference architecture distributes application compute and private endpoints across regions alongside Atlas nodes, with virtual-network peering for surviving-region connectivity. It demonstrates that database node distribution must be accompanied by resilient application connectivity; it is an Azure multi-region example, not proof of cross-provider failover. (high confidence) [source]
- The cached Atlas configuration page exposes multi-cloud and workload-isolation configuration for M10+ clusters and permits 3, 5 or 7 electable nodes across providers and regions. These product constraints were observed in the 2026-10-18 source snapshot, whose publication date is unspecified. (low confidence) (verified as of 2026-10-18) [source]
- Electable secondaries can replace a failed primary only while a voting majority remains available. Cross-cloud placement alone therefore does not guarantee continued writes after a provider outage: the surviving members must retain a majority. (high confidence) [source]
- Cross-cloud write latency depends on application-to-primary distance and the replication path needed for the requested acknowledgements. Majority writes wait for a majority of voting data-bearing members; geographic distribution does not by itself make writes local everywhere. (high confidence) [source]
- MongoDB's multi-cloud guidance identifies replication traffic charges and provider-specific key management, secrets, identity, networking, and observability integrations as added costs and operational complexity. (low confidence) [source]
- For a multi-cloud replica set accessed through private connectivity, Atlas documents access limited to nodes in the connecting cloud and region. Reaching all providers privately requires additional VPN and private endpoint configuration. The documented alternative is a sharded deployment whose local mongos routes operations to remote primaries. (low confidence) (verified as of 2026-10-14) [source]
Children
- Voting-majority placement across provider failure domains (frontier)
- Cross-cloud driver discovery and network reachability (frontier)
- Replica-set failover testing (frontier)
Frontier under this node: Cross-cloud driver discovery and network reachability, Replica-set failover testing, Voting-majority placement across provider failure domains