SQL Server中的脏读AlwaysOn

我有一对设置为同步AlwaysOn可用性组的SQL Server 2014数据库。SQL Server中的脏读AlwaysOn

两台服务器都设置为Synchronous commit可用性模式，会话超时时间为50秒。辅助设置为可读辅助设备Read-intent only。

如果我写入主服务器，然后立即从次服务器读取（通过ApplicationIntent=ReadOnly），我一直读取脏数据（即写入前的状态）。如果我在写作和阅读之间等待大约一秒钟，我会得到正确的数据。

这是预期的行为？如果是这样，我能做些什么来确保从中学读取是最新的？

我想使用辅助节点作为主节点的只读版本（以及故障切换），以减少主节点的负载。

2016-09-19 Paul

可能的更好的交易响应时间和吞吐量对于http：/ /dba.stackexchange.com/ – Liam

这不是“脏读”，它只是延迟。请阅读此处：https://blogs.msdn.microsoft.com/sqlserverstorageengine/2011/12/22/alwayson-readable-secondary-and-data-latency/ – dean

请参阅http://dba.stackexchange.com/questions/84420/does-synchronous-commit-availability-mode-ensure-consistency-between-replicas。简而言之：是的，这是预料之中的，如果您无法容忍*任何延迟，请从小学读取。你可以想像得出你自己的机制来确保你的阅读是最新的（带有触发器或类似的时间戳表），但在大多数情况下，这会比它的价值更麻烦。在任何情况下，都不要在一个工作负载中盲目混合副本，以期达到同步。 –

没有办法，你可以得到脏读，除非您使用无锁提示..

当您启用阅读AlwaysOn..Internally SQL只有二级采用rowversioning存储前行的版本..

进一步使用同步提交模式下，这确保日志记录首先在二次承诺，然后在主..

你看到的是数据延迟..

这whitePaper DEA与此scenario..Below LS是有关部分，其可以帮助您了解更多关于它..

在辅助副本上运行的报告工作量会招致一些数据延迟，通常是几秒钟的时间，这取决于主要工作负载分钟和网络延迟。

即使将辅助副本配置为同步模式，也会存在数据延迟。虽然在向主节点发送ACK之前，通过强化已提交事务的事务日志记录来确保同步副本有助于在理想条件（即RPO = 0）下保证没有数据丢失，但并不保证REDO线程在辅助副本上确实将关联的日志记录应用于数据库页面。

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

在同步复制的情况下，不足的网络带宽不会导致更高的数据延迟在次级但它可以减缓用于主工作量

来源

2016-09-19 13:36:40 TheGameiswar

SQL Server中的脏读AlwaysOn

回答

相关问题