本页介绍了 AlloyDB Omni 可用性架构，您可以使用这些架构来确保 AlloyDB Omni 数据库能够及时恢复，且数据丢失很少或没有数据丢失。
为确保业务连续性并尽可能减少数据丢失，高可用性 (HA) 和灾难恢复 (DR) 是 AlloyDB Omni 的关键数据保护策略。高可用性 (HA) 侧重于保持数据库可用性并尽可能缩短恢复时间目标 (RTO)，而灾难恢复 (DR) 侧重于从灾难性事件中恢复并尽可能缩短恢复点目标 (RPO)。
RTO 和 RPO 与业务需求保持一致，定义如下：
- RTO 是指数据库在业务遭受不可接受的后果（例如收入或生产力损失）之前可以关停或不可用的最长时间。
- RPO 是企业在影响业务要求之前可以承受的最大数据丢失量。例如，需要完整审核轨迹的库存系统可能要求零数据丢失。
AlloyDB Omni 提供以下可用性参考架构，这些架构可提供越来越高的可用性：
可用性机制
以下是确保可用性的主要机制：
- 数据库备份
- 数据库复制
数据库备份
数据库备份是数据保护的基本方面，涉及创建数据库数据文件的物理副本。不同的备份类型（完整备份、增量备份和差分备份）在恢复点目标 (RPO)、备份大小和时长以及恢复时间之间实现了不同的平衡。
为确保高效恢复并最大限度地减少系统故障造成的数据丢失，可靠的备份策略必须同时包含数据库备份和预写式日志 (WAL) 文件备份。定期（通常是每天）备份数据文件至关重要。您还必须备份 WAL 文件，这些文件会记录数据库修改，对于时间点恢复和在恢复期间保持数据完整性至关重要。
数据库复制
PostgreSQL 提供副本服务器，以提高可靠性。这些副本分为温备用副本（不接受应用连接）或热备用副本（以只读模式运行）。主数据库的更改会持续应用于副本，以使副本的数据保持最新状态。如果主数据库发生故障，则副本会升级为主数据库，并承担主数据库的职责。
数据库副本可以与主实例位于同一可用区或数据中心，也可以位于不同的可用区、不同的区域，或者位于这些位置的组合中。副本与主数据库之间的距离越远，在发送更改以使副本保持最新状态时，延迟就越大。对于跨遥远位置的部署，为了缓解大规模故障（例如区域性故障），数据复制通常以异步方式进行。这种方法可避免此类设置中可能出现的性能下降问题。
在高可用性部署中，副本通常部署在主数据库附近。例如，部署在同一数据中心内不同可用区的副本可实现较低的 RTO 和接近于零的 RPO。另一方面，在灾难恢复配置中，副本部署在不同的数据中心或区域中，具体取决于所需的防范服务中断的保护级别。这种方法会导致 RPO 较高（因为复制可能是异步的），并且 RTO 各不相同。
下表总结了 AlloyDB Omni 高可用性参考架构所用的机制：
| 功能 | Standard | 增强型 | 优质 |
|---|---|---|---|
| 备份 | ✔ | ✔ | ✔ |
| 可用区副本 | ❌ | ✔ | ✔ |
| 跨可用区副本 | ❌ | ✔ | ✔ |
| 区域级副本 | ❌ | ❌ | ✔ |
表格 1.支持的 AlloyDB Omni 可用性机制
数据库故障和恢复方案
数据库故障可能会在以下级别发生：
- 实例（节点或服务器）故障：数据库本身发生故障。
- 服务器故障：托管数据库的服务器发生故障。
- 可用区故障：托管服务器的整个数据中心发生故障。
- 区域故障：包含多个数据中心（可用区）的整个区域不可用，例如，由于洪水或大地震。
当事件数量减少且预防这些事件的成本增加时，发生灾难的可能性和风险会降低。企业必须确定自己的风险承受能力，并选择是接受潜在的中断，还是投资于更具弹性的架构来最大限度地降低风险。
下表总结了 AlloyDB Omni 参考架构支持的恢复方案：
| 灾难类型 | Standard | 增强型 | 优质 |
|---|---|---|---|
| 虚拟机/实例故障 | ✔ | ✔ | ✔ |
| 节点/服务器故障 | ✔ | ✔ | ✔ |
| 可用区故障 | ❌ | ✔ | ✔ |
| 区域性故障 | ❌ | ❌ | ✔ |
表 2.支持的恢复场景
考虑 AlloyDB Omni 数据库的业务目标，例如关键业务应用需要实现 99.99% 的可用性，并在恢复时实现零数据丢失。可用性参考架构的目标是满足 RTO 和 RPO 要求。
AlloyDB Omni 提供标准、增强型和高级可用性架构，可保护数据库免受计划内和计划外中断的影响，满足不同的业务需求。例如，开发环境可能使用包含备份的基本保护，而任务关键型应用可能采用高可用性和灾难恢复设置。
后续步骤
详细了解 AlloyDB Omni 高可用性参考架构：