为什么HA有自动故障转移，DR有手动故障转移？

Question

我正在阅读卡特的“Pro SQL Server 2019 Administration”一书中的摘要：

它还具体规定：

用于高可用性的热→自动故障转移→(HA)

用于灾难恢复(DR)的温→手动故障转移→

既然“高可用性”通常是计划好的，而“灾难恢复”不是计划好的，那么在“高可用性”场景中，我们不应该以手动故障转移为目标吗？

实现高可用性的自动故障转移有什么意义？

对我来说，如果DR发生了，故障转移应该是自动的，如果我们有计划的话(修补等等)。我们有HA，我们可以手动进行故障转移.

Answer 1

推广和简化是很棘手的。然而，这里有一个尝试：

我的感觉是，医管局一般在地理上较为接近。在这种情况下，使用同步方法更为现实，比如同步可用性组。在这种情况下，自动故障转移是合理的。

但是当我们谈论DR时，想象更远的距离是合理的，因为有一定的距离是弹性架构本身的一部分。而且距离越长，很可能就会有异步方法来进行更改。就像异步AGs。日志传送本质上是异步的。也就是说，使用异步解决方案进行故障转移，您就会丢失数据！不是你想要“幕后”发生的事情。

Answer 2

基于每个企业对数据丢失和恢复时间的容忍度，这种情况将发生巨大的变化。但是，这是我对这件事的想法。

SQL服务器并不是处于真空状态，我们的HA和DR计划是包括应用服务器、BI和其他资源在内的一个整体的一部分。在分散的区域添加一个健康的地理分散和同步组合是不可行的，因为我们不希望连接中的临时延迟会对连接到主站点的用户造成滞后。

考虑到所有这些，我们的业务早就决定，任何故障转移都必须手动执行，这样我们就可以将整个环境作为一个整体进行移动。我们确实有SQL服务器的同步合作伙伴，但是我们仍然选择只使用手动故障转移。

Answer 3

因为在DR场景中，你需要检查到底发生了什么。例如，您的DR站点失去了与主服务器的联系。它应该启动吗？嗯，初级可能真的很好，有人只是在纤维中放了一把反铲，这种情况一直都在发生。或者初选可能被自然灾害或恐怖分子的暴行彻底摧毁。Server无法自行解决这一问题。

HA很简单，它通常在相同的DC中，因此对于自动决策来说，故障模式的范围要容易得多。