适用于 Oracle 数据库工作负载的灾难恢复选项
本指南介绍了面向在裸金属解决方案环境中运行关键任务型 Oracle 数据库工作负载的用户提供的灾难恢复选项。
本指南假定您运行的是 Oracle 企业版。本指南中介绍的部分功能需要单独购买许可，而不仅仅是企业版许可。其中一些功能包括但不限于：
- Oracle Real Application Clusters
- Oracle Active Data Guard
- Oracle 高级压缩
- Oracle GoldenGate
请参阅您的 Oracle 许可协议，确定您在规划灾难恢复和高可用性时有权使用哪些功能。
应用 RTO 和 RPO
必须根据应用的恢复时间目标 (RTO) 和恢复点目标 (RPO) 确定 Oracle 数据库技术的灾难恢复方案。一般来说，RTO 描述的是系统可接受的停机时间，而 RPO 描述的是可接受的数据丢失量。随着这些值的降低，系统的成本和复杂性会增加。如需详细了解 RTO 和 RPO，请参阅灾难恢复规划基础知识。
标记为“RPO = 0”或“零数据丢失”的架构要求数据必须写入多个位置，然后才能被视为已“提交”到数据库。随着 RPO 越接近零，延迟时间就会成为一个问题。
除非在设计阶段妥善考虑，否则实现零数据丢失架构可能会对应用的整体性能产生不利影响。
高可用性与灾难恢复
在设计可靠的数据库架构时，高可用性和灾难恢复是相辅相成的概念。在本指南中，“高可用性”是指系统能够从系统上的单个故障或级联故障自动恢复。另一方面，灾难恢复是整体业务连续性计划的一部分，适用于可能导致整组系统不可用的更大规模故障。由于灾难发生时必须恢复的集成组件数量较多，因此灾难恢复涵盖的范围更广。
在设计可靠系统时，必须将高可用性视为“第一道防线”。高可用性数据库架构必须能够承受个别故障并继续运行，而不会导致应用停机。系统的高可用性组件必须包括但不限于：
- 为服务器、网络或存储硬件提供冗余电源
- 多个网络接口、交换机和电缆
- 冗余存储网络、控制器和磁盘设备
- Google Cloud 与裸金属解决方案区域扩展之间的容错合作伙伴互连
- Oracle RAC，以防止服务器故障导致数据库停用
灾难恢复设计必须包含用于从导致组件不可用的多个级联故障中恢复的流程。灾难恢复计划必须考虑以下事项：
- 区域性服务中断
- 自然灾害
- 导致应用的一个或多个组件完全停机的事故
Oracle 灾难恢复和高可用性工具
以下是一些 Oracle 灾难恢复和高可用性工具：
Oracle Real Application Clusters
Oracle Real Application Clusters (RAC) 用于水平扩展数据库工作负载，以便由多个数据库服务器提供服务。使用 RAC 的数据库允许在区域扩展内的服务器之间进行主动/主动配置。
RAC 通常用于为需要防范单个服务器故障的系统提供高可用性。由于采用“共享一切”方法（共享存储空间和共享网络）进行集群，因此在裸金属解决方案环境中运行的 RAC 集群必须位于单个裸金属解决方案 pod 中。这使得 RAC 成为高可用性问题的解决方案，但无法满足灾难恢复要求。
如需了解如何为裸金属解决方案设置 RAC，请参阅在裸金属解决方案上安装 Oracle RAC。
Oracle Recovery Manager
Oracle 恢复管理器 (RMAN) 是用于备份和恢复 Oracle 数据库的主要工具，因为它能够读取 Oracle 专有的数据文件格式。它可用于执行数据库克隆、时间点恢复，甚至恢复 Oracle 数据库中的单个表。
RMAN 是唯一可在数据库处于打开状态时用于备份的工具。它还用于维护可用于恢复的备份文件目录。
Oracle Data Guard
Oracle Data Guard 会将数据库复制到远程 RAC 集群或其他数据库安装。Data Guard 支持物理或逻辑配置中的备用数据库。
物理备用数据库是按块复制的，允许数据库的一个副本处于打开状态以进行写入；所有其他副本要么挂载（但未打开）以应用更改，要么处于只读打开状态以支持报告应用。
如需了解如何在裸金属解决方案上设置 Data Guard，请参阅在裸金属解决方案上部署 Oracle Data Guard。
FLASHBACK DATABASE
借助 Oracle 企业版的 FLASHBACK DATABASE 功能，管理员可以快速将数据库快退到特定时间点，而无需执行耗时的备份恢复操作。
在灾难恢复情境中，FLASHBACK DATABASE 通常与 Data Guard 结合使用，以便在故障切换操作期间更快地恢复数据库。系统会将失败的数据库闪回到与新主实例上的日志一致的特定时间点，并发送 redo，以便其能够完全重新同步。
Oracle GoldenGate
Oracle GoldenGate 是一款逻辑复制工具，通常用于实现主动/主动多站点部署或跨硬件平台迁移数据。使用 GoldenGate 时，源数据库上的 extract 进程会捕获在线重做日志中的更改，并将这些更改写入到跟踪文件，然后这些更改会传输到目标数据库。目标数据库上的 replicat 进程会将尾文件中的事务转换为 SQL，并在目标数据库上运行 SQL。
这种架构使 GoldenGate 成为一款强大的工具，可用于在数据库平台之间迁移数据或在数据复制时转换数据。与 Data Guard 不同，GoldenGate 需要在源系统和目标系统上安装和维护单独的软件。GoldenGate 无法用于同步复制，因为事务会被转换为 SQL 并应用于目标数据库。虽然 GoldenGate 可以将复制延迟降到最低，但仅 GoldenGate 无法保证 RPO 为零。
灾难恢复部署模型（仅限数据库）
Oracle 创建了极高可用性架构 (MAA) 框架，为您提供部署应用和数据库的推荐灾难恢复模型。
以下每种模型都提供特定的 RTO 和 RPO 目标：
这些模型会映射到特定的部署模式，以便在计划停机和非计划停机事件中满足 RPO 和 RTO 要求。必须对每个数据库工作负载进行可用性要求评估，并采用相应的模型进行设计。开发数据库通常使用保护级别低于生产数据库和质量检查数据库的模型。
青铜级模型适用于不需要以分钟为单位衡量 RTO 的数据库。银级及更高级别的模型包括在远程站点运行的备用数据库。每个模型都包含较低级别模型的功能。例如，青铜级模型使用备份和恢复概念，即使部署了备用数据库，也必须遵循这些概念。
Copper 模型
Copper 模型提供最少的部署，可将数据库备份到本地存储媒体，并复制到位于区域扩展之外的存储空间。此部署需要分两个阶段进行，但可以通过脚本使用 Google Cloud SDK 自动传输备份。
由于需要进行两阶段恢复，因此使用这种部署方式还会增加 RTO。RMAN 无法直接访问备份，因此必须先将备份移至 RMAN 可访问的位置，然后才能开始恢复。
| 服务中断 | 服务中断类型 | RPO : 恢复点目标 (RPO) | RTO : 恢复时间目标 (RTO) |
|---|---|---|---|
| 非计划性 | 可恢复的节点或实例故障 | 0 | 重启实例所需的时间 |
| 灾难：腐败 | 从 RE 转移出去的上一个归档日志、增量备份或完整备份 | 数小时（具体取决于数据库大小和分配给合作伙伴互连的带宽） | |
| 灾难：区域扩展故障 | 从 RE 传输出去的上一个归档日志、增量备份或完整备份 | 几天 / 几周，具体取决于恢复区域扩展所需的时间 | |
| 已计划 | 数据库补丁、操作系统 / 固件更新 | 0 | 更新和重启实例所需的时间 |
| 数据库重大升级 | 0 | 1-2 小时 |
青铜级模型
青铜版提供两种部署选项。它们都使用 Google Cloud 原生存储空间来保留数据库备份。
青铜部署 1：在区域性存储空间中进行备份
在此部署中，备份会直接写入到异地媒体。在大多数情况下，首选备份目的地是使用 Cloud Storage FUSE 的 Cloud Storage，该工具会将 Cloud Storage 存储桶显示为文件系统。
如需了解有关使用 Cloud Storage FUSE 的建议，请参阅“使用 NFS 和 Cloud Storage 进行 Oracle 备份”。您也可以使用 Google Cloud Filestore，它会向裸金属解决方案实例提供 NFS 共享。
下图展示了一个示例部署。
| 服务中断 | 服务中断类型 | RPO : 恢复点目标 (RPO) | RTO : 恢复时间目标 (RTO) |
|---|---|---|---|
| 非计划性 | 可恢复的节点或实例故障 | 0 | 重启实例所需的时间 |
| 灾难：腐败 | 上次归档日志、增量备份或完整备份 | 小时数，具体取决于数据库大小和分配给合作伙伴互连的带宽 | |
| 灾难：区域扩展故障 | 上次归档日志、增量备份或完整备份 | 几天 / 几周，具体取决于恢复区域扩展所需的时间 | |
| 已计划 | 数据库补丁、操作系统/固件更新 | 0 | 更新和重启实例所需的时间 |
| 数据库重大升级 | 0 | 1-2 小时 |
青铜部署方案 2：使用备份和灾难恢复服务进行备份
在此部署中，备份和灾难恢复服务用于在 Google Cloud 中存储备份。备份和灾难恢复功能提供永久增量备份方法，这些备份存储在由 Cloud Storage 支持的高性能媒体上，以实现长期保留。
与将备份存储在 Filestore 或 Cloud Storage 上相比，备份和灾难恢复功能还可缩短 RTO，因为它可以立即将数据库文件的映像提供给 Oracle 实例。挂载和迁移功能可快速将数据库上线，同时复制回生产存储媒体，从而大幅缩短 RTO。
下图展示了一个示例部署。
| 服务中断 | 服务中断类型 | RPO : 恢复点目标 (RPO) | RTO : 恢复时间目标 (RTO) |
|---|---|---|---|
| 非计划性 | 可恢复的节点或实例故障 | 0 | 重启实例所需的时间
如果使用 RAC，则为秒 |
| 灾难：腐败 | 上次归档日志、增量备份或完整备份 | 几分钟到几小时，具体取决于性能要求、数据库大小和分配给合作伙伴互连的带宽 | |
| 灾难：区域扩展故障 | 上次归档日志、增量备份或完整备份 | 几天 / 几周，具体取决于恢复区域扩展程序上线所需的时间或客户是否能够改用其他区域扩展程序。 | |
| 已计划 | 数据库补丁、操作系统 / 固件更新 | 0 | 更新和重启实例所需的时间 |
| 数据库重大升级 | 0 | 1-2 小时 |
银色
银牌模型引入了使用 Oracle Data Guard 进行数据库复制。Data Guard 提供实时数据库复制，其中一个或多个数据库充当备用数据库。由于 Data Guard 依赖于在数据库更改发生时传输和应用这些更改，因此 RPO 可能接近零。Silver 模型依赖于异步复制；使用同步复制可确保零数据丢失，但在区域之间发送数据所需的时间通常会导致应用响应时间超出可接受的限制。
如果主数据库在用户指定的时间段内不可用，Data Guard 的快速启动故障切换功能能够执行自动故障切换操作。配置由 Data Guard 观察器进程监控，该进程可以运行。
银色模型的好处在于，可确保在发生区域性故障时数据库可用，但随着应用服务器和数据库之间的网络延迟时间增加，故障切换和切换操作可能会影响应用性能。我们很少建议在不同区域运行应用和支持的数据库。虽然数据库的 RTO 可能不到 1 分钟，但在应用故障切换的情况下，服务可能需要几分钟到几小时才能完全正常运行。在大多数情况下，由于要迁移的组件数量较多，因此执行跨区域灾难恢复故障切换计划通常涉及手动流程。
在银牌方案中，您可能仍需要在每季度补丁活动期间安排停机或维护窗口。引入 Oracle RAC 可以缩短补丁或服务器故障导致的停机时间。
下图显示了一个示例配置。
图中的示例配置显示了在 us-west2 和 us-east4 区域中运行的 RAC 数据库。复制是使用异步 Data Guard 配置的。裸金属解决方案与 Google Cloud 之间的所有流量都会通过合作伙伴互连传输，跨区域流量则会通过 Google 网络骨干传输。应用服务器在每个区域中均配置，但通常会在灾难恢复区域关闭，直到声明故障切换事件。
| 服务中断 | 服务中断类型 | RPO : 恢复点目标 (RPO) | RTO : 恢复时间目标 (RTO) |
|---|---|---|---|
| 非计划性 | 可恢复的节点或实例故障 | 0 | 重启实例所需的时间
如果使用 RAC，则为秒 |
| 灾难：腐败 | < 60 秒 | 几分钟到几小时，具体取决于应用故障切换。 | |
| 灾难：区域扩展故障 | < 60 秒 | 几分钟到几小时，具体取决于应用故障切换。 | |
| 已计划 | 数据库补丁、操作系统 / 固件更新 | 0 | 更新和重启实例所需的时间。
如果使用 RAC，则为秒 |
| 数据库重大升级 | 0 | 1-2 小时
如果使用 |
黄金版
如果您担心白银级模型会丢失数据，可以选择黄金级模型，该模型使用远程同步实例向 Google Cloud Compute Engine 中运行的实例提供同步复制。
远程同步实例包含一个数据库控制文件和一组在距离主数据库地理位置较近的位置运行的备用重做日志。此实例配置为以低延迟同步接收重做，以便将所有更改记录在主数据库的区域扩展之外。然后，远程同步实例会将该重做提交到远程区域中的备用数据库，以便异步应用。
远程同步实例不是数据库的完整副本，因此无法处理应用流量。远程同步实例用于提供容错位置，以便同步写入数据库更改，从而实现零数据丢失解决方案。向远程同步实例执行同步复制时，只有在远程同步实例收到更改并将其提交后，主数据库才会提交事务。
Compute Engine 实例通常会被选为托管远程同步实例的候选实例。将远程同步实例放置在靠近主数据库的 Compute Engine 可用区，可最大限度地缩短延迟时间（通常低于 1.5 毫秒），并防止区域扩展中发生故障。
下图展示了一个示例部署。
图中的示例配置显示了在 us-west2 中运行的主 RAC 数据库，以及在 Compute Engine 中运行的应用。us-west2 中的 Compute Engine 实例正在运行远程同步实例，并接收同步重做。远程同步实例配置为异步将 redo 发送到在 us-east4 区域运行的 RAC 数据库。应用实例在 Compute Engine 的 us-east4 区域中配置，以便在发生灾难时处理应用流量。
| 服务中断 | 服务中断类型 | RPO : 恢复点目标 (RPO) | RTO : 恢复时间目标 (RTO) |
|---|---|---|---|
| 非计划性 | 可恢复的节点或实例故障 | 0 | 重启实例所需的时间
如果使用 RAC，则为秒 |
| 灾难：腐败 | 0 | 几分钟到几小时，具体取决于应用的区域故障切换。 | |
| 灾难：区域扩展故障 | 0 | 几分钟到几小时，具体取决于应用的区域故障切换。 | |
| 已计划 | 数据库补丁、操作系统 / 固件更新 | 0 | 更新和重启实例所需的时间。
如果使用 RAC，则为秒 |
| 数据库重大升级 | 0 | 1-2 小时
如果使用 |
铂金型号
白金版模型提供两种部署选项。每种部署选项都使用不同的技术提供保护，并且具有不同的 RTO 和 RPO 特性。
白金版部署 1：具有快速启动故障切换功能的 Data Guard
在黄金模型部署的基础上，白金部署 1 在本地区域中添加了第二个在 Compute Engine 实例上运行的 Data Guard 待机数据库。此配置会在主数据库与在 Compute Engine 中运行的备用数据库之间使用同步复制，从而在主区域内保证不会丢失任何数据。
创建区域内备用数据库后，数据库故障切换和切换操作便可在不影响应用的情况下进行。在数据库角色更改期间，根据 Oracle 的客户端注意事项配置的应用会自动重新连接到新的主数据库，而无需手动干预。正确配置的应用在故障切换事件期间的停机时间不到 2 分钟。
虽然 Compute Engine 中的备用数据库不会运行 RAC，但在作为主数据库运行时，其大小必须足以支持正常的应用流量。此实例可以以较小的形状运行，同时作为待机实例运行，并在发生故障切换事件时扩容，也可以始终以满载运行。在故障切换事件期间调整实例大小会对 RTO 产生负面影响，因为实例必须在调整大小操作期间重启。
在运行 Data Guard 代理且具有观测器的 Compute Engine 实例上配置快速启动故障切换。观测器运行一个基本 Oracle 客户端，该客户端连接到所有主数据库和备用数据库。如果观察器检测到主数据库发生故障，则会发起对某个备用数据库的故障切换。使用金级层部署时，必须将在 Compute Engine 上运行的备用数据库配置为首选故障切换目标。
Oracle 建议将观察器放置在与主数据库和备用数据库分开的区域。这可针对区域性故障和网络分区事件提供最佳保护。如果无法使用第三个区域，则必须在主要区域中安装观察器，并在与近场备用服务器位于不同可用区的情况下运行。
下图展示了一个示例部署。
图中显示的示例部署包含以下内容：
- 在
us-west2区域的裸金属解决方案服务器上运行 RAC 的主数据库。 - 在
us-west2区域的 Compute Engine 实例上运行的近场备用数据库。 - 在
us-east4区域的裸金属解决方案服务器上运行的远程备用数据库。 - 在
us-central1区域的 Compute Engine 实例上运行的 Data Guard 观测器。
为在 Compute Engine 实例上运行的区域内备用数据库配置同步复制，并将异步复制配置为远程区域。在每种情况下，重做操作都会从主数据库发送到备用数据库；重做操作不会从一个备用数据库转发到另一个备用数据库。观察器在第三个区域中配置，并与配置中的所有数据库保持连接。应用实例在主区域中配置，并连接到裸金属解决方案服务器上的主要数据库（或在故障切换和切换操作期间连接到 Compute Engine 实例上的数据库）。应用实例在 Compute Engine 的 us-east4 区域中配置，以便在发生灾难时处理应用流量。
| 服务中断 | 服务中断类型 | RPO : 恢复点目标 (RPO) | RTO : 恢复时间目标 (RTO) |
|---|---|---|---|
| 非计划性 | 可恢复的节点或实例故障 | 0 | 重启实例所需的时间
如果使用 RAC，则为秒 |
| 灾难：腐败 | 0 | < 60 秒 | |
| 灾难：区域扩展故障 | 0 | < 60 秒 | |
| 已计划 | 数据库补丁、操作系统 / 固件更新 | 0 | 更新和重启实例所需的时间。
如果使用 RAC，则为秒 |
| 数据库重大升级 | 0 | 1-2 小时
如果使用 |
白金版部署 2：GoldenGate 用于复制
铂金版部署 2 依赖于使用 Oracle GoldenGate 进行复制。因为 GoldenGate 不会在块级进行复制。它允许每个数据库独立处理读写应用会话。它会双向复制更改，从而支持主动/主动数据库配置。
在提交到主动/主动部署之前，必须对应用进行全面验证，并且您必须考虑冲突检测和解决。
与 Data Guard 不同，GoldenGate 需要在 Oracle 数据库服务器上安装和维护额外的软件。主动/主动部署通常需要复杂的架构和应用设计，才能充分利用多站点数据库部署。许多预打包应用都不支持这种架构。
由于逻辑复制的异步特性，依赖 GoldenGate 进行所有复制的部署无法支持零数据丢失 RPO。您可以部署在 Compute Engine 中使用 Data Guard 运行的本地备用数据库，以通过同步复制实现 RPO 为零。
下图展示了一个示例部署。
| 服务中断 | 服务中断类型 | RPO : 恢复点目标 (RPO) | RTO : 恢复时间目标 (RTO) |
|---|---|---|---|
| 非计划性 | 可恢复的节点或实例故障 | 0 | 重启实例所需的时间 |
| 灾难：腐败 | 秒转换为分钟
如果在每个位置都使用 Data Guard，则为 0 |
0 | |
| 灾难：区域扩展故障 | 秒转换为分钟
如果在每个位置都使用 Data Guard，则为 0 |
0 | |
| 已计划 | 数据库补丁、操作系统 / 固件更新 | 0 | 更新和重启实例所需的时间。
如果使用 RAC，则为秒 |
| 数据库重大升级 | 0 | 0 |