问日志传送或始终打开作为DR的SQL故障转移CLuster

EN

我的经验是，AlwaysOn高可用性组HAG比日志运输更容易维护。让我们为我们的场景设置一些变量。

1.)Server的版本和版本是Server 2016企业版。我们不在最新的Server修补程序级别上。我们需要应用一个新发布的服务包。

2.)Server数据库环境存在于一个典型的中小型公司(您在问题中描述的主动被动AlwaysOn构建使我得出了这个结论)。该公司有一个夜间或每周维护窗口，但与大多数公司一样，服务水平协议要么是4或5个启动时间(数据库必须有99.99%或99.999%的时间可用)。

让我们来看看每个特性如何让您，DBA，保持那些向上的时间号码，让at经理高兴。

AlwaysOn HAG为您提供了在AlwaysOn副本之间来回失败的灵活性。我的假设是，第一和第二复制品在物理上并不是十分接近的。也许它们位于不同的数据中心或数据中心内的不同机架中。无论如何，如果我需要在主服务器上执行维护，我可以将可用性模式从异步模式设置为同步模式、故障转移模式、执行维护模式、故障恢复模式，并将可用性模式设置为异步模式(https://learn.microsoft.com/en-us/sql/database-engine/availability-groups/windows/availability-modes-always-on-availability-groups)。有了正确配置的AlwaysOn HAG侦听器，最终用户将几乎没有中断，您将很容易地维护该SLA。

现在让我们来看看日志传送。不需要从Microsoft在线剪切和粘贴，就必须手动执行五个步骤，然后才能进行故障转移。它们可以在这里找到..。https://learn.microsoft.com/en-us/sql/database-engine/log-shipping/fail-over-to-a-log-shipping-secondary-sql-server。

考虑到大多数事件和或维护窗口发生在几个小时后，您是否希望有一个AlwaysOn高可用性组，您可以轻松地在副本之间来回切换，或者尝试通过应用事务日志备份使主数据库和辅助数据库同步？

对于您描述的场景，日志传送比可用性组更容易维护。

使用AG快速反复失败的能力对于高可用性来说是很好的，但通常灾难恢复RTO (恢复时间目标)要长得多，因为这是一场灾难。虽然高可用性目标可能是在60秒内全部备份，但灾难恢复目标可能是60分钟。日志传送应该能够很容易地处理。

在异步提交模式下添加远程的第三个AG节点本身可能是一项简单的任务，但维护它可能会变得棘手。我看到我自己的AGs出了问题，包括：

• 未能在辅助节点上自动为数据库添加种子
• 在故障转移后显示为“不同步”或“恢复”的数据库
• 未能在计划的故障转移之前停止数据移动，导致节点不同步
• SQL Server服务在AG节点维护过程中停留为“更改挂起”
• 数据库可能最终恢复：https://blogs.msdn.microsoft.com/alwaysonpro/2014/11/25/large-transaction-interrupted-by-failover-secondary-database-reports-reverting/

对于可用性组，有更多的事情可能出错，还有更多的地方(DMVs、错误日志)来查找故障排除信息：https://blogs.msdn.microsoft.com/sql_服务器_小组/故障排除-高-hadr_同步_commit-wait-type-with-always-on-availability-groups/。

另外，下面是一些与修补可用性组相关的问题(当然，这个列表现在有点老了)：https://www.brentozar.com/archive/2015/02/patching-sql-server-availability-groups/

噢，还有Windows Server故障转移集群的附加复杂性/安装/维护，还有AGs。(注意: Server 2017+并不总是需要WSFC。)

不仅要考虑技术部分的维护，还要考虑人员配置。对于完整的生产覆盖范围，您应该至少有两个具有AG经验的DBA。这种经历很难找到，薪水也很高。将其与日志运输进行比较，大多数DBA候选人都有这样的经验，而且没有相应的薪资溢价。

简而言之，除了故障转移到DR节点的过程之外，可用性组的所有内容都是更高的维护。如果您对DR节点有一个紧凑的RTO，那么您可能必须使用异步镜像，甚至是AG。同样，如果您有一个经验丰富的DBA团队能够处理AGs出错，那么可能会走这条路。否则，日志传送将是更容易维护的技术。

日志传送是最容易维护和排除故障的技术，因为我已经广泛地使用了这两种技术，并且更喜欢日志传送。

为什么？

因为有了一些脚本，您就可以轻松地自动化故障转移过程。这是一个很好的故障转移，您可以在这里进行尾日志备份并复制它(使用已经存在的代理作业)、恢复它(同样使用已经存在的作业)和恢复。

日志运输几乎不会出错。这样做是很容易的。

当然，没有很好的GUI来监视日志传送，但这并不难，而且代理作业确实会检查您的作业。从盒子里出来。

除非您知道如何设置警报，否则AOAG可能会下降，直到您需要它之后才会知道。我之所以知道这是因为我继承了AOAG停止同步的服务器。几个月前我就知道这些服务器的存在。

日志托运设置警报作业，确保您的电子邮件警报正常工作，直到您修复它，它会无止境地困扰您。

我用过日志托运，镜像，AOAG都是为了医生..。我更喜欢原木运输。