如果不推荐使用 DNS 故障转移，那么推荐什么？

Question 1

整个数据中心需要瘫痪或无法访问才能应用此方法。然后，通过将 IP 地址路由到其他数据中心，即可访问您在另一个数据中心的备份。这将通过不再提供主数据中心的 BGP 路由公告来实现。然后，将使用来自辅助数据中心的辅助公告。

小型企业通常规模不够大，不足以证明可移植 IP 地址分配和自己的自治系统编号用于宣布 BGP 路由的费用是合理的。在这种情况下，提供商会选择多个位置。

您要么必须通过原始 IP 地址联系到您，要么必须通过 DNS 更改 IP 地址联系到您。由于 DNS 并非按照“故障转移”所需的方式设计（用户无法联系的时间至少与您的 TTL 或某些缓存服务器规定的 TTL 一样长），因此使用相同 IP 访问备份站点是最佳解决方案。

Answer

整个数据中心需要瘫痪或无法访问才能应用此方法。然后，通过将 IP 地址路由到其他数据中心，即可访问您在另一个数据中心的备份。这将通过不再提供主数据中心的 BGP 路由公告来实现。然后，将使用来自辅助数据中心的辅助公告。

小型企业通常规模不够大，不足以证明可移植 IP 地址分配和自己的自治系统编号用于宣布 BGP 路由的费用是合理的。在这种情况下，提供商会选择多个位置。

您要么必须通过原始 IP 地址联系到您，要么必须通过 DNS 更改 IP 地址联系到您。由于 DNS 并非按照“故障转移”所需的方式设计（用户无法联系的时间至少与您的 TTL 或某些缓存服务器规定的 TTL 一样长），因此使用相同 IP 访问备份站点是最佳解决方案。

Question 2

这开始是一条评论...但它变得太长了。

遗憾的是，大多数答案上一个问题是错误的：他们认为故障转移与 TTL 有关。得票最高的答案是完全错误的，而且值得注意的是没有引用任何来源。TTL 适用于整个区域记录，与循环无关。

来自 RFC 1794（关于循环 DNS服务）

There is no use in handing out information with TTLs of an hour [or less]

（IME 表示需要接近 3 个小时才能获得完全传播）。

来自 RFC 1035

When several RRs of the same type are available for a
 particular owner name, the resolver should either cache them
 all or none at all

RFC 1034 列出了负缓存的要求 - 一种指示所有请求都必须从权威 DNS 服务器新鲜提供的方法（在这种情况下 TTL 确实控制故障转移） - 根据我的经验，对此的支持有所不同。

由于任何故障转移都必须在客户端堆栈的高层实现，因此可以说它不是 TCP/IP 或 DNS 的一部分 - 事实上，SIP、SMTP、RADIUS 和其他运行在上面TCP/IP 定义了客户端应如何使用循环机制 - 值得注意的是，RFC 2616（HTTP/1.1）并未提及它应如何运作。

但是，根据我的经验，如果连接时间似乎比预期的要长，过去 10 年编写的每个浏览器和大多数其他 HTTP 客户端都会透明地检查额外的 A RR。而且这不仅仅是我：

故障转移时间因实施而异，但大约为几秒。这不是一个理想的解决方案，因为（由于 DNS 的限制）发布故障节点需要 DNS TTL - 同时您必须依赖客户端检测。

Round-Robin 不能替代其他 HA 机制之内一个站点。但它确实对其进行了补充（编写 HAProxy 的人建议使用一对通过循环 DNS 访问的安装）。它是跨多个站点实施 HA 的最佳支持机制：事实上，据我所知，它是标准客户端上唯一支持的故障转移机制。

Answer