当您丢失主节点 (primary node in the replica set)Ops Manager时,您可以从从节点(secondary node from replica set)Ops Manager恢复其 后端数据库,然后启动新的主节点 (primary node in the replica set)Ops Manager 。在发生升级失败、数据意外删除或基础架构故障等事件后,请使用此程序。当主节点 (primary node in the replica set)Ops Manager重新启动时,它会自动进入恢复模式,以在恢复正常操作之前协调代理配置。有关此模式的概述,请参阅使用从节点实例备份和恢复Ops Manager 。要配置此模式,请参阅配置从节点Ops Manager以备份Ops Manager。
Considerations
恢复顺序
恢复后端数据库和启动主节点 (primary node in the replica set)Ops Manager的顺序至关重要。
警告
在启动主节点 (primary node in the replica set)Ops Manager之前恢复后端数据库。如果在恢复其后端数据库之前启动主节点 (primary node in the replica set)Ops Manager ,则主节点 (primary node in the replica set)Ops Manager可能会写入不一致的状态,并在新旧部署之间造成脑裂情况。
如果从节点(secondary node from replica set)Ops Manager也备份了快照元数据存储和oplog元数据存储,则在开始之前,请将所有三个后端数据库恢复到同一时间点,或将元数据存储恢复到比应用程序数据库稍晚的点。主节点 (primary node in the replica set)Ops Manager。将元数据存储恢复到应用程序数据库之前的时间点会导致主节点 (primary node in the replica set)Ops Manager使用HTTP 409(“快照块丢失”)拒绝受影响的恢复作业。
恢复点
时点还原将应用程序数据库恢复到您选择的时间点,而不是灾难发生的那一刻。在灾难发生之前,备份未在oplong slice中捕获的操作可能无法恢复。在时间点恢复窗口允许的范围内,选择距离灾难发生地点尽可能近的恢复点。
主节点 (primary node in the replica set)Ops Manager重新启动后,协调将从MongoDB助手恢复部署自动化配置。其他最近的应用程序数据库更改会反映您选择的恢复点。
版本兼容性
主节点 (primary node in the replica set)Ops Manager 和从节点(secondary node from replica set)Ops Manager版本必须保持兼容。
警告
将应用程序数据库恢复到与创建快照的主节点 (primary node in the replica set)Ops Manager运行的版本相同或更高的主节点 (primary node in the replica set)Ops Manager 。如果替换二进制文件早于应用程序数据库记录的版本,Ops Manager将拒绝启动,并显示“不允许降级”错误。
先决条件
Ops Manager8.0.24 及更高版本中默认启用恢复模式。如果已禁用,请在恢复之前在主节点 (primary node in the replica set)Ops Manager上重新启用。有关步骤,请参阅配置从节点Ops Manager以备份Ops Manager。
确认从从节点(secondary node from replica set)Ops Manager具有完整的快照和针对后端数据库的连续时间点恢复窗口。
确认您保留了恢复所需的每主机状态,包括原始Ops Manager主节点 (primary node in the replica set)安装中的
gen.key文件。
保留每台主机的状态
完整的主节点 (primary node in the replica set)Ops Manager恢复需要的不仅仅是应用程序数据库。除了从从节点(secondary node from replica set)Ops Manager备份的应用程序数据库之外,还在每个托管上保留以下状态:
列项 | 地点 | 说明 |
|---|---|---|
加密密钥 |
| 加密应用程序数据库内容。必须与原始安装使用的密钥匹配,否则主节点 (primary node in the replica set)Ops Manager无法在初创企业时解密恢复的应用程序数据库。 |
Ops Manager配置 |
| 存储数据库URI、块存储配置、许可证密钥和 TLS 证书。如果没有它,您必须手动重新配置主节点 (primary node in the replica set)Ops Manager 。 |
代理配置 |
| 存储 |
重要
如果 gen.key文件丢失或与恢复的应用程序数据库不匹配,则主节点 (primary node in the replica set)Ops Manager将无法初创企业预检查,并显示 gen.key 与已用于此Ops Manager安装的密钥不匹配的错误。将 gen.key 与应用程序数据库数据一起保留在灾难恢复备份中。
恢复主节点Ops Manager
恢复后端数据库
在从从节点(secondary node from replica set)Ops Manager中,将主节点 (primary node in the replica set)Ops Manager 的应用程序数据库恢复到您选择的时间点:
单击 Continuous Backup,然后选择应用程序数据库副本集。
单击菜单,然后单击Restore 。
选择 Point in Time,然后输入目标日期和时间。
单击 Choose Cluster to Restore to,选择应用程序数据库副本集主机,然后单击 Restore。
从节点(secondary node from replica set)Ops Manager 的MongoDB 助手会停止应用程序数据库进程,用恢复的快照替换数据,将oplog重放到目标时间,然后重新启动进程。
警告
如果从节点(secondary node from replica set)Ops Manager也备份快照和oplog元数据存储,请在启动主节点 (primary node in the replica set)Ops Manager之前将其恢复到与应用程序数据库相同的时间点,或稍晚一些的点。将元数据存储恢复到较早的点会导致主节点 (primary node in the replica set)Ops Manager使用HTTP 409(“快照块丢失”)拒绝受影响的恢复作业。
如果仅恢复应用程序数据库,则从从节点(secondary node from replica set)Ops Manager会保持元数据存储不变。这对于正常操作是安全的,但主节点 (primary node in the replica set)Ops Manager在恢复点和现在之间拍摄的备份快照可能不可用。
启动主节点 (primary node in the replica set)Ops Manager
启动主节点 (primary node in the replica set)Ops Manager。主节点 (primary node in the replica set)Ops Manager连接到已恢复的应用程序数据库,读取已恢复的状态,然后开始恢复。要学习;了解更多信息,请参阅启动和停止Ops Manager 应用程序。
恢复模式和协调
恢复应用程序数据库并启动主节点 (primary node in the replica set)Ops Manager后,主节点 (primary node in the replica set)Ops Manager会将每个MongoDB助手的配置版本与恢复的配置版本进行比较。如果代理报告了更高版本,主节点 (primary node in the replica set)Ops Manager会进入该项目的恢复模式并自动协调配置:
主节点 (primary node in the replica set)Ops Manager隔离项目。它会显示恢复模式横幅,向代理轮询返回未更改的响应,并阻止从用户界面和 API部署更改,直到协调完成。
主节点 (primary node in the replica set)Ops Manager从每个代理收集配置版本,选择具有最新配置的代理,并将该配置作为权威配置写入应用程序数据库。
主节点 (primary node in the replica set)Ops Manager退出项目的恢复模式并恢复正常运行。备份会自动恢复。
这种协调可以防止裂脑情况。在任何代理收到新配置之前,它将所有代理集中在一个权威配置上。
当您将应用程序数据库回滚到较早的点时,恢复的配置不再包括您在恢复点之后所做的部署更改。如果不进行调节,代理会收到较旧的配置,并停止该配置不再引用的进程。影响取决于部署更改:
部署变更 | 没有调节的风险 |
|---|---|
新副本集成员 | 数据存在于其他成员上,因此您不会丢失任何数据。 |
包含迁移数据段的新分片 | 迁移的数据段仅存在于新分片上。停止运行会导致无法访问该数据,从而导致数据丢失。 |
新进程版本 | 该进程无法在回滚的二进制版本上运行,这会导致操作偏差。 |
新索引 | 在Ops Manager重建索引之前,索引查询会降级。 |
协调可以防止这些结果。主节点 (primary node in the replica set)Ops Manager将所有代理聚合到最新配置,并在退出恢复模式之前将按需快照,从而为您提供一致的备份点。
验证恢复的Ops Manager
确认恢复的主节点 (primary node in the replica set)Ops Manager正常:
确认MongoDB助手重新连接并报告为正常运行。
确认托管部署的自动化、备份和监控已恢复。
确认主节点 (primary node in the replica set)Ops Manager退出恢复模式。要检查恢复模式状态,请以具有
GET角色的用户身份向以下端点发送Project Read Only请求。响应显示项目的当前状态、触发原因和时间戳:GET /api/public/v1.0/groups/{PROJECT-ID}/restorationMode
从卡住的协调中恢复
如果主节点 (primary node in the replica set)Ops Manager在恢复模式下重启,则会在下一次MongoDB 助手轮询时重新触发协调。您无需对重启案例采取动作。
协调可能无法完成,示例因为无法访问代理。在这种情况下,请以具有 角色的用户身份使用以下API端点之一:Project Owner
要重试协调,请向以下端点发送
POST请求。重试会重置协调失败计数器并重新运行协调,而无需退出恢复模式:POST /api/public/v1.0/groups/{PROJECT-ID}/restorationMode/retry 要强制主节点 (primary node in the replica set)Ops Manager退出恢复模式并接受恢复的配置,请向以下端点发送
DELETE请求:DELETE /api/public/v1.0/groups/{PROJECT-ID}/restorationMode
警告
当您强制主节点 (primary node in the replica set)Ops Manager退出恢复模式时,它会接受恢复的配置,而不协调后续的代理配置。仅当协调无法完成时才使用此端点。强制退出后,主节点 (primary node in the replica set)Ops Manager会为项目中的所有代理提供恢复的配置,并且在每个代理都收敛之前不会重新进入恢复模式。
切换到已恢复的Ops Manager
此模式可将主节点 (primary node in the replica set)Ops Manager恢复到位。它不会提升从节点(secondary node from replica set)Ops Manager以替换主节点 (primary node in the replica set)Ops Manager。
验证恢复的主节点 (primary node in the replica set)Ops Manager后,完成切换:
更新
URL to Access Ops Manager设置和所有 DNS 记录,使其点已恢复的主节点 (primary node in the replica set)Ops Manager。确认MongoDB助手已连接到已恢复的主节点 (primary node in the replica set)Ops Manager。当配置中的
mmsGroupId和mmsApiKey与恢复的项目记录匹配时,代理无需重新注册即可重新连接。
操作指南
随着时间的推移,使用以下实践来操作和验证此模式。
测试备份和恢复路径
未经测试的恢复存在操作风险。定期测试此备份和恢复路径。将以下操作手册视为必需的实践,而不是可选的指导:
按安排执行测试恢复。将后端数据库恢复到沙箱Ops Manager ,并确认其启动和协调。
确认快照按安排出现,并且时间点恢复窗口保持连续。
查看主节点 (primary node in the replica set)Ops Manager和从节点(secondary node from replica set)Ops Manager日志是否有备份和恢复错误。
监控从节点Ops Manager
监控从节点(secondary node from replica set)Ops Manager及其备份的后端数据库:
使用Ops Manager备份警报来监视后端数据库是否有丢失或失败的快照。
确认时间点恢复窗口保持连续并不断前进。
监控从从节点(secondary node from replica set)Ops Manager 的应用程序数据库和备份守护程序的运行状况。
故障场景
下表描述了此模式在常见故障场景中的行为:
Scenario | 影响 | 恢复 |
|---|---|---|
从节点Ops Manager暂时不可用 | 新的备份和恢复暂停。主节点 (primary node in the replica set)Ops Manager和所有托管代理继续运行。 | 恢复从节点(secondary node from replica set)Ops Manager。备份代理会自动恢复。 |
从节点Ops Manager在恢复后失败 | 无。恢复应用程序数据库后,主节点 (primary node in the replica set)Ops Manager会进入恢复模式并在没有从节点(secondary node from replica set)Ops Manager 的情况下进行协调。 | 无需执行任何动作。 |
两个Ops Manager实例均丢失 | 主节点 (primary node in the replica set)Ops Manager 的应用程序数据库无法进行时点恢复。 | 重新构建从节点(secondary node from replica set)Ops Manager并重新导入应用程序数据库,或者重建主节点 (primary node in the replica set)Ops Manager并手动重新导入集群。 |
性能、存储和成本考量
运行专用从节点(secondary node from replica set)Ops Manager时,请考虑以下事项:
从从节点(secondary node from replica set)Ops Manager 的大小远小于生产主节点 (primary node in the replica set)Ops Manager。它仅管理主节点 (primary node in the replica set)Ops Manager 的后端数据库的备份和恢复,而不管理您的MongoDB集群。
根据快照安排和保留策略,规划后端数据库的快照存储容量。
考虑运行专用从节点(secondary node from replica set)Ops Manager的额外的基础架构和运营费用。