注意：

• 本教程需要访问 Oracle Cloud。要注册免费账户，请参阅开始使用 Oracle Cloud Infrastructure 免费套餐。
• 它对 Oracle Cloud Infrastructure 身份证明、租户和区间使用示例值。完成实验室后，请使用特定于云环境的那些值替换这些值。

使用 OCI Full Stack Disaster Recovery 为 Oracle HeatWave MySQL 自动执行冷灾难恢复

简介

Oracle Cloud Infrastructure Full Stack Disaster Recovery (OCI Full Stack DR) 只需单击一下即可编排全球 OCI 区域之间的计算、数据库和应用转换。客户可以自动执行恢复一个或多个业务系统所需的步骤，而无需重新设计或重新设计现有基础设施、数据库或应用，也不需要专门的管理或转换服务器。

Oracle HeatWave MySQL 是一项完全托管的数据库服务，部署在 Oracle Cloud Infrastructure (OCI) 中，支持希望快速部署安全云原生应用的运营商和开发人员。Oracle HeatWave MySQL 是 MySQL 产品，支持使用 HeatWave，这是一种集成的高性能内存中查询加速器。HeatWave 支持客户直接针对运营中的 MySQL 数据库运行复杂的分析，无需进行复杂、耗时且成本高昂的数据迁移，并可与单独的分析数据库集成。HeatWave 可显著提高分析和混合工作负载的 MySQL 性能。HeatWave 针对 OCI 进行了全面优化，Oracle HeatWave MySQL 由 OCI 和 MySQL 工程团队 100% 构建、管理和支持。

在本教程中，您将了解如何在 OCI 中为 Oracle HeatWave MySQL 自动执行冷灾难恢复。它概述了使用 OCI Full Stack DR 服务管理切换和故障转移流程的过程。

注：这种类型的灾难恢复 (Disaster Recovery，DR) 策略依赖于备份和还原机制，因此非常适合恢复时间目标 (Recovery Time Objectives，RTO) 和恢复点目标 (Recovery Point Objectives，RPO) 业务要求不高的非关键应用。

体系结构描述

本教程介绍在 OCI 虚拟机 (VM) 上运行的 WordPress 应用，该应用与 Oracle HeatWave MySQL 无缝集成。此外，该设置还利用 OCI File Storage 服务作为网络文件系统 (Network File System，NFS) 共享来存储 WordPress 内容。此共享存储已挂载到每个 VM，可确保立即同步访问整个环境中的所有新内容。

OCI 负载平衡器部署在公共子网中，可高效管理外部用户连接，并在 WordPress VM 中分配传入流量。

灾难恢复体系结构说明

WordPress 应用程序 VM 的 DR 策略涉及一种全面的方法，包括通过卷组复制来完整复制 VM 的每个引导卷，以及使用文件存储复制来确保 WordPress 内容的同步。

负载平衡器在远程区域中预配，可确保在切换或故障转移方案中将 WordPress VM 转换为远程区域时，它已准备好无缝处理流量。

对于 Oracle HeatWave MySQL，备份会定期复制到远程区域，以确保数据保护和灾难恢复就绪。可以使用定制脚本从一个应用程序 VM 启动此过程，该脚本可以通过 crontab 进行调度，以实现自动、一致的执行。

下图说明了将可用的最新 MySQL 备份从主区域复制到远程区域的工作流。

以下 crontab 设置已在 WordPress 应用程序 VM1 上的 opc 用户下配置为每 4 小时执行 mds_copy_bkp.py 脚本。这可确保自动备份同步到备用区域，从而改进灾难恢复：

15 */4 * * * /home/opc/mds_copy_restore_bkp/mds_copy_bkp.py mds01

此作业每隔 4 小时运行 15 分钟的脚本。

所有脚本都位于 GitHub 上，在以下各节中进行了详细介绍。

注：请确保根据您的业务要求安排此脚本（或类似脚本），以定期将 MySQL 备份复制到远程区域。如果没有此步骤，恢复过程可能会因备份在辅助区域中不可用而失败。

恢复如何工作？

执行计划切换后，角色将反转：主工作负载将在区域 2 中运行，备用工作负载将在区域 1 中运行。该体系结构将显示如下：

在当前设置中，我们利用 OCI 专用 DNS 服务管理将流量定向到活动 Oracle HeatWave MySQL 端点的 DNS 记录。在恢复过程中，会通过定制脚本更新此 DNS 记录，以反映新的 Oracle HeatWave MySQL，从而确保无缝故障转移和服务连续性。

下图说明了在备用区域中恢复最新 MySQL 备份的工作流。

此部署的恢复解决方案要求 OCI Full Stack DR 在恢复操作（例如故障转移或切换）期间运行一系列定制 Python 脚本。本教程中引用的脚本由 EMEA 云架构专家团队提供，可在此处获取： full-stack-disaster-recovery ，专为此 DR 解决方案量身定制。

本教程介绍了如何下载脚本以及如何在后续任务中使用这些脚本。

注：为通用指导提供了以下脚本。您可以使用自己的脚本，也可以根据公司策略和安全要求定制脚本。

整个教程中的定义和假设

• 区域：

  • 第 1 个区域是迪拜：迪拜最初将作为主要区域。但是，此角色将在切换过程中转换为备用，该过程将在后续任务中作为灾难恢复计划的一部分执行。

  • 第 2 区域是阿布扎比：阿布扎比最初将用作备用区域。此角色稍后将在切换过程后转换为主节点，在后续任务中将在灾难恢复过程中执行该过程。

• 区间：您可以随意将此部署和 OCI Full Stack DR 组织到符合 IT 治理标准的任何区间方案中。我们已选择将本教程的所有 OCI 资源组织在一个区间中。

WordPress 应用 VM 和 OCI 文件存储

