数据库应用的故障转移策略答案

【问题标题】：Failover strategy for database application数据库应用的故障转移策略
【发布时间】：2016-03-01 17:52:25
【问题描述】：

我有一个持有本地缓存的读写数据库应用程序。如果应用服务器出现故障，备份服务器将开始工作。

主要和备份应用程序只能以独占方式运行，因为它的本地缓存和数据库上的一些低隔离级别。

就我的通信知识而言，不可能让两台服务器始终弄清楚谁可以独占运行。

我可以通过将数据库用作第三方实体以某种方式解决这种通信冲突吗？我认为这是一个非常典型的问题，可能没有 100% 安全的方法，但我很高兴知道其他人建议如何解决此类问题？或者，如果有一些最佳实践。

如果两个应用程序都在 30 分钟左右都没有工作也没关系，但是没有足够的时间让人们起床并让他们找出问题所在。

【问题讨论】：

这实际上并不像您想象的那么普遍，因为应用服务器被设计成集群和水平扩展，其中单个节点的故障是透明且无关紧要的。另一方面，出于显而易见的原因，数据库服务器通常以您描述的方式进行故障转移。
谢谢，应用服务器可能是“错误”的术语。它是一个运行应用程序的独立服务器，该应用程序与数据库紧密相连，是数据库的一条长臂，而且根本不是为扩展而设计的。

【解决方案1】：

您能否设置第三台服务器来监控两个应用程序服务器的运行状况？然后，该服务器可以在其中一台服务器出现故障的情况下做出适当的决定：指示热备用服务器开始处理。

【讨论】：

【解决方案2】：

如果我得到了正确的图片，您的备份服务器会不断轮询主服务器以获取数据更新，不难检查轮询是否失败，30 秒后再次安排它 3 次，并在第三次失败时动态更新数据库服务器的 DNS 条目以反映活动服务器中的更改。 Windows DNS 和绑定都接受签名和未签名的动态更新。

【讨论】：