了解 Databases for MySQL 的高可用性和灾难恢复
高可用性服务或工作负载根据预先定义的服务级别承受故障并继续提供处理能力的能力。 对于服务，可用性在服务水平协议中进行了定义。 可用性包括计划内和计划外事件，例如维护、故障和灾难。 （HA）是指服务在出现意外故障时仍能保持运行和访问的能力。 灾难恢复服务或工作负载从罕见重大事故和大规模故障（如服务中断）中恢复的能力。 这包括影响整个地区的自然灾害、数据库损坏或导致工作负荷增加的服务中断。 这种影响超出了高可用性设计所能承受的范围。是将服务实例恢复到工作状态的过程。
Databases for MySQL 是一种区域性服务，可实现标准计划中规定的 服务水平目标(SLO)。 有关详细信息，请参阅 服务级别协议(SLA)。 有关 Databases for MySQL 可用 IBM Cloud 地区和数据中心的更多信息，请参阅“按位置划分的服务和基础设施可用性”。
高可用性架构
Databases for MySQL 提供复制、故障转移和高可用性功能，保护您的数据库和数据免受基础架构维护、升级和某些故障的影响。 部署包含一个群集，其中有三个数据成员--一个领导者和两个副本。 通过使用 Orchestrator 处理故障切换，所有成员都包含一份数据副本。 如果领导者无法访问，群集会启动故障转移，将一个副本提升为领导者，新的副本作为副本重新加入群集，群集继续正常运行。 领导者和复制者总是位于 MZR 的不同区域。 如果副本失败，则会创建一个新副本。 如果区域故障导致某个成员失效，则会在存活的区域中创建新的副本。
通过为跨区域故障切换或读取卸载配置 只读副本，可以进一步扩展高可用性。
查看 MySQL 复制技术文档，了解与半同步复制策略相关的限制和权衡。
以编程方式访问群集的工作负载必须遵循客户端可用性重试逻辑，以保持可用性。
Databases for MySQL 在正常运行时，有时会执行受控切换。 这些切换是无数据丢失事件，会导致活动连接的重置。 重新连接失败的时间最长可达 15 秒。 有时，由于运行环境中的意外事件，可能会发生计划外的故障切换。 这可能需要长达 45 秒的时间，但一般不超过 30 秒。 例如，服务维护会触发受控故障切换。
高可用性功能
Databases for MySQL 支持以下高可用性功能
| 功能 | 描述 | 对价 |
|---|---|---|
| 自动故障切换 | 所有集群的标准配置，可抵御区域或单个成员故障。 | |
| 成员计数 | 三人部署。 三成员群集可自动从实例或区域的单一故障中恢复，恢复过程中可能会出现数据滞后。 发生故障时，副本会晋升为领导者，群集会继续正常运行。 | |
| 只读复制 | 只读副本可在远程区域提供本地访问，提高对潜在网络延迟或连接问题的可用性。 | 所有写入请求必须专门指向与读取复制相关联的读写群集。 |
灾后恢复架构
灾难恢复的一般策略是创建一个新数据库，如 Restore 数据库。 新数据库的内容可以是灾难发生前创建的源数据库备份。 如果生产数据库可用，可使用时间点功能创建新数据库。
灾难恢复功能
Databases for MySQL 支持以下灾难恢复功能：
| 功能 | 描述 | 对价 |
|---|---|---|
| 备份还原 | 从先前创建的备份中创建数据库。 更多信息，请参阅 管理 Cloud Databases 备份。 | 必须在整个工作负载中引用已恢复数据库的新连接字符串。 |
| 时间点复原 | 使用 时间点恢复 从实时生产中创建数据库。 | 这只有在活动数据库可用且 RPO（灾难）在支持窗口内的情况下才有可能。 如果生产群集不可用，它就没有用了。 必须在整个工作负载中引用已恢复数据库的新连接字符串。 |
| 推广阅读复制品 | 当计划在同一或远程区域发生灾难时，创建 只读副本。 推广只读副本，以便从灾难中恢复。 | 之前创建的读取副本必须可用。 必须在整个工作负载中引用已恢复数据库的新连接字符串。 |
规划灾难恢复
必须定期练习灾难恢复步骤。 在制定计划时，请考虑以下失败情况和解决办法。
| 失败 | 解决方法 |
|---|---|
| 硬件故障（单点） | IBM 提供的数据库可抵御区域内单点硬件故障，无需任何配置。 |
| 区域故障 | 自动故障转移（#mysql-高可用性）。 数据库成员分布在各区之间。 |
| 数据损坏 | 备份还原。 将恢复的数据库用于生产或源数据，以纠正恢复数据库中的损坏。
时间点还原。 将恢复的数据库用于生产或源数据，以纠正恢复数据库中的损坏。 |
| 地区性失败 | 备份还原。 在生产中使用恢复的数据库。
推广阅读副本。 将只读副本升级为读写数据库。 在生产中使用恢复的数据库 |
应用级高可用性
通过网络和云服务进行通信的应用程序会受到瞬时连接故障的影响。 当与部署或 IBM Cloud 的连接暂时中断造成错误时，您需要设计应用程序重试连接。
由于 Databases for MySQL 是托管服务，因此定期更新和数据库维护是正常运行的一部分。 如果两个副本都丢失，由于半同步复制过程中没有跟随者，向领导者的写入就会挂起。 更多信息，请参阅 半同步复制。 这种情况偶尔会导致数据库在短时间内不可用。 它还会导致数据库触发优雅故障切换、重试和重新连接。 数据库需要很短的时间来确定哪个成员是副本，哪个是领导者，因此也可能会出现短暂的连接中断。 故障切换一般不超过 30 秒。 为尽量减少中断，更新首先应用于副本，最后才应用于领导者。
您的应用程序必须能够处理数据库的临时中断，对失败的数据库命令执行错误处理，并执行重试逻辑以从临时中断中恢复。
预计不会出现几分钟的数据库不可用或连接中断情况。 如果超过一分钟仍无法连接，请打开 支持案例 并提供详细信息，以便我们进行调查。
连接限制
Databases for MySQL 将 数据库的最大连接数设置为 MySQL 200。 留出一些可用连接，因为内部会保留一些连接来维护数据库的状态和完整性。 达到连接上限后，任何启动新连接的尝试都会导致错误。 为防止连接数过多，可使用连接池，或扩大部署规模并增加连接数限制。 更多信息，请参阅 管理 MySQL 连接。
您对 HA 和 DR 的责任
以下信息可帮助您创建并持续实践 HA 和 DR 计划。
从备份或使用时间点还原法还原数据库时，会创建一个带有新连接字符串的新数据库。 必须调整现有的工作负载和流程，以便使用新的连接字符串。 将读取副本升级到群集也会产生类似的影响，尽管工作负载的现有只读部分不会受到影响。
恢复后的数据库可能还需要与灾难数据库相同的客户创建的依赖关系--确保恢复区域中存在这些服务和其他服务：
- IBM® Key Protect for IBM Cloud®
- Hyper Protect Crypto Services
请记住，删除数据库也会删除其相关备份。 不过，被删除的数据库可以在有限的时间内恢复。 有关数据库恢复程序的具体详情，请参阅 备份常见问题。
无法从 IBM Cloud 复制备份，因此可考虑使用特定于数据库的工具进行额外备份。 在恶意删除数据库后，可能需要使用它来恢复数据库。 仔细管理 IAM 对数据库的访问有助于减少这一问题的发生。
以下与每个功能相关的核对表可以帮助您制定和实践您的计划。
- 备份还原
- 验证备份是否以所需频率提供，以满足 RPO 要求。 更多信息，请参阅 管理 Cloud Databases 备份。 如果数据库的关键性和规模允许，可考虑使用 IBM Cloud® Code Engine- 与定期定时器（cron）事件生成器合作 创建额外的按需备份脚本，以提高 RPO。 不过，鉴于 MySQL's PITR 功能，应仔细评估是否需要额外的备份。
- 对数据库还原区域有一些限制--请阅读 管理 Cloud Databases 备份，确认能否实现还原目标。
- 验证备份的保留期限是否符合您的要求。
- 定期安排测试恢复，以验证实际恢复时间是否符合定义的 RTO。 请记住，数据库大小对还原时间有很大影响。 考虑尽量缩短还原时间的策略，例如将大型数据库分解成更小、更易于管理的单元，以及清除未使用的数据。
- 验证 Key Protect 服务。
- 时间点复原
- 验证前面介绍的程序。
- 确认窗口中是否有所需的备份。
- 推广阅读复制品
- 验证恢复区域中是否存在读取副本。
- 练习推广过程--在所需区域创建一个临时读取副本。 可以将临时副本升级为读/写，并进行一些测试，而对生产几乎没有影响。
要进一步了解客户和 IBM Cloud 之间在使用 Databases for MySQL 方面的责任归属，请参阅 Cloud Databases 的共同 责任。
了解最新信息：IBM 通知
影响客户工作负载的更新通过 IBM Cloud 通知。 要随时了解与此服务相关的计划维护、公告和发布说明，请参阅 监控通知和状态 页面。 此外，请定期查看 版本政策 页面，了解有关生命周期结束版本和日期的最新更新。