本教程中使用的体系结构围绕 OCI 文件存储设计，以确保所有应用 VM 都可以共享访问相同的 WordPress 内容。

有关如何在 Linux 实例上正确挂载文件系统的更多信息，请参见 Configuring a File System to Automatically Mount (Linux Instances) 。

以下是用于在 WordPress 应用程序 VM 上挂载文件系统的 /etc/fstab 文件配置的示例。

xxx.xxx.xxx.xxx:/wordpress /var/www/html nfs nfsvers=3,noacl,nosuid,nofail 0 0

将 xxx.xxx.xxx.xxx 替换为位于区域 1 中的挂载目标的 IP 地址，以确保正确连接。

目标

本教程包含以下任务：

1. 任务 1：为灾难恢复准备环境
2. 任务 2：在两个区域中创建 DR 保护组 (DRPG)
3. 任务 3：将成员添加到 DR 保护组
4. 任务 4：在区域 2 中创建基本 DR 计划
5. 任务 5：自定义区域 2 中的切换计划
6. 任务 6：自定义区域 2 中的故障转移计划
7. 任务 7：在区域 2 中运行 DR 计划的预检查
8. 任务 8：在区域 2 中运行切换计划
9. 任务 9：在区域 1 中创建和自定义 DR 计划

任务 1：为灾难恢复准备环境

任务 1.1：创建卷组并启用复制

在区域 1 中为 WordPress 应用程序 VM 创建卷组，并确保在区域 2 中复制该卷组。确保每个应用程序 VM (WordPress) 的引导卷是卷组的成员，并且该卷组已复制到区域 2。

下图显示了创建的卷组，其中包含两个 WordPress 应用程序 VM 的引导卷，成功启用了到区域 2 的复制。有关更多信息，请参见 Creating a Volume Group 。

任务 1.2：为 WordPress 内容启用文件存储复制

1. 在区域 2 中，创建专门指定用于复制的文件系统。此文件系统将用于将数据从区域 1 无缝复制到区域 2。

   

2. 在区域 2 中，创建将在从区域 1 到区域 2 的恢复过程中使用的挂载目标。

   

   

3. 使用在步骤 1 中创建的文件系统，从区域 1 中的源 OCI 文件存储启用和配置复制。

   

   下图说明了到区域 2 的文件存储复制详细信息。

   

有关更多信息，请参见 File System Replication 。

任务 1.3：准备应用程序 VM 以运行定制自动化

1. 安装和配置 Oracle Cloud Infrastructure 命令行界面 (OCI CLI)。在本教程中，Oracle Linux 8 用于 WordPress 应用程序 VM。有关更多信息，请参见 Installing the CLI 。

2. 从 /home/opc 文件夹中的 GitHub 系统信息库 (mds_colddr_scripts ) 部署脚本。

3. 安装所提供脚本使用的熊猫和制表模块。

   pip install pandas
   pip install tabulate
   

4. 使用区域 1 中 Oracle HeatWave MySQL 的必要详细信息更新 config.csv 文件。

   • 将 MYSQL_DB_SYSTEM_OCID 替换为 Oracle HeatWave MySQL 的 OCID。您可以保留或定制 MySQL 标签以符合您的特定要求。
   • 将 COMPARTMENT_OCID 替换为 MySQL 系统所在区间的 OCID。
   • 将 PRIMARY_SUBNET_OCID 和 STANDBY_SUBNET_OCID 替换为两个区域中的子网 OCID。
   • 将 PRIMARY_DNS_VIEW_OCID 和 STANDBY_DNS_VIEW_OCID 替换为与管理 Oracle HeatWave MySQL 端点记录的专用 DNS 区域关联的专用 DNS 视图的 OCID。

   注：确保准确更新所有值。

在教程中，我们将使用相同的 VM 来运行用户定义的脚本。确保充当 DR 控制节点的 VM 已配置为运行命令。有关详细信息，请参阅使用运行命令和 Oracle Cloud Infrastructure Full Stack Disaster Recovery 调用定制脚本。

任务 1.4：为 OCI 全栈 DR 创建 OCI IAM 策略

为 OCI Full Stack DR 配置所需的 OCI IAM 策略，如以下文档所述。

• OCI Full Stack DR 策略

• 配置身份和访问管理 (Identity and Access Management，IAM) 策略以使用全栈 DR

任务 1.5：为 OCI Full Stack DR 管理的其他服务创建 OCI IAM 策略

OCI Full Stack DR 必须能够控制和管理其他关键 OCI 服务，例如计算、网络、存储和其他杂项服务。要为其他服务配置所需的 OCI IAM 策略，请参见 Policies for Other Services Managed by Full Stack Disaster Recovery 和 OCI IAM Policies 。

任务 2：在两个区域中创建 DR 保护组 (DRPG)

如果此应用程序堆栈的保护组尚不存在，请在区域 1 和区域 2 中创建 DR 保护组。

任务 2.1：在区域 1 中创建保护组

1. 转到 OCI 控制台并导航到 DR 保护组，如图 2.1 所示。

   1. 确保 OCI 区域上下文设置为区域 1（迪拜）。
   2. 单击 Migration & Disaster Recovery 。
   3. 单击 DR 保护组。

   
   图 2.1：导航到 DR 保护组

2. 在区域 1 中创建一个基本 DR 保护组 (DRPG)，如图 2.2 所示。在后面的步骤中将分配对等节点、角色和成员。

   1. 选择要创建 DRPG 的区间。
   2. 单击 Create DR protection group（创建 DR 保护组）以打开对话框。
   3. 为 DRPG 使用有意义的名称。
   4. 为 OCI 全栈 DR 日志选择 OCI 对象存储桶。
   5. 单击创建。

   
   图 2.2：在区域 1 中创建 DR 保护组所需的参数

