对于 AI 代理:可在 https://www.mongodb.com/zh-cn/docs/llms.txt 获取文档索引—通过在任何 URL 路径后添加 .md 可获取所有页面的 Markdown 版本。
Docs 菜单

Atlas 高可用性指导

高可用性是指您的应用程序在基础设施服务中断、系统维护和其他干扰期间,确保持续操作并最大限度地减少停机时间的能力。MongoDB 的默认部署架构专为高可用性而设计,具有内置的数据冗余和自动故障转移功能。

高可用性 与 灾难恢复 不同。高可用性可防止节点、区域、地区或云提供商服务中断等基础设施故障,通过自动故障转移,可在故障发生的精确时刻进行恢复,且不会丢失数据(RPO = 0),并在几秒内完成 RTO。灾难恢复可以防止数据完整性问题,例如损坏或意外删除,这些问题需要从备份恢复。要了解有关灾难恢复的更多信息,请参阅 Atlas 灾难恢复指导。

本页描述了您可以选择的其他配置选项和部署架构增强,以防止服务中断并支持针对可用区、区域和云提供商服务中断的强大故障转移机制。

MongoDB's default deployment architecture is designed for redundancy. Atlas deploys each cluster as a replica set with a minimum of three database instances (also called nodes or replica set members), distributed across separate availability zones within your selected cloud provider regions. Applications write data to the replica set's primary node, and then Atlas replicates and stores that data across all nodes within your cluster. To control the durability of your data storage, you can adjust the write concern of your application code to complete the write only once a certain number of secondaries have committed the write. The default behavior is for data to be persisted on a majority of electable nodes before confirming the action.

下图表示默认三节点副本集的复制工作原理:

图像显示三节点副本集中的复制过程。
点击放大

In the event that a primary node in a replica set becomes unavailable due to an infrastructure outage, scheduled maintenance, or any other disruption, Atlas clusters self-heal by promoting an existing secondary node to the role of primary node in a replica set election. This failover process is fully automatic and recovers to the exact moment of failure with no data loss (RPO = 0) in seconds. Operations that were in flight at the time of the failure are retried after the failure if retryable writes are enabled. After a replica set election, Atlas restores or replaces the failing member to ensure that the cluster is returned to its target configuration as soon as possible. The MongoDB client driver also automatically switches all client connections during and after the failure.

下图表示副本集选举过程:

图像显示三节点副本集中自我修复主节点的选举过程。
点击放大

为了提高最关键应用程序的可用性,您可以通过添加节点、区域或云提供商来扩展部署,以分别抵御区、区域或提供商的服务中断。要了解更多信息,请参阅下面的扩展您的部署范式以实现容错建议。

以下建议描述了您可以使用的其他配置选项和部署架构增强,以提高部署的可用性。

您可以在“专用”、“灵活”或“免费”部署类型下提供的范围集群层中进行选择。MongoDB Atlas中的集群层指定了集群中每个节点可用的资源(内存、存储、vCPU 和 IOPS)。扩展到更高层级可提高集群处理流量峰值的能力,并通过更快地响应高工作负载来提高系统可靠性。要确定适合您的应用程序大小的推荐集群层,请参阅《Atlas集群大小指南》。

Atlas also supports auto-scaling to allow the cluster to automatically adjust to spikes in demand. Atlas uses both reactive auto-scaling, which triggers based on current resource usage, and predictive auto-scaling, which proactively scales up eligible clusters before forecasted cyclical demand spikes occur. Automating scaling actions reduces the risk of an outage due to resource constraints. To learn more, see Guidance for Atlas Automated Infrastructure Provisioning.

An Atlas deployment's fault tolerance is the number of replica set members that can become unavailable while your deployment still remains operational. In the event of an availability zone, region, or cloud provider outage, Atlas clusters self-heal by promoting an existing secondary node to the role of primary node in a replica set election. A majority of the voting nodes in a replica set must be operational in order to run a replica set election when a primary node experiences an outage.

为确保副本集在部分区域服务中断时能够选举出主节点,您应将集群部署到至少有三个可用区的区域。可用区是单个云提供商区域内独立的数据中心组,每个数据中心都有自己的电力、冷却和网络基础设施。当您选择的云提供商区域支持可用区时,Atlas 会自动将您的集群分布在这些可用区中,以便在某个可用区发生服务中断时,集群中的其他节点仍然支持区域服务。大多数 Atlas 支持的云提供商区域至少有三个可用区。这些区域在 Atlas 用户界面中标记有星形图标。

每个云提供商都在可用区内提供默认数据冗余:

  • AWS 将数据存储在 AWS 区域中跨越至少三个可用区的多个设备上。

  • Microsoft Azure使用本地冗余存储(LRS),可在所选区域的单个数据中心内将数据复制三份。

  • Google Cloud 将数据分布在该区域的多个区域中。

For more information about recommended regions, see Cloud Providers and Regions.

为了进一步提高您最关键的应用程序的容错能力,您可以通过添加节点、区域或云提供商来扩展部署,以分别应对可用区、区域或提供商的服务中断。您可以将节点数增加到任意奇数,可选举节点数最多为 7 个,节点总数最多为 50 个。您还可以将集群部署到多个区域,以增强更大地理区域的可用性,并在发生全区域服务中断导致主区域内所有可用区禁用的情况下启用自动故障转移。同样的模式也适用于将您的集群部署到多个云提供商,以应对整个云提供商的服务中断。

