[AlwaysOn Availability Groups]排查:AG超过RTO

简介: 排查:AG超过RTO 自动故障转移或者手动转移之后,没有数据都是,你可能会发现切换时间超过了你的RTO。或者当你评估切换时间同步提交secondary副本,发现超过了你的RTO。 1. 通常原因 通常引起故障转移超过RTO的原因: 1.报表负荷堵塞了Redo线程。

排查:AG超过RTO

自动故障转移或者手动转移之后,没有数据都是,你可能会发现切换时间超过了你的RTO。或者当你评估切换时间同步提交secondary副本,发现超过了你的RTO

1. 通常原因

通常引起故障转移超过RTO的原因:

1.报表负荷堵塞了Redo线程。

2.因为资源争用,Redo线程被落下。

2. 报表负荷堵塞了Redo线程

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

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

诊断和解决:
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会话,强制释放锁。

3. 因为资源争用,Redo线程被落下。

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

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

诊断和解决:
你可以通过DMV查看被落下了多少,通过对比last_redone_lsnlast_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 来限制其他会话的资源使用

 

目录
相关文章
|
3月前
|
存储 API
【Azure Storage Account /ADLS】可用性指标降低的警告和是否会发生故障转移
【Azure Storage Account /ADLS】可用性指标降低的警告和是否会发生故障转移