任务 2.2：在区域 2 中创建保护组

1. 转到 OCI 控制台，导航到 DR 保护组，如图 2.3 所示。

   1. 确保 OCI 区域上下文设置为区域 2 (Abu Dhabi)。
   2. 单击 Migration & Disaster Recovery 。
   3. 单击 DR 保护组。

   
   图 2.3：导航到 DR 保护组

2. 在区域 2 中创建一个基本 DR 保护组 (DRPG)，如图 2.4 所示。在后面的步骤中将分配对等节点、角色和成员。

   1. 选择要创建 DRPG 的区间。
   2. 单击 Create DR protection group（创建 DR 保护组）以打开对话框。
   3. 为 DRPG 使用有意义的名称。
   4. 为 OCI 全栈 DR 日志选择 OCI 对象存储桶。
   5. 单击创建。

   
   图 2.4：在区域 2 中创建 DR 保护组所需的参数

任务 2.3：关联区域 1 和区域 2 中的保护组

将每个区域中的 DRPG 相互关联，并为主数据库和备用数据库分配对等角色。在执行任何 DR 操作/DR 计划过程中，OCI 全栈 DR 会自动更改主数据库和备用数据库角色；无需随时手动管理角色。

1. 转至 DR 保护组详细信息页。

   1. 确保 OCI 区域上下文设置为区域 1（迪拜）。
   2. 单击关联以开始该过程。

   
   图：开始 DRPG 关联

2. 按下图所示输入参数。

   1. 角色：选择主要角色。OCI Full Stack DR 将自动将备用角色分配给区域 2。
   2. 对等区域：选择创建其他 DRPG 的区域 2（阿布扎比）。
   3. 对等 DR 保护组：选择已创建的对等 DRPG。
   4. 单击关联。

   
   图：关联 DRPG 所需的参数

完成关联后，OCI Full Stack DR 将显示如下图中所示的内容。

1. 目前的主要同行 DRPG 是迪拜（区域 1）。
2. 当前的备用对等点 DRPG 是阿布扎比（区域 2）。

图：从单个 DRPG 角度显示对等关系

每当从全局角度显示所有 DR 保护组时，都可以找到相同的信息，如下图中所示。

1. 目前的主要同行 DRPG 是迪拜（区域 1）。
2. 当前的备用对等点 DRPG 是阿布扎比（区域 2）。

图：从全局 DRPG 角度显示对等关系

任务 3：将成员添加到 DR 保护组

在此任务中，我们将向区域 1 中的主 DRPG 添加以下 OCI 资源。

1. 将添加托管 WordPress 应用程序的两个计算实例作为移动 VM。此外，确保正确配置了高级选项中的文件系统部分。
2. 包含 WordPress 应用程序计算节点的引导卷的卷组。
3. 包含 WordPress 内容的 OCI 文件存储。
4. 主要负载平衡器。

任务 3.1：在区域 1 中向 DRPG 添加成员

1. 选择区域 1 中的 DRPG，如下图中所示。

   1. 确保 OCI 区域上下文为区域 1（迪拜）。
   2. 在“Region 1（区域 1）”中选择 DRPG。
   3. 选择成员。
   4. 单击添加成员以开始该过程。

   
   图：如何开始向区域 1 中的 DR 保护组添加成员

2. 为 WordPress 应用程序 VM 添加计算实例。

   1. 确认有关 DR 计划的警告。
   2. 输入计算作为成员资源类型。
   3. 选择托管 WordPress 应用程序的计算实例。
   4. 选择移动实例。
   5. 单击添加 VNIC 映射以选择在恢复期间分配给区域 2 中 VNIC 的 VCN 和子网。
   6. 单击显示高级选项。
   7. 在 Settings 中，选择 Retain fault domain（保留容错域）。
   8. 在文件系统中，根据您的设置完成导出映射部分，如下图中所示。

   
   图：添加 WordPress 应用程序 VM 所需的参数

   
   图：映射区域 2 中的 VNIC 所需的参数

   
   图：高级选项，保留容错域

   
   图：高级选项，文件系统映射

   
   图：已将计算实例添加到区域 1 中的 DRPG

   注：对 WordPress 应用程序 VM 的所有计算实例重复前面的子步骤。

   
   图：在区域 1 中向 DRPG 添加了两个计算实例

3. 添加包含 WordPress 应用程序 VM 的引导卷的块存储卷组。

   1. 确认有关 DR 计划的警告。
   2. 选择卷组作为成员资源类型。
   3. 确保选择了包含卷组的正确区间并选择卷组。

   
   图：为 WordPress 计算添加卷组所需的参数

   
   图：将 WordPress 计算的卷组添加到区域 1 中的 DRPG

4. 添加包含 WordPress 内容的 OCI 文件存储。

   1. 确认有关 DR 计划的警告。
   2. 选择文件系统作为成员资源类型。
   3. 确保选择了包含文件系统的正确区间并选择文件系统。
   4. 选择要用于区域 2 的目标可用性域。
   5. 为此文件系统选择源导出路径。在还原文件系统后，将在目标区域 2 中创建此导出路径。
   6. 选择区域 2 中用于为还原的文件系统创建导出的目标装载目标。

   
   图：为 WordPress 内容添加文件系统所需的参数

   
   图：WordPress 内容的文件系统已添加到区域 1 中的 DRPG

5. 添加 OCI 负载平衡器。

   在本示例中，我们将添加负载平衡器作为区域 1 中 DRPG 的成员。

   1. 确认有关 DR 计划的警告。
   2. 选择负载平衡器作为成员资源类型。
   3. 确保为负载平衡器选择了正确的区间，并选择要添加的负载平衡器。
   4. 选择要用于区域 2 的目标负载平衡器。
   5. 选择源后端集，这是 WordPress 应用程序 VM 使用的后端集。OCI 负载平衡器可以在多个应用之间共享，并且可能配置了多个后端集。在 DR 切换期间，只有在此处指定的后端集才会将其配置移动到备用区域。
   6. 选择目标后端集，这是在区域 2 中创建的空后端集。

   
   图：添加负载平衡器所需的参数

   
   图：已将负载平衡器添加到区域 1 中的 DRPG

