了解 Databases for PostgreSQL 的高可用性和灾难恢复
高可用性服务或工作负载根据预先定义的服务级别承受故障并继续提供处理能力的能力。 对于服务，可用性在服务水平协议中进行了定义。 可用性包括计划内和计划外事件，例如维护、故障和灾难。 （HA）是指服务在出现意外故障时仍能保持运行和访问的能力。 灾难恢复服务或工作负载从罕见重大事故和大规模故障（如服务中断）中恢复的能力。 这包括影响整个地区的自然灾害、数据库损坏或导致工作负荷增加的服务中断。 这种影响超出了高可用性设计所能承受的范围。是将服务实例恢复到工作状态的过程。
Databases for PostgreSQL 是一种区域性服务，可实现标准计划中规定的 服务水平目标(SLO)。 更多信息，请参阅 服务级别协议(SLA)。 有关 site.data.keyword.databases-for-postgresql 可用 IBM Cloud 地区和数据中心的更多信息，请参阅“按位置划分的服务和基础设施可用性”。
高可用性架构
Databases for PostgreSQL 提供复制、故障转移和高可用性功能，保护您的数据库和数据免受基础架构维护、升级和某些故障的影响。 部署包含一个具有两个数据成员（领导者和副本）的群集。 副本通过异步复制保持更新。 分布式共识机制用于维护集群状态和处理故障切换。 如果领导者无法访问，群集就会启动故障转移，将副本提升为领导者，新的副本作为副本重新加入群集。 在 MZR 中，领导者和副本总是处于不同的区域。 如果副本失败，则会创建一个新副本。 如果区域故障导致成员失效，新副本将在存活的区域中创建。
您可以通过向群集添加 PostgreSQL 成员 来进一步扩展高可用性，以实现更大的区域内冗余，或通过配置 只读副本 来实现跨区域故障转移或读取卸载。
查看 PostgreSQL 复制技术文档，了解与默认部署的异步复制策略相关的限制和权衡。
在数据库出现严重不健康情况（如领导者服务器崩溃）时，Databases for PostgreSQL 会尝试进行故障转移。 这种自动故障切换功能的上限为从领导者到副本之间 16 MB 的数据滞后（几行数据一次占更多 PostgreSQL 数据开销），如果超过滞后阈值，则不执行自动故障切换。 如果应用程序无法忍受 16 MB 的潜在数据丢失，请参阅下面的 同步复制。
以编程方式访问群集的工作负载必须遵循客户端可用性重试逻辑，以保持可用性。
在正常运行情况下，服务有时会进行受控故障切换。 这些故障切换不会造成数据丢失，但会导致活动连接的重置。 重新连接失败的时间最长可达 15 秒。 有时，由于运行环境中的意外事件，可能会发生计划外的故障切换。 这可能需要长达 45 秒的时间，但一般不超过 30 秒。 例如，服务维护会触发受控故障切换。
高可用性功能
Databases for PostgreSQL 支持以下高可用性功能
| 功能 | 描述 | 对价 |
|---|---|---|
| 自动故障切换 | 所有集群的标准配置，可抵御区域或单一成员故障 | |
| 成员计数 | 最少 2 名成员。 默认为标准双成员部署。 双成员群集将自动从单个实例或区域故障中恢复（数据丢失最高可达滞后阈值）。 在新副本的数据同步过程中，群集会面临第二次故障，导致数据丢失。 三成员（请参阅 添加 PostgreSQL 成员 ）在同一故障期间可抵御两个成员的故障 | 同步复制需要三个成员 |
| 同步复制 | 在数据写入路径中增加远程成员同步功能，从而提高 RPO。 请参阅下面的 同步复制。 | 性能影响和成本。 |
| 只读复制 | 只读副本可在远程区域提供本地访问，提高对潜在网络延迟或连接问题的可用性。 | 所有写入请求必须专门指向与读取复制相关联的读写群集 |
同步复制 Databases for PostgreSQL
默认情况下，流式复制是异步的。 如果领导者崩溃，一些已提交的事务可能没有同步到副本，从而导致数据丢失。Cloud Databases 可确保将数据丢失保持在最低限度，避免大量数据丢失；不过，同步复制提供了确认事务的所有更改已同步到副本的能力。 这可确保整个集群的一致性。 这种一致性来自于通过 success 在返回连接客户端之前确认写入内容已写入辅助客户端。 有关同步复制的变量，请参阅 synchronous_commit 更改配置页面上的
同步复制将复制的可用性引入主写入路径。 如果没有副本确认写入，则会挂起，直到有副本可用。 这需要至少三个成员才能可靠运行，因为双成员部署不支持同步复制。 在启用同步复制之前，您_必须_横向扩展到至少三个成员。 请参见 添加 PostgreSQL 成员。
虽然可能性不大，但有可能出现多个副本同时不可用的情况。 如果发生这种情况，主数据库将无法完成任何写入操作，直到副本重新联机，从而有效地阻止数据库的所有写入流量。 在决定使用同步复制时，要权衡提高数据耐用性与潜在可用性问题的相对成本和效益。
配置同步复制会大大增加写入延迟，降低总体吞吐量。 为获得最佳性能，建议只在需要最高数据持久性的特定数据库或工作负载上使用同步复制。
灾后恢复架构
灾难恢复的一般策略是创建一个新数据库，如下面的 Restore 数据库。 新数据库的内容可以是灾难发生前创建的源数据库备份。 如果生产数据库可用，可使用时间点功能创建新数据库。
灾难恢复功能
Databases for PostgreSQL 支持以下灾难恢复功能：
| 功能 | 描述 | 对价 |
|---|---|---|
| 备份还原 | 根据先前创建的备份创建数据库；请参阅 管理 Cloud Databases 备份。 | 必须在整个工作负载中引用已恢复数据库的新连接字符串。 |
| 时间点复原 | 使用 时间点恢复 从实时生产中创建数据库 | 这只有在活动数据库可用且 RPO（灾难）在支持窗口内的情况下才有可能。 如果生产群集不可用，它就没有用了。 必须在整个工作负载中引用已恢复数据库的新连接字符串。 |
| 推广阅读复制 | 当计划在同一或远程区域发生灾难时，创建 只读副本。 推广只读副本，以便从灾难中恢复。 | 之前创建的读取副本必须可用。 必须在整个工作负载中引用已恢复数据库的新连接字符串。 |
规划灾难恢复
必须定期练习灾难恢复步骤。 在制定计划时，请考虑以下失败情况和解决办法。
| 失败 | 解决方法 |
|---|---|
| 硬件故障（单点） | IBM 提供的数据库可抵御区域内单点硬件故障，无需任何配置。 |
| 区域故障 | 自动故障转移（#postgresql-高可用性）。 数据库成员分布在各区之间。 配置三个成员将为多个区域故障提供额外的恢复能力。
同步复制会降低 RPO，但会牺牲性能。 |
| 数据损坏 | 备份还原。 将恢复的数据库用于生产或源数据，以纠正恢复数据库中的损坏。
时间点还原。 将恢复的数据库用于生产或源数据，以纠正恢复数据库中的损坏。 |
| 地区性失败 | 备份还原。 在生产中使用恢复的数据库。
推广阅读副本。 将只读副本升级为读写数据库。 在生产中使用恢复的数据库 |
应用级高可用性
通过网络和云服务进行通信的应用程序会受到瞬时连接故障的影响。 当与部署或 IBM Cloud 的连接暂时中断造成错误时，您需要设计应用程序重试连接。
由于 Databases for PostgreSQL 是托管服务，因此定期更新和数据库维护是正常运行的一部分。 这偶尔会导致数据库在短时间内不可用。 它还会导致数据库触发优雅的故障切换、重试和重新连接。 数据库需要很短的时间来确定哪个成员是副本，哪个是领导者，因此也可能会出现短暂的连接中断。 故障切换一般不超过 30 秒。
您的应用程序必须能够处理数据库的临时中断，对失败的数据库命令执行错误处理，并执行重试逻辑以从临时中断中恢复。
预计不会出现几分钟的数据库不可用或连接中断情况。 如果超过一分钟仍无法连接，请打开 支持案例 并提供详细信息，以便我们进行调查。
连接限制
Databases for PostgreSQL 将 数据库的最大连接数设置为 PostgreSQL 115。其中 15 个连接留给超级用户，用于维护数据库的状态和完整性，100 个连接供您和您的应用程序使用。 达到连接上限后，任何启动新连接的尝试都会导致错误。 为防止连接数过多，可使用连接池或扩大部署规模并增加连接上限。 更多信息，请参阅 管理 PostgreSQL 连接 页面。
您对 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。 不过，鉴于 PostgreSQL's PITR 功能，应仔细评估是否需要额外的备份。
- 数据库还原区域有一些限制--请阅读 管理 Cloud Databases 备份，以验证能否实现还原目标。
- 验证备份的保留期是否符合您的要求。
- 定期安排测试恢复，以验证实际恢复时间是否符合定义的 RTO。 请记住，数据库大小对还原时间有很大影响。 请考虑尽量缩短还原时间的策略，例如将大型数据库分解成更小、更易于管理的单元，以及清除未使用的数据。
- 验证 Key Protect 服务。
- 时间点复原
- 验证前面介绍的程序。
- 验证窗口中是否有所需的备份。
- 推广阅读复制
- 验证恢复区域中是否存在读取副本。
- 练习推广过程--在所需区域创建一个临时读取副本。 可以将临时副本升级为读/写，并进行一些测试，而对生产几乎没有影响。
要进一步了解客户和 IBM Cloud 之间在使用 Databases for PostgreSQL 方面的责任归属，请参阅 Cloud Databases 的共同 责任。
了解最新信息：IBM 通知
影响客户工作负载的更新通过 IBM Cloud 通知。 要随时了解与此服务相关的计划维护、公告和发布说明，请参阅 监控通知和状态 页面。 此外，请定期查看 版本政策 页面，了解有关生命周期结束版本和日期的最新更新。