了解 Databases for Redis 的高可用性和灾难恢复
高可用性服务或工作负载根据预先定义的服务级别承受故障并继续提供处理能力的能力。 对于服务，可用性在服务水平协议中进行了定义。 可用性包括计划内和计划外事件，例如维护、故障和灾难。 （HA）是指服务在出现意外故障时仍能保持运行和访问的能力。 灾难恢复服务或工作负载从罕见重大事故和大规模故障（如服务中断）中恢复的能力。 这包括影响整个地区的自然灾害、数据库损坏或导致工作负荷增加的服务中断。 这种影响超出了高可用性设计所能承受的范围。是将服务实例恢复到工作状态的过程。
Databases for Redis 是一种区域性服务，可实现标准计划中规定的 服务水平目标(SLO)。
有关 Databases for Redis 可用 IBM Cloud 地区和数据中心的更多信息，请参阅“按位置划分的服务和基础设施可用性”。
高可用性架构
Databases for Redis 提供复制、故障转移和高可用性功能，保护您的数据库和数据免受基础架构维护、升级和某些故障的影响。 部署包含一个群集，该群集有两个数据成员，采用主节点加副本的配置。 副本通过异步复制保持更新。 通过三个 Redis 哨兵监控和管理高可用性
Databases for Redis 结合使用 RDB 快照和 AOF（仅附加文件） 将数据持久化到磁盘。 Databases for Redis 写入磁盘（fsync）的时间间隔设置为 每秒一次，以平衡耐用性和性能。
您可以关闭数据持久性，这对于 将 Redis 配置为缓存 非常有用。
高可用性功能
Databases for Redis 支持以下高可用性功能
| 功能 | 描述 | 对价 |
|---|---|---|
| 自动故障切换 | 所有集群的标准配置，可抵御区域或单一成员故障 | |
| 成员计数 | 最少 2 名成员。 默认为主配置和副本配置中的标准双成员集群。 双成员群集将自动从单个实例或区域故障中恢复（数据丢失最高可达滞后阈值）。 | 三个哨兵节点，用于监控群集的健康状况并协调故障切换。 |
| 异步复制 | 在不阻塞写入路径的情况下，实现从主站到副本的复制，确保高可用性和低延迟。 请参阅下面的 异步复制。 | 由于复制滞后（RPO > 0），可能导致故障切换期间的数据丢失。 不适合需要严格数据耐久性的场合。 |
异步复制 Databases for Redis
默认情况下，Databases for Redis 使用异步复制，即主节点不等待副本确认写入。 这确保了低延迟和高吞吐量，使 Databases for Redis 成为高速缓存和性能敏感型工作负载的理想选择。 但是，如果主系统发生故障，复制滞后可能会导致数据丢失，因为副本可能没有收到最新写入的数据。
Databases for Redis 复制的目的是高可用性，而不是严格的耐用性。 如果主服务器无法访问，就会自动触发故障转移，将副本提升为领导者。 由于复制是异步的，在此过程中可能会丢失一些已提交的写入。 这种复制滞后定义了 Databases for Redis 部署的恢复点目标 (RPO)。
为降低数据丢失风险，Databases for Redis 支持 RDB 快照和 AOF（仅附加文件） 等持久性机制，这些机制可在复制过程之外将数据写入磁盘。 应根据工作量要求对这些设备进行精心配置。
Databases for Redis 中的异步复制可确保快速性能，但并不能消除故障切换事件中数据丢失的可能性。 如果工作负载的速度和可用性比严格的数据一致性更重要，则建议使用这种方法。
灾后恢复架构
灾难恢复的一般策略是创建一个新数据库，如下面的 Restore 数据库。 新数据库的内容可以是灾难发生前创建的源数据库备份。
灾难恢复功能
Databases for Redis 支持以下灾难恢复功能：
| 功能 | 描述 | 对价 |
|---|---|---|
| 备份还原 | 根据先前创建的备份创建数据库；请参阅 管理 Cloud Databases 备份。 | 必须在整个工作负载中引用已恢复数据库的新连接字符串。 |
规划灾难恢复
必须定期练习灾难恢复步骤。 在制定计划时，请考虑以下失败情况和解决办法。
| 失败 | 解决方法 |
|---|---|
| 硬件故障（单点） | (示例） IBM 提供的数据库可防止区域内出现单点硬件故障。 无需客户配置。 |
| 区域故障 | 自动故障切换 数据库成员分布在各区之间。 |
| 数据损坏 | 备份还原。 将恢复的数据库用于生产或源数据，以纠正恢复数据库中的损坏。 |
应用级高可用性
通过网络和云服务进行通信的应用程序会受到瞬时连接故障的影响。 当与部署或 IBM Cloud 的连接暂时中断造成错误时，您需要设计应用程序重试连接。
由于 Databases for Redis 是托管服务，因此定期更新和数据库维护是正常运行的一部分。 这偶尔会导致数据库在短时间内不可用。 它还会导致数据库触发优雅的故障切换、重试和重新连接。 数据库需要很短的时间来确定哪个成员是副本，哪个是领导者，因此也可能会出现短暂的连接中断。 故障切换一般不超过 30 秒。
您的应用程序必须能够处理数据库的临时中断，对失败的数据库命令实施错误处理，并实施重试逻辑以从临时 interruption.Use IOREDIS、NODEREDIS 或您选择的任何其他软件包中恢复，以确保 application.For 的连续性，更多信息，请参阅 Redis 的错误检测和处理博文。
预计不会出现几分钟的数据库不可用或连接中断情况。 如果超过一分钟仍无法连接，请打开 支持案例 并提供详细信息，以便我们进行调查。
连接限制
Databases for Redis 将每次部署的并发连接设置为最多 10,000 个。 这一限制可确保 Redis 环境中的性能稳定性和资源管理。 不过，并非所有 10,000 个连接都可供客户使用，其中一部分在内部保留，用于维护部署的状态和完整性。 达到连接上限后，任何启动新连接的尝试都会导致错误。 更多信息，请参阅 管理 Redis 连接。
您对 HA 和 DR 的责任
以下信息可帮助您创建并持续实践 HA 和 DR 计划。
从备份或使用时间点还原法还原数据库时，会创建一个带有新连接字符串的新数据库。 必须调整现有的工作负载和流程，以便使用新的连接字符串。
恢复后的数据库可能还需要与灾难数据库相同的客户创建的依赖关系。 确保在收复地区提供这些服务和其他服务：
- IBM® Key Protect for IBM Cloud®
- Hyper Protect Crypto Services
请记住，删除数据库也会删除其相关备份。 不过，被删除的数据库可以在有限的时间内恢复。 有关详细信息，请参阅 备份常见问题。
无法从 IBM Cloud 复制备份，因此可考虑使用特定于数据库的工具进行额外备份。 在恶意删除数据库后，可能需要使用它来恢复数据库。 仔细管理 IAM 对数据库的访问有助于减少这一问题的发生。
以下与每个功能相关的核对表可以帮助您制定和实践您的计划。
- 备份还原
- 验证备份是否以所需频率提供，以满足 RPO 要求。 管理 Cloud Databases 备份，记录备份频率。
- 对数据库还原区域有一些限制--请阅读 管理 Cloud Databases 备份，确认能否实现还原目标。
- 验证备份的保留期限是否符合您的要求。
- 定期安排测试恢复，以验证实际恢复时间是否符合定义的 RTO。 请记住，数据库大小对还原时间有很大影响。 考虑尽量缩短还原时间的策略，例如将大型数据库分解成更小、更易于管理的单元，以及清除未使用的数据。
- 验证 Key Protect 服务。
要进一步了解客户和 IBM Cloud 之间在使用 Databases for Redis 方面的责任归属，请参阅 Cloud Databases 的共同 责任。
了解最新信息：IBM 通知
影响客户工作负载的更新通过 IBM Cloud 通知。 要随时了解与此服务相关的计划维护、公告和发布说明，请参阅 监控通知和状态 页面。 此外，请定期查看 版本政策 页面，了解有关生命周期结束版本和日期的最新更新。