任务 3.2：在区域 2 中向 DRPG 添加成员

1. 选择区域 2 中的 DRPG，如下图中所示。

   1. 确保 OCI 区域上下文为区域 1 (Abu Dhabi)。
   2. 在“Region 2（区域 2）”中选择 DRPG。
   3. 选择成员。
   4. 单击添加成员以开始该过程。

   
   图：如何开始向区域 2 中的 DR 保护组添加成员

2. 添加 OCI 负载平衡器。

   在本示例中，我们将添加负载平衡器作为区域 2 中 DRPG 的成员。

   1. 确认有关 DR 计划的警告。
   2. 选择负载平衡器作为成员资源类型。
   3. 确保为负载平衡器选择了正确的区间，并选择要添加的负载平衡器。
   4. 选择要用于区域 1 的目标负载平衡器。
   5. 选择源后端集，这是 WordPress 应用程序 VM 使用的后端集。OCI 负载平衡器可以在多个应用之间共享，并且可能配置了多个后端集。在 DR 切换期间，只有在此处指定的后端集才会将其配置移动到备用区域。
   6. 选择目标后端集，将在区域 2 中创建此后端集。

   
   图：添加负载平衡器所需的参数

   
   图：负载平衡器已添加到区域 2 中的 DRPG

任务 4：在区域 2 中创建基本 DR 计划

在本任务中，我们将创建与区域 2（阿布扎比）中的备用 DR 保护组关联的初始切换和故障转移计划。

这些计划的目的是将工作负载从主区域（区域 1）无缝转换为备用区域（区域 2）。作为任何 DR 操作的一部分，这两个区域中的 DR 保护组的角色将自动反转：区域 1 中的保护组将成为备用组，而区域 2 中的保护组在故障转移或切换后承担主角色。

OCI Full Stack DR 将使用从前面的任务中添加的成员资源派生的内置步骤预填充这些计划。以后将对这些计划进行定制，以便在恢复过程中管理特定于 Oracle HeatWave MySQL 的任务。

切换计划始终在保留备用角色的保护组中创建。由于区域 2（阿布扎比）目前是备用保护组，我们将开始在那里创建计划。

任务 4.1：创建 DR 计划

1. 通过在区域 2（阿布扎比）中选择 DRPG 创建基本计划

   1. 确保 OCI 区域上下文为区域 2 (Abu Dhabi)。
   2. 在区域 2 中选择备用 DRPG。
   3. 选择计划。
   4. 单击创建计划以开始该过程。

   
   图：如何开始在区域 2 中创建基本 DR 计划

2. 创建切换计划。

   1. 为切换计划输入简单但有意义的名称。这个名字应该尽可能短，但很容易一眼就能理解，以帮助减少危机期间的混乱和人为错误。
   2. 选择计划类型作为切换（计划）。

   
   图：创建 DR 切换计划所需的参数

3. 创建故障转移计划。

   按照相同的过程创建基本故障转移计划，如下图中所示。

   1. 输入故障转移计划的名称简单但有意义。这个名字应该尽可能短，但很容易一眼就能理解，以帮助减少危机期间的混乱和人为错误。
   2. 选择计划类型作为故障转移（计划外）。

   
   图：创建 DR 故障转移计划所需的参数

区域 2 中的备用 DR 保护组现在应该具有两个 DR 计划，如下图中所示。这些操作将处理从区域 1 到区域 2 的转换工作量。您将在区域 1 创建类似的计划，以在以后的任务中将工作量从区域 2 转换回区域 1。

图：显示区域 2 中必须存在的两个基本 DR 计划，然后再继续操作

任务 5：自定义区域 2 中的切换计划

在任务 4 中创建的基本 DR 计划包含预填充的恢复任务步骤，这些步骤内置在 OCI Full Stack DR 中，不包含管理特定于 Oracle HeatWave MySQL 的恢复任务的任何内容。此任务说明如何添加自定义 DR 计划组以及管理切换期间需要完成的任务的步骤：

• 在正常关闭应用程序 VM 后创建数据库备份，以确保数据一致性。
• 将最新数据库备份传输到远程 OCI 区域 2，以实现冗余和灾难恢复。
• 还原区域 2 中的最新数据库备份，为环境进行切换做好准备。
• 更新专用数据库 DNS 记录，使应用程序 VM 能够无缝连接到区域 2 中的数据库。
• 终止区域 1 中的源 MySQL 数据库。

任务 5.1：选择切换计划

导航到在任务 4 中创建的切换计划。

图：如何在区域 2 中开始自定义切换计划

任务 5.2：（可选）启用终止对象的 DR 计划组

默认情况下，切换计划中禁用了三个计划组，如下图中所示。禁用这些计划组可在测试期间提供保证，确保不会删除任何构件，并且在测试阶段出现问题时，可行的备份副本保持不变。

但是，这三个计划组用于终止（删除）以后任何 DR 操作将不再需要的对象。如果未启用这些计划组，在两个区域之间执行切换时，未使用的构件将继续累积，这可能会导致哪些计算实例、OCI 文件存储和卷组应处于活动状态混淆。

（可选）现在启用这些计划组将有助于避免在投入生产之前手动清理不必要的工件。这一主动步骤可以简化向生产的过渡，并维护更清洁、更易于管理的环境。

图：默认情况下禁用计划组

