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