了解 Databases for MongoDB 的高可用性和灾难恢复
高可用性服务或工作负载根据预先定义的服务级别承受故障并继续提供处理能力的能力。 （HA）是指服务在出现意外故障时仍能保持运行和访问的能力。 灾难恢复服务或工作负载从罕见重大事故和大规模故障（如服务中断）中恢复的能力。 这包括影响整个地区的自然灾害、数据库损坏或导致工作负荷增加的服务中断。 这种影响超出了高可用性设计所能承受的范围。是将服务实例恢复到工作状态的过程。
Databases for MongoDB 是一种区域性服务，可实现标准计划和企业计划中规定的 服务水平目标(SLO)。 更多信息，请参阅 服务级别协议(SLA)。 有关 Databases for MongoDB 可用 IBM Cloud 地区和数据中心的更多信息，请参阅“按位置划分的服务和基础设施可用性”。
高可用性架构
Databases for MongoDB 提供复制、故障转移和高可用性功能，保护您的数据库和数据免受基础架构维护、升级和某些故障的影响。 部署包含一个群集，其中有三个数据成员--一个主成员和两个辅助成员。 双成员副本集通过异步复制保持更新。 分布式共识机制用于维护集群状态和处理故障切换。 如果主服务器不可用，副本集会选择一个辅助服务器作为主服务器，并继续正常运行。 旧主设备可用时会重新加入机组。 主要成员和次要成员总是位于多边形区域的不同区域。 如果区域故障导致成员失效，新副本将在存活的区域中创建。
高可用性功能
Databases for MongoDB 支持以下高可用性功能
| 功能 | 描述 |
|---|---|
| 自动故障切换 | 所有集群的标准配置，可抵御区域或单个成员故障。 |
| 成员计数 | 至少 3 名成员。 默认为标准三成员部署。 三成员群集将自动从单个实例或区域故障中恢复（数据丢失最多不超过滞后阈值）。 |
| 异步复制 | 辅助节点复制主节点的操作，并异步将操作应用到其数据集。 通过让辅助数据集反映主数据集，复制集可以在一个或多个成员发生故障的情况下继续运行。 |
灾后恢复架构
灾难恢复的一般策略是创建一个新数据库，如以下 MongoDB Restore 数据库。 新数据库的内容可以是灾难发生前创建的源数据库备份。 如果生产数据库可用，可使用企业计划的时间点功能创建新数据库。
灾难恢复功能
Databases for MongoDB 支持以下灾难恢复功能。
| 功能 | 描述 | 对价 |
|---|---|---|
| 备份还原 | 根据先前创建的备份创建数据库；请参阅 管理 Cloud Databases 备份。 | 必须在整个工作负载中引用已恢复数据库的新连接字符串。 |
| 时间点复原 | 使用 时间点恢复 从实时生产中创建数据库。 | 只有在企业计划和活动数据库可用且 RPO（灾难）在支持窗口内的情况下，才可以这样做。 如果生产群集不可用，它就没有用了。 必须在整个工作负载中引用已恢复数据库的新连接字符串。 |
规划灾难恢复
必须定期练习灾难恢复步骤。 在制定计划时，请考虑以下失败情况和解决办法。
| 失败 | 解决方法 |
|---|---|
| 硬件故障（单点） | IBM 提供的数据库可抵御区域内单点硬件故障，无需任何配置。 |
| 区域故障 | 自动故障切换 数据库成员分布在各区之间。 配置三个成员将为多个区域故障提供额外的恢复能力。 |
| 数据损坏 | 备份还原。 将恢复的数据库用于生产或源数据，以纠正恢复数据库中的损坏。
时间点还原。 将恢复的数据库用于生产或源数据，以纠正恢复数据库中的损坏。 |
| 地区性失败 | 备份还原。 在生产中使用恢复的数据库。 |
应用级高可用性
通过网络和云服务进行通信的应用程序会受到瞬时连接故障的影响。 当与部署或 IBM Cloud 的连接暂时中断而导致错误时，您需要设计应用程序以重试连接。
您的应用程序必须能够处理数据库的临时中断，对失败的数据库命令执行错误处理，并执行重试逻辑以从临时中断中恢复。
预计不会出现几分钟的数据库不可用或连接中断情况。 如果超过一分钟仍无法连接，请打开 支持案例 并提供详细信息，以便我们进行调查。
您对 HA 和 DR 的责任
以下信息可帮助您创建并持续实践 HA 和 DR 计划。
从备份或使用时间点还原法还原数据库时，会创建一个带有新连接字符串的新数据库。 必须调整现有的工作负载和流程，以便使用新的连接字符串。 将读取副本升级到群集也会产生类似的影响，尽管工作负载的现有只读部分不会受到影响。
恢复的数据库可能还需要与灾难数据库相同的客户创建的依赖关系--确保恢复区域中存在以下服务和其他服务：
- IBM® Key Protect for IBM Cloud®
请记住，删除数据库也会删除其相关备份。 不过，被删除的数据库可以在有限的时间内恢复。 有关数据库恢复程序的具体详情，请参阅 常见问题备份文件。
无法从 IBM Cloud 复制备份，因此可考虑使用特定于数据库的工具进行额外备份。 在恶意删除数据库后，可能需要使用它来恢复数据库。 仔细管理 IAM 对数据库的访问有助于减少这一问题的发生。
以下与每个功能相关的核对表可以帮助您制定和实践您的计划。
- 备份还原
- 验证备份是否以所需频率提供，以满足 RPO 要求。 管理 Cloud Databases 备份，记录备份频率。 如果数据库的关键性和规模允许，可考虑使用 IBM Cloud® Code Engine- 与定期定时器（cron）事件生成器合作 创建额外的按需备份脚本，以提高 RPO。
- 对数据库还原区域有一些限制--请阅读 管理 Cloud Databases 备份，确认能否实现还原目标。
- 验证备份的保留期限是否符合您的要求。
- 定期安排测试恢复，以验证实际恢复时间是否符合定义的 RTO。 请记住，数据库大小对还原时间有很大影响。 考虑尽量缩短还原时间的策略，例如将大型数据库分解成更小、更易于管理的单元，以及清除未使用的数据。
- 验证 Key Protect 服务。
- 时间点复原
- 验证前面介绍的程序。
- 验证窗口中是否有所需的备份。
有关客户和 IBM Cloud 之间使用 Databases for MongoDB 的责任归属的更多信息，请参阅 Cloud Databases 的共同 责任。
了解最新信息：IBM 通知
影响客户工作负载的更新通过 IBM Cloud 通知。 要随时了解与此服务相关的计划维护、公告和发布说明，请参阅 监控通知和状态。 此外，定期查看 版本政策，了解有关生命周期结束版本和日期的最新更新。