1. 要启用计划组，请从计划组名称右侧的上下文菜单中选择启用所有步骤。

   
   图：如何启用终止文件系统

   
   图：单击“启用”以验证。

   
   图：如何启用终止计算实例

   
   图：单击“启用”以验证。

   
   图：如何启用终止卷组

   
   图：单击“启用”以验证。

任务 5.3：对 DR 计划组重新排序

在更新负载平衡器后端集之前，必须在移至区域 2 的新 VM 上挂载文件系统。这可确保应用程序能够正确访问其所需的存储资源，从而在切换过程中实现平稳过渡。

图：显示初始切换计划顺序以及如何开始重新排序的屏幕截图

图：开始重新排序

1. 在负载平衡器 - 更新目标后端集之前移动文件系统 - 在计算实例上装载。

2. 单击保存更改。

图：最终切换计划单

任务 5.4：创建计划组以运行自定义脚本

首先添加自定义 DR 计划组，以便根据 MySQL 备份/恢复 DR 进程的特定需求定制 DR 工作流。

这些计划组将从区域 1 中的 WordPress VM1 调用必要的脚本，并应在启动 WordPress 应用程序 VM 之前放置在 DR 工作流中。这可确保在应用程序 VM 联机之前 MySQL 数据库已完全恢复且可运行。

应将以下定制计划添加到预填充的切换计划中：创建 MySQL Database 备份、复制 MySQL Database 备份、恢复 MySQL Database 备份、更新 MySQL Database DNS 和终止 MySQL Database 源。

1. 添加定制计划组以创建 MySQL 数据库备份。

   1. 单击添加组。
   2. 输入简单但描述性的计划组名称。在本示例中，我们将使用 Create MySQL DB Backup。
   3. 选择计划组将插入到 DR 计划中的位置。在此示例中，选择添加后以在内置计划组计算实例 - 启动之后插入用户定义的计划组。
   4. 单击添加步骤可打开对话框，在其中指定脚本以创建 MySQL 数据库备份。

   
   图：用于创建计划组“创建 MySQL 数据库备份”的参数

   在添加计划组步骤中，输入以下信息。

   1. 输入简单但具有说明性的步骤名称。在本示例中，我们将使用 Create MySQL DB Backup。与计划组名称相同。
   2. 选择包含运行此步骤的实例的区域。在此示例中，脚本将在区域 1 中的 WordPress 应用程序 VM1 上执行。
   3. 选择运行本地脚本。
   4. 选择目标实例，即区域 1 中的 WordPress 应用程序 VM1。
   5. 在脚本参数中，输入包含参数的脚本的完整路径。例如：/home/opc/mds_copy_restore_bkp/mds_create_bkp.py mds01。
   6. 在 Run as user 中，输入 opc。
   7. 单击添加步骤。

   
   图：用于创建“添加步骤 - 创建 MySQL 数据库备份”的参数

   单击添加。

   
   图：添加计划组“创建 MySQL 数据库备份”

2. 添加定制计划组以复制 MySQL 数据库备份。

   1. 单击添加组。
   2. 输入简单但描述性的计划组名称。在本示例中，我们将使用 Copy MySQL DB Backup。
   3. 选择计划组将插入到 DR 计划中的位置。在此示例中，选择添加后以在内置计划组创建 MySQL 数据库备份之后插入用户定义的计划组。
   4. 单击添加步骤可打开对话框，在其中指定脚本以复制 MySQL 数据库备份。

   
   图：用于创建计划组的参数复制 MySQL 数据库备份

   在添加计划组步骤中，输入以下信息。

   1. 输入简单但具有说明性的步骤名称。在本示例中，我们将使用 Copy MySQL DB Backup。与计划组名称相同。
   2. 选择包含运行此步骤的实例的区域。在此示例中，脚本将在区域 1 中的 WordPress 应用程序 VM1 上执行。
   3. 选择运行本地脚本。
   4. 选择目标实例，该实例是区域 1 中的 WordPress 应用程序 VM1。
   5. 在脚本参数中，输入包含参数的脚本的完整路径。例如：/home/opc/mds_copy_restore_bkp/mds_copy_bkp.py mds01。
   6. 在 Run as user 中，输入 opc。
   7. 单击添加步骤。

   
   图：用于添加步骤复制 MySQL 数据库备份的参数

   单击添加。

   
   图：添加计划组复制 MySQL 数据库备份

3. 添加定制计划组以还原 MySQL 数据库备份。

   1. 单击添加组。
   2. 输入简单但描述性的计划组名称。在本示例中，我们将使用 Restore MySQL DB Backup。
   3. 选择计划组将插入到 DR 计划中的位置。在此示例中，选择添加后以在内置计划组复制 MySQL 数据库备份之后插入用户定义的计划组。
   4. 单击添加步骤可打开对话框，在其中指定用于还原 MySQL 数据库备份的脚本。

   
   图：用于创建计划组 Restore MySQL DB Backup 的参数

   在添加计划组步骤中，输入以下信息。

   1. 输入简单但具有说明性的步骤名称。在本示例中，我们将使用 Restore MySQL DB Backup。与计划组名称相同。
   2. 选择包含运行此步骤的实例的区域。在此示例中，脚本将在区域 1 中的 WordPress 应用程序 VM1 上执行。
   3. 选择运行本地脚本。
   4. 选择目标实例，该实例是区域 1 中的 WordPress 应用程序 VM1。
   5. 在脚本参数中，输入包含参数的脚本的完整路径。例如：/home/opc/mds_copy_restore_bkp/mds_restore_bkp.py mds01 1 --config --switch。
   6. 在 Run as user 中，输入 opc。
   7. 单击添加步骤。

   
   图：用于添加步骤恢复的参数 MySQL 数据库备份

   单击添加。

   
   图：添加计划组还原 MySQL 数据库备份

