SQL Server AlwaysOn中的脏读取

我将一对SQL Server 2014数据库设置为同步AlwaysOn可用性组

两台服务器都设置为

同步提交

可用性模式，会话超时为50秒。辅助设置为

只读

可读辅助

如果我先向主数据写入数据，然后立即从次数据读取数据（通过

applicationcontent=ReadOnly

），我会一直读取脏数据（即写入前的状态）。如果我在写和读之间等待大约一秒钟，我就会得到正确的数据

这是预期的行为吗？如果是这样，我可以做些什么来确保从辅助服务器读取的数据是最新的

---

我想使用辅助设备作为主设备的只读版本（以及故障转移），以减少主设备上的负载。

除非使用无锁提示，否则无法获得脏读

在AlwaysOn.中启用只读二级时，SQL内部使用行版本控制来存储行的早期版本

如果您使用的是同步提交模式，这将确保日志记录首先在辅助服务器上提交，然后在主服务器上提交

您看到的是数据延迟

这涉及到这个场景。下面是相关的部分，有助于理解更多关于它的内容

在辅助副本上运行的报告工作负载将产生一些数据延迟，通常为几秒钟到几分钟，具体取决于主工作负载和网络延迟

即使已将辅助副本配置为同步模式，数据延迟仍然存在。虽然同步复制副本确实有助于确保在理想情况下（即RPO=0）不会丢失数据，但在向主服务器发送ACK之前，它会强化已提交事务的事务日志记录，它不能保证辅助副本上的重做线程确实已将关联的日志记录应用于数据库页面

因此存在一些数据延迟。您可能想知道，在异步模式下配置辅助副本时，这种数据延迟的可能性是否更大。这是一个更难回答的问题。如果主副本和辅助副本之间的网络无法跟上事务日志流量（即，如果没有足够的带宽），则异步副本可能会进一步落后，从而导致更高的数据延迟

在同步副本的情况下，网络带宽不足不会导致辅助服务器上的数据延迟增加，但会降低主工作负载的事务响应时间和吞吐量

---

可能更好，因为它不是“脏读”，只是延迟。读这里：看。简言之：是的，这是预期的，如果您不能容忍任何延迟，请从主服务器读取。可以想象，您可以提出自己的机制来确保读取是最新的（带有触发器或类似触发器的时间戳表），但在大多数情况下，这会带来更多麻烦。在任何情况下，都不要盲目地将副本混合在一个工作负载中，以为它们是同步的。这是同步提交可用性模式的预期行为。据我所知，如果使用异步提交模式，那么只有一种方法可以减少延迟。但是，存在数据丢失的风险。在异步提交模式下，主副本提交事务，而不等待异步提交辅助副本已加固日志的确认。异步提交模式将辅助数据库上的事务延迟降至最低，但允许它们落后于主数据库，从而可能导致一些数据丢失。