有关如何选择能够平衡高可用性、低延迟、合规性和费用需求的部署的指导,请参阅我们的 Atlas 部署范式文档。

下表比较了不同部署范例的 RTO 和 RPO 特征。在 majority写关注(write concern)下,所有这些方法都可以在几秒钟内实现 RPO = 0(无数据丢失)和 RTO。需要在部署复杂性和集群费用进行权衡。

部署范例
涵盖的故障场景
典型 RTO
RPO(多数写关注(write concern))
相对复杂性
相对集群费用

单区域部署(1地区中的 3 个节点)

单个区域内的节点或可用区故障

秒(自动故障转移)

0(无数据丢失)

低

$

多区域、单云

一个地理区域内的可用区或区域服务中断

秒(自动故障转移)

0(无数据丢失)

中型

$$

多区域、多地理位置

跨多个地区的区域或地区服务中断

秒(自动故障转移)

0(无数据丢失)

中–高

$$–$$$

多云(2–3 提供商)

影响一个提供商的云提供商或多区域服务中断

秒(自动故障转移)

0(无数据丢失)

高

$$$

您可以启用终止保护,以确保集群不会被意外终止,并且不需要停机即可从备份恢复。要删除已启用终止保护的集群,必须先禁用终止保护。默认情况下,Atlas 会禁用所有集群的终止保护。

在使用 Terraform 等 IaC 工具时,终止保护尤为重要,以确保重新部署不会预配新的基础设施。

We strongly recommend that you simulate various scenarios that require automatic node failovers to measure your preparedness for such events before you deploy an application to production. With Atlas, you can test primary node failover for a replica set and simulate regional outages for a multi-region deployment.

MongoDB allows you to specify the level of acknowledgment requested for write operations by using write concern. Atlas has a default write concern of majority, meaning that data must be replicated across more than half of the nodes in your cluster before Atlas reports success. Using majority instead of a definite number value like 2 allows Atlas to automatically adjust to requiring replication across fewer nodes if you experience a temporary node outage, allowing writes to continue after automatic failover. This also provides a consistent setting across all environments, so your connection string remains the same whether you have three nodes in a test environment or a larger number of nodes in production.

Atlas supports retryable read and retryable write operations. When enabled, Atlas retries read and write operations once as a safeguard against intermittent network outages and replica set elections in which the application temporarily cannot find a healthy primary node. Retryable writes require an acknowledged write concern, meaning your write concern cannot be {w: 0}.

To avoid resource capacity issues, we recommend that you monitor resource utilization and hold regular capacity planning sessions. MongoDB's Professional Services offers these sessions. See our Resource Capacity Disaster Recovery Plan for our recommendations on how to recover from resource capacity issues.

要了解资源利用警报和监控的最佳实践,请参阅 Atlas 监控和警报指导。

We recommend that you run the latest MongoDB version to take advantage of new features and improved security guarantees. You should always ensure that you upgrade to the latest MongoDB major version before your current version reaches end of life.

您无法使用 Atlas 用户界面降级 MongoDB 版本。因此,我们建议您在计划和执行主要版本升级时直接与 MongoDB 的Professional Services或技术服务合作,以帮助您避免在升级过程中可能出现的任何问题。

在计划维护期间,Atlas 通过滚动更新的方式逐一对节点进行更新,以保持正常运行时间。在此过程中,每当当前主节点因维护而离线时,Atlas 会通过自动副本集选举选出一个新的主节点。此过程与自动故障转移时的处理方式相同,用于应对主节点的非计划性中断。

We recommend that you configure a custom maintenance window for your project to avoid maintenance-related replica set elections during business-critical hours. You can also set protected hours in your maintenance window settings to define a daily window of time in which standard updates cannot begin. Standard updates do not involve cluster restarts or resyncs.

以下示例使用Atlas 工具配置单区域 3 节点副本集/分片部署拓扑结构以实现自动化。

这些示例还应用其他推荐的配置,包括:

  • 集群层已为开发/测试环境设置为 M10。使用集群大小指南了解适合应用程序大小的推荐集群层。

  • 单区域,3 节点副本集/分片部署拓扑结构。

Our examples use AWS, Azure, and Google Cloud interchangeably. You can use any of these three cloud providers, but you must change the region name to match the cloud provider. To learn about the cloud providers and their regions, see Cloud Providers.

注意

在使用 Atlas CLI 创建资源之前,您必须:

在您的开发和测试环境中,为每个项目运行以下命令。在以下示例中,更改 ID 和名称以使用您的值。

注意

以下示例未启用自动伸缩功能,以帮助控制开发和测试环境中的费用。对于分阶段和生产环境,应启用自动伸缩功能。请参阅“分阶段环境和生产环境”标签页,以获取启用自动伸缩的示例。

atlas clusters create CustomerPortalDev \
--projectId 56fd11f25f23b33ef4c2a331 \
--region EASTERN_US \
--members 3 \
--tier M10 \
--provider GCP \
--mdbVersion 8.0 \
--diskSizeGB 30 \
--tag bu=ConsumerProducts \
--tag teamName=TeamA \
--tag appName=ProductManagementApp \
--tag env=dev \
--tag version=8.0 \
--tag email=marissa@example.com \
--watch

For more configuration options and info about this example, see the atlas clusters create command.