我有一对SQL Server 2014数据库设置为同步AlwaysOn可用性组。
两台服务器均设置为Synchronous commit可用性模式,会话超时为50秒。次级被设置为Read-intent only可读的次级。
Synchronous commit
Read-intent only
如果我写入主数据,然后立即(通过ApplicationIntent=ReadOnly)从辅助数据中读取,则我将始终读取脏数据(即写入之前的状态)。如果我在写入和读取之间等待大约一秒钟,我将获得正确的数据。
ApplicationIntent=ReadOnly
这是预期的行为吗?如果是这样,我可以做些什么来确保从辅助读取是最新的?
我想将辅助服务器用作主服务器(以及故障转移)的只读版本,以减少主服务器上的负载。
除非您使用无锁提示,否则您不可能得到脏读。
在AlwaysOn中启用只读辅助副本时。内部SQL使用行版本控制来存储行的先前版本。
此外,您使用的是同步提交模式,这可确保日志记录首先在辅助数据库上提交,然后在主要数据库上提交。
您看到的是数据延迟。
本白皮书处理了这种情况。下面是相关部分,有助于您进一步了解它。
在辅助副本上运行的报告工作负载将导致一些数据延迟,通常要几秒钟到几分钟,这取决于主要工作负载和网络延迟。 即使将辅助副本配置为同步模式,也存在数据延迟。确实,同步副本通过在将ACK发送到主数据库之前对已提交事务的事务日志记录进行加固来帮助确保在理想条件下(即RPO = 0)没有数据丢失,但这并不能保证REDO线程辅助副本上的磁盘确实已将关联的日志记录应用于数据库页面。 因此存在一些数据延迟。您可能想知道在异步模式下配置辅助副本时,这种数据延迟是否更有可能发生。这是一个较难回答的问题。如果主副本和辅助副本之间的网络无法跟上事务日志流量(即,如果没有足够的带宽),则异步副本可能会进一步落后,从而导致更高的数据延迟。 对于同步副本,不足的网络带宽不会导致辅助节点上的数据延迟增加,但会减慢主节点工作负载的事务响应时间和吞吐量。
在辅助副本上运行的报告工作负载将导致一些数据延迟,通常要几秒钟到几分钟,这取决于主要工作负载和网络延迟。
即使将辅助副本配置为同步模式,也存在数据延迟。确实,同步副本通过在将ACK发送到主数据库之前对已提交事务的事务日志记录进行加固来帮助确保在理想条件下(即RPO = 0)没有数据丢失,但这并不能保证REDO线程辅助副本上的磁盘确实已将关联的日志记录应用于数据库页面。
因此存在一些数据延迟。您可能想知道在异步模式下配置辅助副本时,这种数据延迟是否更有可能发生。这是一个较难回答的问题。如果主副本和辅助副本之间的网络无法跟上事务日志流量(即,如果没有足够的带宽),则异步副本可能会进一步落后,从而导致更高的数据延迟。
对于同步副本,不足的网络带宽不会导致辅助节点上的数据延迟增加,但会减慢主节点工作负载的事务响应时间和吞吐量。