Oracle 数据库工作负载的灾难恢复选项

本指南介绍了在裸金属解决方案环境中运行任务关键型 Oracle 数据库工作负载的用户可用的灾难恢复选项。

本指南假定您运行的是 Oracle Enterprise Edition。本指南中介绍的部分功能需要单独许可，不包含在企业版许可中。这些功能包括但不限于：

• Oracle Real Application Clusters
• Oracle Active Data Guard
• Oracle Advanced Compression
• Oracle GoldenGate

在规划灾难恢复和高可用性时，请参阅您的 Oracle 许可协议，以确定您有权使用哪些功能。

应用 RTO 和 RPO

Oracle 数据库技术的灾难恢复必须根据应用的恢复时间目标 (RTO) 和恢复点目标 (RPO) 来确定。一般来说，RTO 描述的是系统可接受的停机时间，而 RPO 描述的是可接受的数据丢失量。随着这些值的减小，系统的成本和复杂性会增加。如需详细了解 RTO 和 RPO，请参阅灾难恢复规划基础知识。

被标记为“RPO = 0”或“零数据丢失”的架构要求在将数据视为已“提交”到数据库之前，必须将数据写入多个位置。随着 RPO 接近于零，延迟时间会成为一个问题。

如果在设计阶段未妥善考虑，实现零数据丢失架构可能会对整体应用性能产生不利影响。

高可用性与灾难恢复

在设计可靠的数据库架构时，高可用性和灾难恢复是互补的概念。在本指南中，高可用性是指系统能够自动从系统中的单个或级联故障中恢复。另一方面，灾难恢复是整个业务连续性计划的一部分，适用于可能导致整个系统组无法使用的大型故障。灾难恢复的范围更广，因为在发生灾难时，必须恢复许多集成组件。

在设计可靠的系统时，必须将高可用性视为“第一道防线”。高可用性数据库架构必须能够承受单个故障，并继续运行，而不会导致应用停机。系统的高可用性组件必须包括但不限于以下组件：

• 为服务器、网络或存储硬件提供冗余电源
• 多个网络接口、交换机和线缆
• 冗余存储光纤网、控制器和磁盘设备
• Google Cloud 与裸金属解决方案区域扩展之间的容错合作伙伴互连
• Oracle RAC，以防止服务器故障导致数据库无法正常运行

灾难恢复设计必须包含从导致组件无法使用的多个级联故障中恢复的流程。灾难恢复规划必须考虑以下事项：

• 区域性服务中断
• 自然灾害
• 导致应用的一个或多个组件完全中断的突发事件

Oracle 灾难恢复和高可用性工具

以下是一些 Oracle 灾难恢复和高可用性工具：

• Oracle 真正应用集群
• Oracle Recovery Manager
• Oracle Data Guard
• 闪回数据库
• Oracle GoldenGate

Oracle Real Application Clusters

Oracle Real Application Clusters (RAC) 用于横向扩缩数据库工作负载，以便由多个数据库服务器提供服务。使用 RAC 的数据库允许在区域扩展内的服务器之间实现主动/主动配置。

RAC 通常用于为需要防范单服务器故障的系统提供高可用性。由于集群采用“全部共享”方法（共享存储和共享网络），因此在裸金属解决方案环境中运行的 RAC 集群必须位于单个裸金属解决方案 pod 中。这使得 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 Enterprise Edition 的 FLASHBACK DATABASE 功能可让管理员快速将数据库回滚到特定时间点，而无需执行耗时的数据库恢复操作。

在灾难恢复方面，FLASHBACK DATABASE 通常与 Data Guard 结合使用，以便在故障切换操作期间更快地恢复数据库。将发生故障的数据库闪回至与新主数据库上的日志一致的特定时间点，并传送重做，以便该数据库能够完全重新同步。

Oracle GoldenGate

