是否有人有跨 OCI 区域设置 Oracle Exadata Active-Active 集群的经验？如果是，您能否分享可能的最佳实践和指导原则。
目标是跨两个 OCI 区域设置一个主动-主动 Oracle Exadata 集群，以便在一个区域出现故障时客户可以轻松访问其他区域。它必须是自发的，没有任何停机时间。它不应该是只读的被动站点，如果需要，可以在任何给定点使用其他站点（R&W 模式）。要求是，不要将基础设施浪费为被动或备用，而是应将所有基础设施用作主动服务客户。
目标是跨两个 OCI 区域设置一个主动-主动 Oracle Exadata 集群，以便客户可以轻松地同时访问这两个区域。它必须是自发的，没有任何停机时间。
通常，已知Dataguard和Goldengate都可以使用，但我正在寻找考虑App Middle tier自发访问DB cluster的具体实现最佳实践和架构原则.
【问题讨论】：
标签： oracle oracle-cloud-infrastructure exadata
您提到“我们的目标是跨两个 OCI 区域建立一个 Active-Active Oracle Exadata 集群，这样如果一个区域出现故障，客户可以轻松访问其他区域。它必须是自发的，没有任何停机时间。”
术语 Active-Active 或 Active-Standby 用于数据库语义，而不是 Exadata 集群（数据库系统/VM 集群）。所以我要回答这个问题，因为这里的目标是为 Exadata 数据库设计一个 DR 解决方案，它具有严格的 RTO 目标，并且您想要一个自动/自发的解决方案，无需停机。
一个。通过适当的规划和执行，Oracle Data Guard 和 Active Data Guard 角色转换可以有效地减少停机时间，并确保在对业务影响最小的情况下恢复数据库环境。
b.当主数据库被认为丢失或不可恢复，或者预期的修复时间超过所需的恢复时间目标 (RTO) 时，将使用故障转移。在故障转移期间，主数据库在一个站点上脱机，而备用数据库作为主数据库联机。故障转移可以使用 Data Guard 快速启动故障转移完全自动化，也可以是手动的、管理员驱动的过程。快速启动故障转移消除了需要手动干预的过程中固有的不确定性，假设已采取类似措施将应用层故障转移到新的主数据库自动化。快速启动故障转移会在检测到中断后的几秒钟内自动执行数据库故障转移，并且可以在几秒钟内完成。
请注意 OCI/DBAAS 尚未实现快速启动故障转移，这意味着这无法通过控制台或 DBAAS API 完成。
请查看https://www.doag.org/formes/pubfiles/5256791/2013-DB-Larry_Carpenter-Session_Keynote__Best_Practices_for_Data_Availability_and_Disaster_Protection-Praesentation.pdf（第 38 页了解有关快速启动故障转移的更多详细信息）
使用 Goldengate 的客户可以配置 Active-Active 主备，其中主备都以读写模式打开。请注意，Goldengate 复制与 Dataguard 复制的不同之处在于 Goldengate 备用不是一个精确的块来阻止主副本的复制。 Goldengate 可以支持的特定对象数据类型也可能存在限制。 有关配置 Goldengate 以维护实时备用数据库和故障转移最佳实践的更多详细信息，请参阅
https://www.oracle.com/technetwork/database/availability/8399-goldengate-dataguard-1888654.pdf
请注意，目前在 OCI/DBAAS 中还没有针对 Goldengate 的产品，这意味着没有用于配置/设置 Goldengate 待机的控制台/DBAAS API。
【讨论】：