4. 添加定制计划组以更新 MySQL 数据库 DNS。

   1. 单击添加组。
   2. 输入简单但描述性的计划组名称。在本示例中，我们将使用 Update MySQL DB DNS。
   3. 选择计划组将插入到 DR 计划中的位置。在此示例中，选择添加后以在内置计划组还原 MySQL 数据库备份之后插入用户定义的计划组。
   4. 单击添加步骤可打开对话框，在其中指定用于更新 MySQL 数据库 DNS 的脚本。

   
   图：用于创建计划组 Update MySQL DB DNS 的参数

   在添加计划组步骤中，输入以下信息。

   1. 输入简单但具有说明性的步骤名称。在本示例中，我们将使用 Update MySQL DB DNS。与计划组名称相同。
   2. 选择包含运行此步骤的实例的区域。在此示例中，脚本将在区域 1 中的 WordPress 应用程序 VM1 上执行。
   3. 选择运行本地脚本。
   4. 选择目标实例，该实例是区域 1 中的 WordPress 应用程序 VM1。
   5. 在脚本参数中，输入包含参数的脚本的完整路径。例如：/home/opc/mds_copy_restore_bkp/mds_update_dns.py mds01 demo.local mds01.demo.local --remote。
   6. 在 Run as user 中，输入 opc。
   7. 单击添加步骤。

   
   图：用于添加步骤更新 MySQL DB DNS 的参数

   单击添加。

   
   图：添加计划组 Update MySQL DB DNS

5. 添加定制计划组以终止 MySQL 源数据库。

   1. 单击添加组。
   2. 输入简单但描述性的计划组名称。在本示例中，我们将使用 Terminate MySQL DB Source。
   3. 选择计划组将插入到 DR 计划中的位置。在此示例中，选择 Add after 将我们的自定义计划组插入到内置计划组 File Systems - Remove from DR Protection Group 之后。
   4. 单击添加步骤可打开对话框，在其中指定用于终止 MySQL 数据库源的脚本。

   
   图：用于创建计划组的参数终止 MySQL 源数据库

   在添加计划组步骤中，输入以下信息。

   1. 输入简单但具有说明性的步骤名称。在本示例中，我们将使用 Terminate MySQL Source DB。与计划组名称相同。
   2. 选择包含运行此步骤的实例的区域。在此示例中，脚本将在区域 1 中的 WordPress 应用程序 VM1 上执行。
   3. 选择运行本地脚本。
   4. 选择目标实例，该实例是区域 1 中的 WordPress 应用程序 VM1。
   5. 在脚本参数中，输入包含参数的脚本的完整路径。例如：/home/opc/mds_copy_restore_bkp/mds_terminate_db.py mds01。
   6. 在 Run as user 中，输入 opc。
   7. 单击添加步骤。

   
   图：用于添加步骤终止的参数 MySQL 源数据库

   单击添加。

   
   图：添加计划组终止 MySQL 源数据库

6. （可选）添加定制计划组以停止 WordPress 应用程序。

   1. 单击添加组。
   2. 输入简单但描述性的计划组名称。在本示例中，我们将使用 Application - Stop。
   3. 选择计划组将插入到 DR 计划中的位置。在此示例中，选择添加后以在内置计划组负载平衡器 - 更新源后端集之后的末尾插入用户定义的计划组。
   4. 单击添加步骤可打开对话框，在其中指定用于停止应用程序的脚本。

   
   图：用于创建计划组的参数 - 应用程序 - 停止

   在添加计划组步骤中，输入以下信息。

   1. 输入简单但具有说明性的步骤名称。在本示例中，我们将使用 Application - Stop - VM1。
   2. 选择包含运行此步骤的实例的区域。在此示例中，脚本将在区域 1 中的 WordPress 应用程序 VM1 上执行。
   3. 选择运行本地脚本。
   4. 选择目标实例，该实例是区域 1 中的 WordPress 应用程序 VM1。
   5. 在脚本参数中，输入包含参数的脚本的完整路径。例如：/home/opc/fsdrscripts/wdp_stop.sh。
   6. 在 Run as user 中，输入 opc。
   7. 单击添加步骤。

   
   图：用于创建步骤应用程序的参数 - 停止 - VM1

   单击添加步骤以在 VM2 上添加第二个步骤以停止应用程序。

   
   图：添加步骤应用程序 - 停止 - VM2

   在添加计划组步骤中，输入以下信息。

   1. 输入简单但具有说明性的步骤名称。在本示例中，我们将使用 Application - Stop - VM2。
   2. 选择包含运行此步骤的实例的区域。在此示例中，脚本将在区域 1 中的 WordPress 应用程序 VM2 上执行。
   3. 选择运行本地脚本。
   4. 选择目标实例，该实例是区域 1 中的 WordPress 应用程序 VM2。
   5. 在脚本参数中，输入包含参数的脚本的完整路径。例如：/home/opc/fsdrscripts/wdp_stop.sh。
   6. 在 Run as user 中，输入 opc。
   7. 单击添加步骤。

   
   图：用于创建步骤应用程序的参数 - 停止 - VM2

   单击添加。

   
   图：添加计划组应用程序 - 停止