Oracle GoldenGate 是一种逻辑复制工具，通常用于实现主动/主动多站点部署或在硬件平台之间移动数据。使用 GoldenGate 时，源数据库上的 extract 进程会捕获在线重做日志中的更改，并将这些更改写入跟踪记录文件，然后将这些文件传输到目标数据库。目标数据库上的 replicat 进程将尾部文件中的事务转换为 SQL，并在目标数据库上运行该 SQL。

此架构使 GoldenGate 成为在数据库平台之间移动数据或在复制数据时转换数据的强大工具。与 Data Guard 不同，GoldenGate 需要在源系统和目标系统上单独安装和维护软件。GoldenGate 无法用于同步复制，因为事务会转换为 SQL 并应用于目标数据库。虽然 GoldenGate 可以最大限度地减少复制延迟，但仅靠 GoldenGate 无法保证 RPO 为零。

灾难恢复部署模型（仅限数据库）

Oracle 创建了 Maximum Availability Architecture (MAA) 框架，为您提供用于部署应用和数据库的推荐灾难恢复模型。

以下每种模型都提供特定的 RTO 和 RPO 目标：

• Copper 模型
• 青铜级模式
• 银色模型
• 黄金模型
• 白金级模式

这些模型会映射到特定的部署模式，以在计划内和计划外中断事件中满足 RPO 和 RTO。必须评估每个数据库工作负载的可用性要求，并使用相应的模型进行设计。开发数据库通常会使用比生产数据库和 QA 数据库保护级别更低的模型。

青铜模型适用于不需要以分钟为单位衡量 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：使用 Backup and DR 进行备份

在此部署中，Backup and DR Service 用于将备份存储在Google Cloud中。Backup and DR 采用永久增量备份方法，备份存储在由 Cloud Storage 提供支持的高性能媒体上，以便长期保留。

与将备份存储在 Filestore 或 Cloud Storage 中相比，Backup and DR 还提供更快的 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 观测器进程监控，该进程可以运行。

Silver 模式的优势在于，即使发生区域性故障，也能确保数据库可用，但故障切换和切换操作可能会影响应用性能，因为应用服务器与数据库之间的网络延迟会增加。我们很少建议在不同区域运行应用和支持数据库。虽然数据库的 RTO 可能不到 1 分钟，但应用故障切换可能需要数分钟到数小时才能使服务完全正常运行。在大多数情况下，执行跨区域灾难恢复故障切换计划通常涉及手动流程，因为需要迁移的组件数量较多。

在 Silver 模型中，您可能仍会在季度补丁活动期间遇到停机或维护窗口。引入 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 小时 如果使用 DBMS_ROLLING 执行升级，则为分钟。

黄金级模型

如果您担心白银模型中的数据丢失问题，可以选择黄金模型，该模型使用远距离同步实例向在 Compute Engine 中运行的实例提供同步复制功能。 Google Cloud

远距离同步实例包含一个数据库控制文件和一组在地理位置上靠近主数据库的备用重做日志。此实例配置为以低延迟同步接收重做，从而允许在主数据库的区域扩展之外记录所有更改。然后，远同步实例会将重做转发到远程区域中的备用数据库以进行异步应用。

远距离同步实例不是数据库的完整副本，因此无法处理应用流量。远距离同步实例用于提供一个容错位置，以便同步写入数据库更改，从而实现零数据丢失解决方案。对远端同步实例执行同步复制时，事务不会在主数据库上提交，直到远端同步实例收到并提交更改为止。

Compute Engine 实例通常会被选为托管远距离同步实例的候选对象。将远距离同步实例放置在靠近主数据库的 Compute Engine 可用区中，可最大限度地减少延迟（通常低于 1.5 毫秒），并防范区域扩展中的故障。

下图展示了一个示例部署。

该图中的示例配置显示了在 us-west2 中运行的主 RAC 数据库，以及在 Compute Engine 中运行的应用。us-west2 中的 Compute Engine 实例正在运行远距离同步实例，接收同步重做。远距离同步实例配置为将重做异步发送到在 us-east4 区域中运行的 RAC 数据库。应用实例在 Compute Engine 上的 us-east4 区域中配置，以便在发生灾难时处理应用流量。

