[AlwaysOn Availability Groups]排查：Primary上的修改无法在Secondary体现

排查：Primary上的修改无法在Secondary体现

客户端进程在primary上修改成功，但是在Secondary上却无法看到修改结果。这个case假设你的可用性组有同步的健康问题。很多情况下这个情况会在几分钟之后自动解决。

如果几分之后依然看不到，那么可能在同步的工作流上有瓶颈问题。这个瓶颈会因为是不是同步提交的而不同。

 

Commit Mode	Possible Bottleneck	Explanation
Synchronous Commit	Primary上长运行事务 secondary上的redo线程	每个在primary上成功的更新，都同步到了secondary或者日志记录已经为固话刷新。因此瓶颈应该在redo线程上，如果一旦redo跟上，secondary上的读取负荷都是快照隔离级别的。
Asynchronous Commit	Primary上长运行事务 网络延迟或者吞吐量 secondary中的日志固话 secondary上的redo	因为一部提交一旦事务被写入到磁盘就会被通知，瓶颈可能在这个点之后任意位置出现。

1.通常原因

导致primary修改后没有反映到secondary上原因：
1.长运行活动事务
2.高网络延迟，网络吞吐量低导致，Primary的日志堆高
3.有一个Report负荷堵塞了Redo线程
4.因为资源争用导致redo落后

2. 长运行活动事务

primary的长运行事务阻止了从secondary上读取。

原因：
所有secondary上的读负荷都是快照隔离级别的。在快照隔离下，只读客户端只能看到secondary的可用数据库中在redone log中最早的活动事务开始点之前的数据。如果事务几个小时没有提交，事务会block所有只读查询可以看到新的更新数据。

诊断和解决：
在primary，使用dbcc opentran查看最老的活动事务，查看是否可以回滚。一旦最老的事务被回滚并且同步到secondary，在secondary上的读负荷就能之后更新的数据了。

3. 高网络延迟，网络吞吐量低导致，Primary的日志堆高

高网络延迟或者低吞吐量会阻止日志被发送到secondary。

原因：
如果未响应信息发送超过最大允许值，primary会激活flow control，不再发送信息到secondary。直到有些信息有了反馈。这种状态会严重影响数据丢失能力，甚至超过RPO。

诊断和解决：
如果DMV的log_send_queue_size很大，表示log被堵塞在primary上。如果值除以log_send_rate可以初略的评估多久之后才能赶上primary。

也可以检查 SQL Server:Availability Replica > Flow Control Time (ms/sec)和 SQL Server:Availability Replica > Flow control/sec。这2个值相乘可以得到每秒至少花多少时间来等待flow control。flow control等待时间越长，速度越慢。

以下是有用的网络延迟和吞吐的诊断值。也可以使用windows工具，比如ping， Resource Monitor 来评估网络使用率。

·  DMV log_send_queue_size

·  DMV log_send_rate

·  Performance counter SQL Server:Database > Log Bytes Flushed/sec

·  Performance counter SQL Server:Database Mirroring > Send/Receive Ack Time

·  Performance counter SQL Server:Availability Replica > Bytes Sent to Replica/sec

·  Performance counter SQL Server:Availability Replica > Bytes Sent to Transport/sec

·  Performance counter SQL Server:Availability Replica > Flow Control Time (ms/sec)

·  Performance counter SQL Server:Availability Replica > Flow Control/sec

·  Performance counter SQL Server:Availability Replica > Resent Messages/sec

4. 有一个Report负荷堵塞了Redo线程

Redo线程在secondary副本被一个只读长运行语句堵塞。

原因：
在secondary副本，只读查询获得Sch-s锁，这些sch-s锁会堵塞redo线程获得sch-m锁执行DDL修改。被堵塞的redo线程不能应用log记录，直到被释放。一旦被释放，可以执行redo。并且允许执行随后的undo和failover过程执行。

诊断和解决：
当redo线程被堵塞，扩展时间会生产，sqlserver.lock_redo_blocked。另外你可以查询sys.dm_exec_request,查看那个会话堵塞了redo。

select session_id, command, blocking_session_id, wait_time, wait_type, wait_resource

from sys.dm_exec_requests where command = 'DB STARTUP'

可以通过kill会话，强制释放锁。

5. 因为资源争用导致redo落后

大报表行为降低了secondary的性能，导致redo线程被落下

原因：
当应用log记录，redo线程读取log记录，并且应用这些log访问数据page。Page访问可能造成IO瓶颈，如果page不在内存中。如果还有IO密集型的负荷，照成IO资源争用，会降低redo线程的性能。

诊断和解决：
你可以通过DMV查看被落下了多少，通过对比last_redone_lsn和last_received_lsn

select recovery_lsn, truncation_lsn, last_hardened_lsn, last_received_lsn,

   last_redone_lsn, last_redone_time

from sys.dm_hadr_database_replica_states

如果redo线程被真的落下了，就需要研究secondary上的性能问题，是否有IO争用问题。可以通过Resource Governor 来限制其他会话的资源使用