对于应用程序，我们希望使用 Active Active 配置实现零数据库和应用程序停机时间。我们的 dB 是 Oracle
以下是我的问题：
- Oracle中怎样实现主动主动配置？
- 引入 Cassandra/HBase（或任何其他 No SQL dbs）云是否有助于实现零停机时间，还是仅用于快速检索大型数据库中的数据？
- 还有其他选择吗？
感谢并问候，Hiral
答案1
不存在零停机时间。设定一个现实的目标（比如五个九的正常运行时间），并围绕这个目标制定计划。如果你超额完成了目标，那当然很好，但承诺系统永远不会停机可能会让你陷入无法进行重大架构升级以继续以合理的成本维护系统的状态。
答案2
零停机时间（或接近停机时间）的主要考虑因素是更新活动的数量。更新（和删除）会以插入不会发生冲突的方式发生冲突。
级别 1。数据库几乎完全是只读的（例如用于内容管理系统）。这是最容易复制的。
级别 2。仅在单个节点上插入，然后分发到其他“只读”节点。
级别 3. 仅插入分片（例如，一个节点负责更新美洲，另一个节点负责更新欧洲，第三个节点负责更新亚洲...）。
级别 4. 在单个节点上插入/更新/删除，并分发到其他“只读”节点。
级别 5. 插入/更新/删除分片（例如，一个节点负责更新美洲，另一个节点负责更新欧洲，第三个节点负责更新亚洲...）。
第 6 级。在分发到所有其他节点的多个节点上进行插入。
级别 7. 在分发到所有其他节点的多个节点上进行插入/更新/删除。
在第 6/7 级，我会研究 NoSQL 解决方案。如果我认为分片机制可能无法持续较长时间，那么也许会考虑第 3 和第 5 级。
级别 7 几乎不可能实现高 9 可用性。最终，您将看到 A 尝试在节点 1 上更新内容，而 B 正在节点 2 上更新内容……然后您将失去节点 1。
答案3
这不一定是服务器故障问题。能否并行运行两个活动数据库取决于您的应用程序代码。诀窍是您必须设计代码，这样就不会发生两个位置同时更改记录的冲突。
一些设计想法：
- 使用 SYS_GUID 创建所有主键，而不是使用序列，因为如果不小心，序列可能会创建重复的键。
- 避免删除，因为它们似乎会导致复制中引用约束失败的最大麻烦。
- 尝试将可能相互干扰的事务分组到一个数据库上，并且只有当该数据库出现故障时才转移到备用数据库。
- 谨慎使用唯一约束，因为它们也往往会导致大量复制失败
至于如何设置，我们使用流进行复制，然后使用 Net8 的故障转移功能来处理服务器宕机。如果您愿意花大价钱，可以考虑 RAC。
答案4
我想说实现零停机时间是可能的。
GoldenGate 尝试通过双向复制提供此解决方案。您仍然需要解决主动-主动配置的冲突，这确实可能会成为问题，但这是一个很好的解决方案。
对于主/从，ChronicDB 可以进行实时更新，考虑复制而不会出现不一致的情况。
因此，挑战在于主动-主动与主从之间，对于这两种情况，都有很好的替代方案