对于一个应用程序，我们希望使用Active Activeconfiguration来实现零数据库和应用程序停机。 我们的dB是Oracle
以下是我的问题：
感谢和问候，Hiral
没有零宕机的事情。 设定一个现实的目标（比如说，五个9的正常运行时间），然后围绕这个目标进行规划 如果你击败了你的目标，那么很好，但是承诺一个永远不会下降的系统会陷入一个不可能进行重大的架构升级，继续以合理的代价维持系统的状态。
零（或接近）停机时间的主要考虑因素是更新活动的数量。 更新（和删除）以插入的方式冲突。
级别1.数据库几乎是完全只读的（例如用于内容pipe理系统）。 这是最容易复制的。
级别2.仅在分配给其他“只读”节点的单个节点上插入。
只有插入分片（例如，一个节点需要更新美国，另一个欧洲，第三个亚洲…）。
级别4.在分配给其他“只读”节点的单个节点上插入/更新/删除。
级别5.插入/更新/删除分片（例如，一个节点将更新为美国，另一个为欧洲，第三个为亚洲…）。
级别6.插入到分布于所有其他节点的多个节点上。
级别7.插入/更新/删除分布到所有其他节点的多个节点上。
在6/7级我会研究NoSQL解决scheme。 也许3级和5级，如果我通过分拆机制可能无法持续更长的时间。
7级实际上不可能实现高的可用性。 最终你会得到人A试图更新在节点1上的东西，就像人B在节点2上更新它一样…然后你将失去节点1。
这不一定是一个服务器错误的问题。 能够并行运行两个活动数据库将取决于您的应用程序代码。 诀窍是你必须devise你的代码，这样就不会有与两个位置同时改变的logging冲突。
一些devise思路：
至于如何设置它，我们使用stream进行复制，然后使用Net8的故障转移function来处理服务器closures。 如果你想支付大笔钱，你可以看看RAC。
在Oracle中实现主动/主动configuration的最简单方法是使用Oracle RAC（Real Application Cluster）。 RAC文档可以在这里find。
RAC还可以与其他Oracle高可用性工具（如Data Guard或Streams）结合使用。 HA文档可在这里find 。
请记住，某些维护操作可能要求您closures一个节点（如果不是全部）。
我会说可以实现零宕机。
GoldenGate试图提供双向复制的解决scheme。 你仍然需要冲突解决主动 – 主动configuration，是的，这可能成为一个问题，但这是一个很好的解决scheme。
对于主站/从站，ChronicDB可以进行实时更新，从而对复制进行计数而不会出现不一致。
所以挑战是积极主动型还是主从型之间，这两者都有很好的select
将介绍Cassandra / HBase（或任何其他无SQL dbs）云帮助在零宕机时间，或者它只是快速检索大数据库中的数据？
Cassandra可以提供帮助，因为它允许通过滚动重启进行重大升级（每个节点连续升级）。 大多数好的Cassandra库支持在执行群集更改时自动将请求发送到可访问的节点。 使用复制因子3和“仲裁”的一致性级别，即使在保持一致性的情况下，也可以通过滚动重新启动进行正常运行。