注意
本页面同时适用于 Atlas Infinite 和 Atlas Core。
您可以通过配置以下选项来管理 Atlas 如何为您的项目推出维护：
受保护时间：业务关键时间，在此期间无法进行标准更新。
Maintenance Windows：Atlas 开始每周维护的时间，该维护需要对项目中的集群进行副本集选举。
维护波次：组织中项目接收维护的顺序。维护波次按顺序标记，从 Wave 1 到 Last Wave。
您可以可视化 Atlas 如何根据您的维护窗口、受保护时间和维护波向您的项目推出维护，使用 Projected Maintenance Calendar tool。
重要
维护窗口、受保护时段和维护波次是按项目配置的，它们仅适用于专用集群（M10 及以上版本）。对于 Free 集群和 Flex 集群，Atlas 会自动托管其维护窗口，您无法手动配置它们。
我们建议您设置维护窗口、受保护时间和维护波，尽管所有这些都是可选的。Atlas 以滚动方式自动执行维护，以确保弹性应用程序的持续可用性。为确认您的应用程序对副本集选举具有弹性，请在 Atlas 中测试故障转移。
要了解详情，请参阅：
维护管理注意事项
受保护时间：除了配置维护窗口之外，您还可以设置每日受保护时间，这是 Atlas 避免执行标准更新的时间段。 受保护时间窗口的长度不得超过 18 个小时。
Atlas 可以执行不涉及集群重启或影响工作负载性能的标准更新，即使这些更新在您配置的维护窗口之外进行，但 Atlas 始终遵循受保护的时间。
紧急维护活动：Atlas 可能会在必要时立即执行紧急维护活动（例如零日漏洞的安全补丁），而不考虑配置的维护窗口、受保护的时间或维护波。
持续维护操作：一旦您为集群安排了维护窗口，在所有进行中的维护操作完成之前，您无法更改它。
MongoDB 数据库升级：如果维护包括 MongoDB 次要版本或补丁版本升级，Atlas 会在控制台中显示当前版本和目标版本。如果 Atlas 在下一个维护窗口期间升级您某个集群上的 MongoDB 维护版本，则该集群会显示目标 MongoDB 维护版本。
维护需要副本集选举：Atlas 的维护方式与 MongoDB 手册中所述的维护过程相同。此过程要求每个副本集在维护窗口期间至少进行一次副本集选举。要确认您的应用程序对副本集选举具有弹性，请在 Atlas 中测试故障转移。
维护会尽可能接近窗口开始时启动：但正在进行的集群更新或意外的系统问题可能会延迟开始时间。
维护期间可能会出现短暂的性能下降：如果磁盘 IOPS 较低，则在 MongoDB 重新填充 WiredTiger 存储引擎时，集群可能会在维护期间出现短暂的性能下降。请参阅日志记录和 WiredTiger 存储引擎，以了解更多信息。
默认维护波次：对于未明确分配维护波次的项目，Atlas 会根据以下规则自动分配：
Atlas 将没有配置维护窗口的项目分配给 Wave 1。
Atlas 将配置了维护窗口的项目分配给 Wave2 。
您可以随时手动更改这些波次分配。如需了解更多信息，请参阅配置维护管理设置。
维护波次评估：Atlas 在维护事件首次发出时评估配置的维护波次。如果您在维护事件开始到完成所有波之间对维护波进行了更改，Atlas 将在下一个维护事件开始时开始使用新的维护波。
维护间隔时间：如果您配置了维护波次，Atlas 在对一个波次和下一个波次推出维护之间至少间隔 48 小时。对分配给特定波次的所有项目，必须完成一次维护工作，然后 Atlas 才会从 Wave 1 开始进行到下一个波次。
计划维护操作类型
Scheduled Maintenance Operations 模态可能显示以下一种或多种维护类型：
MongoDB 所需维护：集群运行状况和稳定所需的关键维护操作。
MongoDB 版本更新：升级到 MongoDB 次要版本、补丁版本或维护版本。
操作系统策略版本更新：更新根本的操作系统策略和安全补丁。
其他维护操作：集群管理所需的其他维护活动。
轨道维护完成
维护操作完成后，您将在项目操作日志中看到 Maintenance window completed事件。
为未来的维护 Windows 自动推迟
您可以启用 Automatically defer maintenance for one week 选项，让 Atlas 每次自动将未来的计划维护推迟一周。这意味着维护实际上每两周运行一次，而不是每周一次，因为第一周每次都会被自动推迟。如果需要，您仍然可以手动额外推迟一次维护。
重要
如果您已为组织中的项目配置了维护波动，则无法为该组织中的项目配置自动推迟维护。
如果您启用Automatically defer maintenance for one week 选项， Atlas会为未来的维护窗口配置自动延迟。要推迟当前计划的维护，请使用Defer 1 Week 选项，如推迟维护部分所述。
自动推迟功能允许您将维护操作合并到单个维护窗口中，并减少维护事件的总数。如果您想在较低的环境中测试维护以在更新到达生产环境之前进行验证，请使用 Maintenance Waves，而不是使用自动推迟。
要启用自动延迟，请参阅 配置维护管理设置。
使用维护波次来观察维护影响
您可以设置维护波次，以便在维护影响生产环境之前，先观察其对较低环境的影响。维护包括任何计划内维护操作类型。建议在任何升级节奏中都在生产环境之前进行测试。要了解更多信息，请在升级前参阅版本和升级路径指导。
使用维护波次与环境隔离
许多代码开发设置将其工作流分离到不同的环境中，最常见的是：
开发 (Dev)：即开发者初次写入和测试新代码的地方。
质量保证 (QA)：测试人员在模拟真实工作负载的环境中查看代码，以检查错误、性能和可靠性。
生产 (Prod)：终端用户访问代码并与其进行交互的地方。
维护批次对环境分离的工作流很有用，因为它们可以让您在维护推出到用户面对的环境之前，监控集群维护如何影响内部环境。
要跨这些或类似环境为项目使用维护波次，我们建议为每个项目设置相同的维护窗口和保护时间。然后，将每个环境分配给一个维护波次，如下所示：
从开发到 Wave 1
QA 针对 Wave 2
生产环境 到 Last Wave
这可以确保在向每个环境推出维护事件之间至少有七天的时间间隔。您还可以对于分配给 Last Wave 的项目将维护推迟额外七天。
预计维护日历工具
要直观了解维护事件何时将推送到您的项目，可以使用 Projected Maintenance Calendar 工具。通过此工具，您可以输入潜在的维护窗口和批次以及维护版本发布日期。根据这些设置和发布日期，该工具会显示 Atlas 在各个批次中对项目执行维护的日期和时间。
此工具未链接到 Atlas 账户。它无法读取您在 Atlas 中配置的设置，也无法为您的项目或组织配置设置。