我为一家为数千用户提供Web应用程序的小公司工作。 今年早些时候，他们有一台服务器托pipe一家公司。 我们最近在另一个地方购买了另一台服务器，希望有一天能够成为一个冗余的故障切换机器。 我明白如何处理mysql复制，我打算使用主 – 主复制设置，并使用rsync同步脚本和文件，但是我仍然关于如何configuration故障转移。 理想情况下，我希望这两台机器接受请求，如循环的DNS，但是如果一台机器停机，我不希望请求去那台机器。 我遇到的所有解决scheme都假设服务器在同一位置具有高可用性，这些服务器位于两个完全不同的位置，具有不同的公有IP地址。 任何帮助将是伟大的。 谢谢
通常情况下， 心跳 （ 心脏起搏器 ）或MMM用于pipe理将dynamic故障切换的IP资源。 为了有效地工作，您需要共享相同的网段。
如果服务器不在同一个物理空间中，即使有两个不同的互联网链路用于监视，也比一个数英尺的串行电缆的链路更易发生错误。
您将需要根据您的需求来评估风险和优先级。 你最重要的是什么？ 可用性或数据完整性？ 如果数据完整性不是优先级，则可能会自动进行故障切换，但是仍有风险分区。 CAP定理更详细地探讨了这一点。
一般不build议同时写入两个主服务器，因为可能会有ID冲突。 你可以configuration一个偏移量，但这是你的整个架构需要考虑的上下文。
根据我所了解的内容，我可能会倾向于数据完整性。 我会设置双主，只能从你的应用程序写入一个主IP。 如果您的主服务器出现故障，我将手动故障切换过程将Web应用程序重新指派给辅助数据库。
如果坚持自动进行故障转移，则可以编写一个脚本来考虑两个以上的故障点，并且可以通过附加的逻辑将数据风险降到最低。 然而，这个架构要复杂得多，而且你必须自己devise一些。
在MySQL集群（NDB）和Google的补丁之间有各种各样的技术，但没有完全消除CAP定理。