接下来，我编写了一个 shell 脚本，并将其安排在主站点 RAC 节点之一的 oracle crontab 中。使用存档日志序列号和上次生成的日志记录，该脚本将每 5 分钟唤醒一次，以确定自上次运行脚本以来，任一线程是否生成了其他存档日志。如果有，则生成并执行 ASM cp 命令以将这些存档日志复制到挂载到两个 RAC 节点的共享存储中。最后一个日志序列占位符将被更新，以备下次运行。
注意：我还将脚本存储在共享存储中，并将作业放在两个节点上的 oracle crontab 中，以便在必要时可以轻松地从任一节点执行它。
在 AWS 方面，我安排了一个非常简单的脚本，每 5 分钟运行一次 rsync 命令，以监控放置在主站点暂存区并同步到试点站点的新存档日志。我最终添加了逻辑以确保一次只运行一个作业。否则，在主站点上重做生成量高的时候，rsync 作业会在前一个作业完成之前启动相同日志的另一个副本。
一旦日志传输作业顺利运行，我就添加一个日志清除脚本，以便在主站点和备用站点上只维护给定天数的日志。
准备构建备用数据库！已对主数据库进行完整的 RMAN 备份并将其传输到 AWS 备用实例。在本例中，我使用 Tsunami-UDP 来管理此传输，因为它非常大。这种方法效果不错，但还
数据库恢复后，只需将备用实例指向主数据库存档日志被复制的位置，并通过现有的任何日志进行恢复即可。恢复后完成初始恢复后，我安排了一个脚本，每 30 分钟尝试进一步恢复一次。
我还向此恢复脚本添加了逻辑以检查延迟和应用率（v$recovery_progress 是一个很好的视图）。如果延 立陶宛电报数据 迟超过三个小时，则会发送电子邮件通知，以便在待机过程超过四小时 RPO 要求之前解决所有问题。我还向管理层发送了一份每日格式化的 HTML 报告，其中用绿色和红色进行颜色编码，让他们放心，指示灯实例是同步的并且正常运行！
一旦试点就绪，AWS 实例就会缩减到最小大小，以便能够跟上主站点数据库交易的高峰期。此时，它被视为可运行，等待灾难恢复测试。
这花了大约两周的时间来设置，管理层很高兴每天收到一份报告，显示指示灯备用数据库在最短四小时内与主生产数据库同步！
成功的灾难恢复策略需要坚如磐石的故障转移计划。毫无疑问，数据库是灾难恢复计划中的关键组件，但为了在灾难情况下成功运行生产操作，可能需要许多组件。应定期进行测试以确保灾难恢复计划的有效性。
在这种情况下，故障转移计划包括与数据库相关的以下活动：
确保主服务器上的所有可用日志都已转移到指示灯备用服务器
执行最终恢复并验证所应用的最近事务的时间
打开备用数据库作为主数据库（如果主站点已丢失，请启动新的主数据库的完整备份！）
启动监听器并检查应用程序使用的数据库服务的状态
对连接到数据库的客户端应用程序进行 DNS 更改
扩展 AWS 实例上的资源以满足生产工作负载