抱歉，这个问题很蠢，但我还是个新手。
我有两台 Linux 服务器：其中一台运行 Apache 和 MySQL，为我的 Web 平台提供服务（主服务器）；另一台用作复制服务器，提供故障转移功能（从属服务器）。这两台机器由不同的托管商和 DNS 服务器维护。
我在互联网上找到的所有实现此目的的信息都是基于通用虚拟 IP 或位于同一 LAN 的服务器解决方案（如 Heartbeat、RedHat、DRBD、协议 CARP 等集群），这对我来说并不适合。
有没有解决方案可以监控服务器状态，如果服务器无响应，则从主服务器切换到从服务器，修复后再切换回来？我猜应该通过 DNS 故障转移来实现。还是只有流量平衡才能帮助我？
答案1
考虑具有此类故障转移功能的 Amazon AWS Route 53 DNS。也适用于托管在 Amazon AWS 外部的服务器：
http://gc-taylor.com/blog/2013/04/02/amazon-route53-failover
答案2
好吧，我们通常在控制托管基础设施时尝试这些解决方案。由于您雇用了托管公司，因此他们有义务使其在指定的 SLA（服务水平协议）下运行。但如果您真的对此感兴趣，我建议您至少雇用一家公司和一个 SaaS 或 IaaS 解决方案来实现这一点。
答案3
是的，有负载平衡服务可以满足您的要求。因为我们拥有自己的硬件，所以我们实际上有一个硬件解决方案，即使用 Barracuda 负载平衡器。它们监控我们网站上的页面（一个建立数据库连接的特定页面，如果连接成功则显示“UP”）。如果显示“UP”，则我们知道 Web 服务器和数据库都在运行。如果没有显示“UP”，则我们知道 Web 服务器或数据库没有运行，并触发故障转移。有软件负载平衡器可以实现同样的效果。询问您的托管服务提供商是否提供此类服务。
编辑上一段：抱歉，我想我应该澄清一下。Barracuda 有一个“最后手段”故障转移选项。因此，我们只配置了 1 台服务器，100% 的流量都流向它进行负载平衡。发生故障时，它将使用“最后手段” IP 地址。这不是负载平衡器的典型用例，但它对我们的小型设置非常有用。如果需要进行维护，我们可以强制故障转移到数据中心 B，然后根据需要将其恢复。
然后，我们使用 DNS 故障转移作为辅助层。它以相同的方式监控网站，但我们给它延迟了 5 分钟左右，因为我们发现并不是每个人的 ISP 都遵守 DNS TTL，所以最终会有人同时访问两个网站。因此，我们尽量避免 DNS 故障转移。
说到这一点，为了正确地让它来回故障而不会出现问题，您需要某种集中式数据库或主主复制。我们选择后者，但这很冒险。我的待办事项清单上列出了重新构建数据库部分。
无论如何，这种设置足以实现 99.9% 到 99.99% 的正常运行时间，这对于大多数小型企业来说是可以接受的。