问题标签 [failover]

这是我想要实现的目标，但我对这个主题还不够熟悉，所以请多多包涵:)

我有一个服务器，一些设备连接到该服务器并定期上传一些数据。使用我们为速度和效率而设计的专有协议通过普通 TCP 套接字进行通信。每个这样的连接基本上都是一个会话，只要设备保持连接，它就会打开。我现在需要的是（1）设计故障转移机制和（2）扩大规模。一旦第一个实例失败，就会有另一个服务器节点启动。我一直在看 Terracotta 做一个轻量级的集群。但我不明白的是设备如何知道为第二个节点运行？我可能可以“教”他们尝试几个接入点。但这真的很痛苦，因为其中一些是我无法控制的。理想情况下，

现在。我想知道的第一件事是这样的工具在世界上是如何被调用的。其次 - 我需要简单的现成解决方案，最好是免费或开源并具有友好的商业许可。我们不使用任何重量级的容器，服务器实例是一堆与 Spring 连接的 POJO，一切都在一个 JVM 中运行。理想情况下，我想将这样的魔术盒放在其中一个节点上，为所有设备公开单个 IP/端口并进行一些配置。设置。这是可能的，还是我梦想在一个棘手的问题上找到廉价的解决方案？

我承认我有点小气，但我不想为通过镜像获得 SQL Server 自动故障转移所需的三台服务器而奔波，尤其是因为这三台服务器中的一台除了作为见证服务器之外什么都不做。

如果我设置了从主服务器到备份服务器的正常 SQL 复制（比如快照），我可以在我的 ASP.NET 应用程序中设置我的连接字符串以包含“故障转移伙伴=备份”吗？似乎客户端上的 ADO.NET 应该只尝试主节点，如果主节点不可用，则故障转移到备份。

或者这只适用于镜像？

（我喜欢镜像的想法，但是如果您不想为见证服务器付费，则必须手动将备份服务器切换为主服务器。）

谢谢！

我们目前有一个带有两个节点的故障转移 sql 集群。对于我们确定对业务至关重要的新大型项目，我们的开发团队正在请求一个新的 2 节点故障转移 sql 集群。

我们的服务器部门回应说他们不想为我们实施集群，而是雇用多个虚拟机，每个虚拟机都安装了 SQL 服务器，指向同一个磁盘，所以如果一个失败，他们要么将其移动到新主机，或者将另一个图像打开，因为它指向同一个磁盘，所以数据将保持不变。

我不是 sql server 专家，只了解基本级别的集群，但有些事情告诉我，他们提出的这个虚拟机“想法”并不完全是企业解决方案。对我来说，这听起来很像米奇老鼠。我要出去吃午饭吗？我可以用什么样的论据来支持我的观点？

我正在构建一个客户端-服务器应用程序，并且正在考虑向客户端添加故障转移，以便在服务器关闭时它会尝试连接到另一个可用服务器。是否有任何标准或规范涵盖服务器故障转移？我宁愿采用现有的标准，也不愿实施我自己的机制。

目前我正在研究现有应用程序的故障转移支持。

该应用程序使用 postgres 存储数据，但不使用任何特殊功能（视图/触发器等）。数据库更多的是配置存储而不是真实的数据存储。当应用程序启动时，它会将数据加载到内存中，并且很少只有在配置更改时才返回数据库。尝试为这个简单的任务配置 postgres 故障转移解决方案感觉有点矫枉过正。

是否有任何轻量级数据库内置了故障转移支持并且在生产中易于配置和使用？我的大部分数据模型都是单表，每分钟大约有 5 个事务。

我这里有一个特殊的情况。我已经在 Wintel 盒子中安装了 JBoss 5.1.0 作为服务。如果 JBoss 实例失败，服务将自行重启。

但是我找不到测试这种情况的方法。我杀死了运行 JBoss 的 JVM，但它没有重新启动服务。我需要让 JBoss 服务异常结束，这样我才能确保它再次重新启动。

简而言之，我需要一种方法让 JBoss 异常结束。

请帮忙。

我有一个使用 Hibernate 在 Oracle 10g 上运行的应用程序。我想知道是否可以使用 Oracle RAC 使应用程序在数据库故障方面具有高可用性，而无需在应用程序端进行任何代码更改。

我有两个用于应用程序的 Oracle RAC 节点，理想情况下希望能够拔出其中一个节点的插头并让应用程序继续运行，而不会出现任何异常到达应用程序代码。

我的应用程序向数据库发送选择、插入、更新和删除查询。

我一直在阅读有关透明应用程序故障转移的信息，但我发现的网站暗示只有选择查询可以透明地进行故障转移，并且所有其他类型的查询将导致抛出异常并且必须重新执行查询。我宁愿避免这种情况，因为我不想在我的代码库的每个部分添加额外的异常处理来进行数据库查询。

我有一个 Web 应用程序部署到三台运行 Apache、Tomcat 和前面的负载均衡器的服务器上。现在我正在考虑对它们进行聚类。

以下是我知道的常用选项和我的限制：

1. 基于序列化的会话集群：在我的例子中，应用程序在会话中使用了很多对象。所以我宁愿不使用这个解决方案。此外，在不久的将来，服务器的数量可能会增加到五台以上。

2. Terracotta：听起来很有趣，但购买企业许可证不是一种选择。

3. 使应用程序无状态：听起来很诱人，尽管它有点工作。我很想听听一些设计指南和经验。

还有其他建议吗？

我的主要目标是故障转移。

我正在研究将 Firebird 用于项目的可能性。

然而，一个潜在的问题是复制和故障转移，或者更确切地说，缺乏（主观）“好的”解决方案。Firebird 常见问题解答中列出了几种潜在的解决方案，但它们要么是 1) 以 Windows 为中心的；要么 2) 非常过时；3) 商业的；或 4) 功能不全。

我看到的唯一潜在选择是 FIBER，它看起来 1）不成熟；2) 可能死亡；3) 功能不全。

我已经了解了 DRBD 和 Heartbeat，这些解决方案看起来很有希望。如果您已经有 1) 设置复制的 Firebird 配置，我正在寻找您的反馈；和/或 2) 将 DRBD 与 Firebird 一起使用。

任何“陷阱”、建议、提示等？

谢谢！

MySQL 是否带有内置的自动故障转移功能？或者，是否有负载平衡器可以“检测”数据库是否处于活动状态......如果没有......将其发送到故障转移数据库？

我知道基本的 MySQL，但不知道为一个主数据库设计故障转移的最佳方法。