数据库的地理冗余：有哪些选择？

Question

我们需要在项目中提供地理冗余，它有大量的数据库（2-20 TB，具体取决于客户的具体要求）。我们持续从网络流入数据（例如每小时1-20 GB）。

目前，我们在RHEL（Linux）集群和SAN磁盘上使用Oracle（无RAC）和J2EE AppServer进行存储，简而言之就是一个DB，多个AppServ。

我们需要的是地理冗余。要求可以概括为，只要一切正常，我们产品的2个单独安装服务于2个不同的网络（每个服务一个）。当其中一个人倒下时，其他人应该同时服务。

附加说明：

• 我们需要一个支持SQL的关系数据库，因为仓储是基本需求之一。
• 不希望使用托管/云服务，例如：http://aws.amazon.com/vpc/，因为我们的客户在安全/隐私方面非常挑剔（即使托管/云服务提供这些服务）。

折扣应用程序逻辑只复制数据的选项有哪些？ STFW只提供了以下结果（因为我不是DBA专家，我的解释可能是错误的）：

• 令人惊讶的是，我找不到Oracle的地理冗余产品。 Oracle RAC适用于本地群集（更多用于水平可伸缩性而非冗余）。
• MySQL seems to support仅在分发时处于活动 - 备用状态。我需要积极主动。
• Guident似乎是基于某些Oracle产品提供服务，但没有产品。

谢谢 - Kashyap

Answer 1

我认为MySQL cluster应该适合你。 可以找到其他多主解决方案here。

Answer 2

在考虑优先使用复制的地理分布式数据库时，我们必须考虑优先选择A（可用性）或C（一致性）（存在WAN分区）之间的权衡，否则L（延迟）或C（一致性） （没有WAN分区）。

现在，如果您的应用程序能够容忍具有强大WAN主干的中等延迟，那么您应该保持一致性（这是一个dbms设计），否则，如果应用程序可以在偶尔出现故障并且WAN中的周期性断开连续可用性。

然后是如何确保应用程序的一致性，可用性和延迟要求的挑战。我所理解的复制dbms的一致性来自同步通信，其中提供可用性主要是降低一致性属性（NoSQL系统现在提供的内容）。但是，确保此类dbms的延迟要求对数据库和系统研究人员来说仍然是一个悬而未决的问题（我猜!!）。

在http://danweinreb.org/blog/improving-the-pacelc-taxonomy

了解详情

我最喜欢在整个社区面前看到这些问题。这些是真正的要求，我们仍然缺乏适当的解决方案。从像Oracle这样的系统迁移到新的或开放的架构并不是一个容易做出的决定。似乎像谷歌这样的巨头仍在寻找正确的答案。见http://research.google.com/archive/spanner.html