如何解决OCI上的跨区域oracle exadata活动活动群集
是否有人具有跨OCI区域设置Oracle Exadata Active-Active集群的经验？如果可以，您是否可以分享可能的最佳做法和指导原则。
目标是在两个OCI区域之间建立一个Active-Active Oracle Exadata集群，以便在一个区域出现故障时客户可以轻松访问另一个区域。它必须是自发的，没有任何停机时间。它不应该是只读的被动站点，并且如果需要，可以在任何给定点使用其他站点（R＆W模式）。要求是，不要浪费基础设施作为被动或待命者，而应该将所有基础设施用作主动服务的客户。
目标是在两个OCI区域之间建立一个Active-Active Oracle Exadata集群，以便客户可以轻松地同时同时访问两个区域。它必须是自发的，没有任何停机时间。
通常，可以使用 Dataguard 和 Goldengate ，但是考虑到App中间层自发访问数据库集群，我正在寻找特定的实现最佳实践和体系结构原则
解决方法
您提到“目标是在两个OCI区域之间建立一个Active-Active Oracle Exadata集群，这样，如果一个区域出现故障，客户就可以轻松访问其他区域。它必须是自发的，没有任何停机时间。” >
Active-Active或Active-Standby术语是从数据库语义中使用的，而不是用于Exadata群集（DB System / VM群集）。因此，我要提出一个问题，因为这里的目标是为Exadata数据库设计一个具有严格RTO目标的灾难恢复解决方案，并且您需要一个自动/自发且无停机的解决方案。
- 活动Dataguard：OCI / DBAAS允许客户配置跨区域Dataguard。 Dataguard（备用）数据库是Primary数据库的精确（块对块）副本。可以在活动数据卫士模式下配置Dataguard，这意味着备用数据库以只读模式打开。从本质上讲，这意味着可以将查询（选择）卸载到备用数据库中。
a。通过适当的计划和执行，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。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