服务中断	中断类型	RPO : 恢复点目标 (RPO)	RTO : 恢复时间目标 (RTO)
非计划内	可恢复的节点或实例故障	0	重启实例所需的时间 如果使用 RAC，则为秒
	灾难：损坏	0	几分钟到几小时，具体取决于应用区域故障切换。
	灾难：区域扩展失败	0	几分钟到几小时，具体取决于应用区域故障切换。
已计划	数据库补丁、操作系统 / 固件更新	0	更新和重启实例所需的时间。 如果使用 RAC，则为秒
	主要数据库升级	0	1-2 小时 如果使用 DBMS_ROLLING 执行升级，则为分钟数。

白金级模型

白金版提供两种部署选项。每种部署方案都使用不同的技术提供保护，并具有不同的 RTO 和 RPO 特征。

白金部署 1：使用快速启动故障切换的 Data Guard

白金部署 1 在黄金模型部署的基础上，在本地区域中添加了第二个在 Compute Engine 实例上运行的 Data Guard 备用数据库。此配置在主数据库与 Compute Engine 中运行的备用数据库之间使用同步复制，从而保证在主区域内不会丢失任何数据。

创建区域内备用数据库可让数据库故障切换和切换操作在不影响应用的情况下进行。在数据库角色发生变化期间，根据 Oracle 的客户端注意事项配置的应用会自动重新连接到新的主数据库，无需人工干预。在故障切换事件期间，配置正确的应用停机时间不到 2 分钟。

虽然 Compute Engine 中的备用数据库不运行 RAC，但它的大小必须足以在作为主数据库运行时支持正常的应用流量。此实例可以以较小的规格运行，同时作为备用实例运行，并在发生故障切换事件时扩大规格，也可以始终以完整容量运行。在故障切换事件期间调整实例大小会对 RTO 产生负面影响，因为在调整大小操作期间必须重启实例。

快速启动故障切换是在运行 Data Guard 代理的 Compute Engine 实例上配置的，该实例具有观测器。观测器运行一个基本的 Oracle 客户端，该客户端与所有主数据库和备用数据库建立连接。如果观察器检测到主数据库发生故障，则会启动到其中一个备用数据库的故障切换。使用 Gold 级部署时，必须将在 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 小时 如果使用 DBMS_ROLLING 执行升级，则为分钟。

白金级部署 2：使用 GoldenGate 进行复制

白金部署 2 依赖于使用 Oracle GoldenGate 进行复制。由于 GoldenGate 不在块级别进行复制。这样一来，每个数据库都可以独立处理读写应用会话。它会双向复制更改，从而实现主动/主动数据库配置。

在提交到有效/有效部署之前，必须对应用进行彻底验证，并且您必须考虑冲突检测和解决。

与 Data Guard 不同，GoldenGate 需要在 Oracle 数据库服务器上安装和维护其他软件。主动/主动部署通常需要复杂的架构和应用设计，才能充分利用多站点数据库部署。许多预打包的应用不支持这种类型的架构。

依赖 GoldenGate 进行所有复制的部署无法支持零数据丢失 RPO，因为逻辑复制是异步的。使用 Data Guard 在 Compute Engine 中运行的本地备用数据库可以部署为通过同步复制提供零 RPO。

下图展示了一个示例部署。

服务中断	中断类型	RPO : 恢复点目标 (RPO)	RTO : 恢复时间目标 (RTO)
非计划内	可恢复的节点或实例故障	0	重启实例所需的时间
	灾难：损坏	秒到分钟 如果在每个位置都使用 Data Guard，则为 0	0
	灾难：区域扩展失败	秒到分钟 如果在每个位置都使用 Data Guard，则为 0	0
已计划	数据库补丁、操作系统 / 固件更新	0	更新和重启实例所需的时间。 如果使用 RAC，则为秒
	主要数据库升级	0	0