7. （可选）添加定制计划组以启动 WordPress 应用程序。

   1. 单击添加组。
   2. 输入简单但描述性的计划组名称。在本示例中，我们将使用 Application - Start。
   3. 选择计划组将插入到 DR 计划中的位置。在这种情况下，选择添加时间以在内置计划组文件系统 - 在计算实例上装载之后，在末尾插入用户定义的计划组。
   4. 单击添加步骤可打开对话框，在其中指定脚本以启动应用程序。

   
   图：用于创建计划组的参数 - 应用程序 - 启动

   在添加计划组步骤中，输入以下信息。

   1. 输入简单但具有说明性的步骤名称。在本示例中，我们将使用 Application - Start - VM1。
   2. 选择包含运行此步骤的实例的区域。在这种情况下，脚本将在区域 1 中的 WordPress 应用程序 VM1 上执行。
   3. 选择运行本地脚本。
   4. 选择目标实例，该实例是区域 1 中的 WordPress 应用程序 VM1。
   5. 在脚本参数中，输入包含参数的脚本的完整路径。例如：/home/opc/fsdrscripts/wdp_start.sh。
   6. 在 Run as user 中，输入 opc。
   7. 单击添加步骤。

   
   图：用于创建步骤应用程序的参数 - 开始 - VM1

   单击添加步骤以添加第二个步骤以在 VM2 上启动应用程序。

   
   图：添加步骤应用程序 - 开始 - VM2

   在添加计划组步骤中，输入以下信息。

   1. 输入简单但具有说明性的步骤名称。在本示例中，我们将使用 Application - Start - VM2。
   2. 选择包含运行此步骤的实例的区域。在这种情况下，脚本将在区域 1 中的 WordPress 应用程序 VM2 上执行。
   3. 选择运行本地脚本。
   4. 选择目标实例，该实例是区域 1 中的 WordPress 应用程序 VM2。
   5. 在脚本参数中，输入包含参数的脚本的完整路径。例如：/home/opc/fsdrscripts/wdp_start.sh。
   6. 在 Run as user 中，输入 opc。
   7. 单击添加步骤。

   
   图：用于创建步骤应用程序的参数 - 开始 - VM2

   单击添加。

   
   图：添加计划组应用程序 - 开始

已成功完成切换计划的自定义。

任务 6：自定义区域 2 中的故障转移计划

在此任务中，添加自定义、用户定义的 DR 计划组和步骤，以管理在故障转移期间需要完成的任务。

• 还原区域 2 中的最新数据库备份，为环境进行切换做好准备。

• 更新专用数据库 DNS 记录，使应用程序 VM 能够无缝连接到区域 2 中的数据库。

任务 6.1：选择故障转移计划

导航到在任务 4 中创建的故障转移计划。

图：如何在区域 2 中开始定制故障转移计划

任务 6.2：创建计划组以在区域 2 运行自定义脚本

首先添加自定义 DR 计划组，以便根据 MySQL 备份/恢复 DR 进程的特定需求定制 DR 工作流。

这些计划组将从 WordPress 应用程序 VM 调用必要的脚本，并应在重新启动 WordPress 应用程序 VM 之前放置在 DR 工作流中。这可确保在应用程序 VM 联机之前 MySQL 数据库已完全恢复且可运行。

应将以下定制计划添加到预填充的故障转移计划：恢复 MySQL Database 备份和更新 MySQL Database DNS 。

1. 添加定制计划组以还原 MySQL 数据库备份。

   1. 单击添加组以开始。
   2. 输入简单但描述性的计划组名称。在本示例中，我们将使用 Restore MySQL DB Backup。
   3. 选择计划组将插入到 DR 计划中的位置。在此示例中，选择添加后以在内置计划组计算实例 - 启动之后插入用户定义的计划组。
   4. 单击添加步骤可打开对话框，在其中指定用于还原 MySQL 数据库备份的脚本。

   
   图：用于创建计划组 Restore MySQL DB Backup 的参数

   在添加计划组步骤中，输入以下信息。

   1. 输入简单但具有说明性的步骤名称。在本示例中，我们将使用 Restore MySQL DB Backup。与计划组名称相同。
   2. 选择包含运行此步骤的实例的区域。在此示例中，脚本将在区域 1 中的 WordPress 应用程序 VM1 上执行。
   3. 选择运行本地脚本。
   4. 选择目标实例，该实例是区域 1 中的 WordPress 应用程序 VM1。
   5. 在脚本参数中，输入包含参数的脚本的完整路径。例如：/home/opc/mds_copy_restore_bkp/mds_restore_bkp.py mds01 1 --config。
   6. 在 Run as user 中，输入 opc。
   7. 单击添加步骤。

   
   图：用于添加步骤恢复的参数 MySQL 数据库备份

   请单击添加

   
   图：添加计划组还原 MySQL 数据库备份

2. 添加定制计划组以更新 MySQL 数据库 DNS。

   1. 单击添加组以开始。
   2. 输入简单但描述性的计划组名称。在本示例中，我们将使用 Update MySQL DB DNS。
   3. 选择计划组将插入到 DR 计划中的位置。在此示例中，选择添加后以在内置计划组还原 MySQL 数据库备份之后插入用户定义的计划组。
   4. 单击添加步骤可打开对话框，在其中指定用于更新 MySQL 数据库 DNS 的脚本。

   
   图：用于创建计划组 Update MySQL DB DNS 的参数

   在添加计划组步骤中，输入以下信息。

   1. 输入简单但具有说明性的步骤名称。在本示例中，我们将使用 Update MySQL DB DNS。与计划组名称相同。
   2. 选择包含运行此步骤的实例的区域。在此示例中，脚本将在区域 1 中的 WordPress 应用程序 VM1 上执行。
   3. 选择运行本地脚本。
   4. 选择目标实例，该实例是区域 1 中的 WordPress 应用程序 VM1。
   5. 在脚本参数中，输入包含参数的脚本的完整路径。例如：/home/opc/mds_copy_restore_bkp/mds_update_dns.py mds01 demo.local mds01.demo.local。
   6. 在 Run as user 中，输入 opc。
   7. 单击添加步骤。

   
   图：用于创建“添加步骤更新 MySQL 数据库 DNS”的参数

   单击添加。

   
   图：添加计划组 Update MySQL DB DNS

