对数据库的故障转移支持答案

【问题标题】：Failover support for a DB对数据库的故障转移支持
【发布时间】：2011-09-12 09:29:05
【问题描述】：

我们目前正在评估不同数据库中的故障转移支持。
我们之前使用的是 HSQLDB，但它似乎没有集群/复制支持。

我们的要求只是拥有两台数据库服务器，一台仅用于同步备份，但如果主服务器宕机，那么从服务器应该自动开始充当主服务器。

有没有人针对这种用例评估过 MySQL、PostgreSQL 或任何其他数据库服务器？

编辑：我们曾考虑使用 MySQL 集群，但现在看来它是在 GPL 许可下，我们将无法使用它。谁能建议一个可以使用的同步复制/集群解决方案？我们目前正在使用 HSQL，因此在集群模式下使用 HSQL 的解决方案对我们来说是理想的，但我们愿意改变。

【问题讨论】：

真正的问题是什么？如果有人在故障转移系统中使用 MySQL / Postgres 或其他数据库？我猜很多人都有，但你感兴趣的细节是什么？
是的，我只是在评估构建故障转移系统。唯一的要求是当主节点宕机时集群可以继续工作。辅助节点应自动开始服务传入请求。最重要的是，从数据应该同步更新，这样主数据和从数据之间就没有滞后。
属于DBA SE。

【解决方案1】：

不确定这是否在大多数 FOSS 类型的人想要的价格范围内 :-) 但我们使用 DB2 9.7 正是为了这个目的（实际上，我们主要在大型机上使用 DB2/z，但有些客户喜欢小型系统的 DB2/LUW (Linux/UNIX/Windows) 选项）。

DB2 内置了高可用性 (HA) 功能，您可以使用db2haicu，DB2 高可用性实例配置实用程序（一定会喜欢蓝色巨人使用的那些首字母缩写词生成器）来相对轻松地进行配置。

它是您想要的主动/被动，尽管 DB2 肯定能够进行主动/主动设置以实现负载平衡。

我们在低端最熟悉的特定设置（除大型机外的所有设置）实际上是共享磁盘设置，HA 仅适用于 DBMS 资源而不适用于数据，但您可以使用 DB2 复制来分离数据功能也很好。

我们有一个客户端（至少）使用 Q 复制，这是一种非常低延迟的复制方法，接近同步但不完全同步。 DB2 实际上也提供了真正的同步复制。

DeveloperWorks 有 an interesting article 了解这一切是如何结合在一起的，以及各种选项。

【讨论】：

【解决方案2】：

为了完整性，H2 database has some clustering support，但与 MySQL 和 PostgreSQL 相比，它的功能非常有限，它实际上只是故障转移。我会先看看HA-JDBC。

【讨论】：

我们只需要故障转移，而且似乎 H2 也可以免费用于商业产品（MySQL 集群让我们失败的地方 :-()。虽然，我还没有完全评估 H2，但我觉得它可能对我有用，所以我将赏金奖励给你。请回来查看并尝试回答我在接下来的几天内可能对 H2 提出的任何疑问。谢谢。

【解决方案3】：

有一个与 HSQLDB 配合使用的第三方产品：

【讨论】：

是的。在 Hibernate 或任何其他 ORM 中，只需使用正确的 URL 形式。
这似乎不是一个正在积极开发的项目，您会考虑将其用于关键的生产部署
它仍在开发和支持中（开发页面显示最近的 SVN 更新）。一旦这种类型的软件可以工作并且报告的错误已得到修复，就没有什么可添加的了。除此之外，部署问题只有你自己可以判断，因为变量很多。
我浪费了一天的时间试图让它工作，但意识到它使用的是相当旧的 jgroups 版本 2.6.x，而我们使用的另一个库依赖于版本 2.12.x，我认为是与未积极开发的项目合作时的问题 :-( 上一次发布是在 2 年前，有人如何使用这样的项目进行重大部署？
您对 jar 依赖问题是正确的。但除此之外，在没有报告重大新错误的情况下，发布几次错误修复后，可能会实现高质量。

【解决方案4】：

Stackoverflow 资源
MySQL 支持开箱即用的复制：请参阅 MySQL 的这个问题：Scaling solutions for MySQL (Replication, Clustering)

PostgreSQL 也支持复制，请参阅此问题：PostgreSQL replication strategies

如果您的要求很简单，MySQL 也可以工作
我使用 MySQL 是一个简单的主-主故障转移方案，使用我在High Performance MySQL 中阅读的设置。如果你热衷于使用 MySQL，我强烈推荐这本书。

它对我来说效果很好，因为我只想要一个简单的故障转移。
如果您的用例同样简单。它会运作良好。

【讨论】：

非常感谢。我有几个问题：你们的系统有同步数据复制吗？每当主服务器出现故障时，您的辅助服务器是否会自动启动？从访问您的数据库的应用程序中，您是否只需要配置一台服务器并且集群负责处理数据库服务器的故障？
是的，是的，是的。但是，如果您只是按照那里的步骤阅读我链接的书，一切都会解决。
主-主复制是许多邪恶事物的根源。 db 连接handelt 中的故障转移在哪里？在应用程序本身？在心跳故障转移环境中。 slave 获取 master 的 ip，因此它的应用程序是透明的。
我在您提到的 booke 中发现了几个复制拓扑，但它们都不是同步的。它们都依赖于基于行/语句的 mysql 复制，这本质上是异步的。你用的是 mysql 集群而不是 mysql 复制吗？
我找不到你说的复制，我只好用 MySQL 集群了。

【解决方案5】：

用于服务器位于同一位置的简单故障转移。你可以使用DRBD和Heartbeat。

简而言之：DRBD 将数据同时存储在两台服务器上。对系统完全透明。使用心跳，备用服务器对主服务器进行检查，如果无法访问，它将接管资源，挂载它并启动数据库守护程序。（适用于 mysql、postgres，很可能适用于大多数其他守护进程）

【讨论】：

感谢您的回复。从 DRBD 文档来看，DRBD 似乎依赖于磁盘更改来同步跨 DB 的更改。然而，在我们的例子中，数据预计主要在内存中。我们的主要要求之一是同步数据复制，这意味着当主服务器的数据发生任何变化时，备份服务器的数据应该立即更新。
撇开 Ashish 在上面的评论，这似乎有点困惑。 DRBD 和 Heartbeat 提供了构建集群的工具——它们不是集群解决方案。特别是，他们对 DBMS 所需的记录锁定没有可见性意识，尽管这并没有明确阻止被动节点充当数据接收器 - 但这仍然留下了自动故障转移和解决 slpit-brain 的问题。不是一个好的答案。
一个简单的故障转移....阅读老兄的话。事务完成时数据库存储到文件中，因此将其复制到第二个节点。在不同的条件下不会出现交易问题和脑裂……这样的设置已经运行了多年，而有了 heartbeat v2，在节点之间移动资源变得更加简单。