Microsoft SQL Server AG 同步镜像不同步

Question

我们正在升级到 SQL Server 2012 并决定我们希望将自己与用于节点 2 上的报告服务的复制分开。AG 和镜像看起来是一个很好的解决方案——我们采用了同步。还决定应用程序将写入节点 1，并从节点 2 读取以最大程度地减少数据争用。

编写了一个应用程序来插入数据，然后他们立即在节点 2 上检查他们插入的数据是否存在。

现在根据我的理解，AG 上的同步镜像应该接收请求，将数据发送到节点 2——节点 2 提交，然后告诉节点 1 完成，然后节点 1 返回给用户。

发生的事情根本不是——他们发送了数据，从节点 2 进行了检索——数据不匹配。错误。

我检查并仔细检查了设置，并让另一位一直使用 AG 和同步镜像的 DBA 查看了这些东西——我们最好的结论是，从我们看到的 Microsoft 的“同步”镜像来看，它不是同步的。有没有其他人看到这个？

Answer 1

这是完全可以预料的。我之前已经谈过这个，但我会为你回顾一下。

您看到这种行为的原因可能有多种。大多数人对其工作方式感到困惑或不准确的两个方面是可用性组如何同步数据以及对可读辅助副本的查询如何工作。

请注意，以下内容仅适用于 SQL 2012 和 2014，在某种程度上也适用于 2016。

数据同步的工作原理（简要概述）

副本同步有两种类型，同步和异步。两者的数据同步方式完全相同。但是，SQL Server 的行为方式是不同的。当使用同步时，我们等待数据在辅助副本上硬化。这意味着只需要确认它已成功写入日志，而不是已成功重做日志块。异步不等待状态消息，只是继续。

因此它完全正常工作，但是似乎对它的工作方式存在误解。AG 发送日志块，而不是事务，因此整个事务可能不会一起发送，甚至可能还没有重做。

查询可读的二级副本

当您在辅助副本上运行查询时，已提交读（默认）隔离级别会静默映射到幕后快照隔离......无论您是否为数据库启用了 SI 或 RCSI。

由于快照通过行版本控制工作并且从事务的开始就保持一致，因此您可能无法看到根据快照隔离的工作方式传入的新数据。这完全按预期工作。

要记住的另一点是，仅仅因为您确认数据已被强化到同步辅助副本上的日志，并不意味着 REDO 线程已经重做这些日志块。因此，仅仅因为您对主服务器进行了确认并不意味着 REDO 已完成它，只是它已被强化到日志中。此外，如果您的重做线程被阻塞，则可能需要很长时间（或永远不会）不被阻塞，因此您的重做队列大小会增加。

最后，我完全可以预料到您所看到的行为，但这并不意味着它不是同步的。这只是意味着它不一定像人们相信或认为的那样工作。希望这能消除混乱。