3. （可选）添加定制计划组以重新启动 WordPress 应用程序。

   1. 单击添加组。
   2. 输入简单但描述性的计划组名称。在本示例中，我们将使用 Application - Restart。
   3. 选择计划组将插入到 DR 计划中的位置。在此示例中，选择添加后以在内置计划组文件系统 - 在计算实例上装载之后插入用户定义的计划组。
   4. 单击添加步骤可打开对话框，在其中指定脚本以启动应用程序。

   
   图：用于创建计划组的参数 - 应用程序 - 重新启动

   在添加计划组步骤中，输入以下信息。

   1. 输入简单但具有说明性的步骤名称。在本示例中，我们将使用 Application - Restart - VM1。
   2. 选择包含运行此步骤的实例的区域。在此示例中，脚本将在区域 1 中的 WordPress 应用程序 VM1 上执行。
   3. 选择运行本地脚本。
   4. 选择目标实例，该实例是区域 1 中的 WordPress 应用程序 VM1。
   5. 在脚本参数中，输入包含参数的脚本的完整路径。例如：/home/opc/fsdrscripts/wdp_restart.sh。
   6. 在 Run as user 中，输入 opc。
   7. 单击添加步骤。

   
   图：用于创建步骤应用程序的参数 - 重新启动 - VM1

   单击添加步骤可添加第二个步骤以在 VM2 上重新启动应用程序。

   
   图：添加步骤应用程序 - 重新启动 - VM2

   在添加计划组步骤中，输入以下信息。

   1. 输入简单但具有说明性的步骤名称。在本示例中，我们将使用 Application - Start - VM2。
   2. 选择包含运行此步骤的实例的区域。在此示例中，脚本将在区域 1 中的 WordPress 应用程序 VM2 上执行。
   3. 选择运行本地脚本。
   4. 选择目标实例，该实例是区域 1 中的 WordPress 应用程序 VM2。
   5. 在脚本参数中，输入包含参数的脚本的完整路径。例如：/home/opc/fsdrscripts/wdp_restart.sh。
   6. 在 Run as user 中。输入 opc。
   7. 单击添加步骤。

   
   图：用于创建步骤应用程序的参数 - 重新启动 - VM2

   单击添加。

   
   图：添加计划组应用程序 - 重新启动

已成功完成故障转移计划的自定义。

任务 7：在区域 2 中运行预检查

已成功在备用区域 2 中创建切换和故障转移 DR 计划。这些计划支持 OCI Full Stack DR 将工作负载从区域 1 迁移到区域 2。后续任务涉及为切换和故障转移计划运行预检查，以确保准备就绪并验证转换过程。

任务 7.1：为切换计划开始预检查

为切换 DR 计划运行预检查。

1. 确保区域上下文设置为备用区域 2。
2. 确保在区域 2 中选择了正确的 DR 保护组，它应该是备用角色。
3. 单击切换计划名称。
4. 单击运行预检查。

图：显示如何运行切换计划的预检查

图：显示切换计划的已完成预检查

任务 7.2：开始故障转移计划的预检查

运行故障转移 DR 计划的预检查。

1. 确保区域上下文设置为备用区域 2。
2. 确保在区域 2 中选择了正确的 DR 保护组，它应该是备用角色。
3. 单击故障转移计划名称。
4. 单击运行预检查。

图：显示如何运行故障转移计划的预检查

图：显示故障转移计划的已完成预检查

任务 8：在区域 2 中运行切换计划

运行切换 DR 计划以开始使用 Oracle HeatWave MySQL 将 WordPress 应用程序从区域 1 转换为区域 2 的过程。

1. 确保区域上下文设置为备用区域 2。
2. 确保在区域 2 中选择了正确的 DR 保护组，它应该是备用角色。
3. 单击切换计划名称。
4. 单击执行计划。

此任务在区域 2 中运行切换计划。

1. 取消选择启用预检查，因为它们已在任务 7 中执行。
2. 单击 Execute DR plan 开始。

图：显示如何运行切换计划

图：显示正在进行的切换计划

监视切换计划，直到将完整的工作量从区域 1 完全转换为区域 2。

切换计划大约在 52 分钟内成功完成。

图：显示已完成的切换计划执行。

图：显示已完成的切换计划执行。

任务 9：在区域 1 中创建和自定义 DR 计划

随着 OCI Full Stack DR 成功完成切换，区域 2 现在承担了主区域的角色，而区域 1 已转换为备用区域。

按照任务 1 到 8 中详细介绍的相同方法，继续为区域 1（现在用作备用对等区域）在 DR 保护组中创建和定制切换和故障转移计划。

图：屏幕截图中显示了区域 1 中的已创建计划

图：屏幕截图中显示了区域 1 中的切换计划

图：屏幕截图中显示了区域 1 中的故障转移计划

后续步骤

有关详细信息，请参阅相关链接部分中的 OCI Full Stack DR 和 Oracle HeatWave MySQL 文档。

相关链接

• Oracle Cloud Infrastructure (OCI) 全栈灾难恢复

• Oracle HeatWave MySQL

• OCI Full Stack Disaster Recovery

• HeatWave MySQL

• 加入 #full-stack-dr 闲置通道

确认

• 作者 — Antoun Moubarak（从超大规模扩展到 OCI 专家）

• 贡献者 — Suraj Ramesh（OCI 全栈灾难恢复产品经理）

更多学习资源

浏览 docs.oracle.com/learn 上的其他实验室，或者访问 Oracle Learning YouTube 渠道上的更多免费学习内容。此外，请访问 education.oracle.com/learning-explorer 成为 Oracle Learning Explorer。

有关产品文档，请访问 Oracle 帮助中心。

---

标题和版权信息

Automate Cold Disaster Recovery for Oracle HeatWave MySQL using OCI Full Stack Disaster Recovery

G24415-01

January 2025

Copyright ©2025,

Oracle 和/或其关联公司。