频道栏目
首页 > 数据库 > SQL Server > 正文
[AlwaysOn Availability Groups]排查:AG超过RPO
2015-11-23 13:33:37           
收藏   我要投稿
排查:AG超过RPO

 

在异步提交的secondary上执行了切换,你可能会发现数据的丢失大于RPO,或者在计算可以忍受的数据都是超过了RPO。

 

1.通常原因

 

1.网络延迟太高,网络吞吐量太低,导致Primary的日志堆积

 

2.磁盘IO瓶颈导致LOG固化速度降低

 

2. 网络延迟太高,网络吞吐量太低,导致Primary的日志堆积

 

很多超过RPO的原因是日志发送到secondary副本不够快。

 

原因:

Primary副本在日志发送启动了流量控制,因为日志发送超过了最大运行的非通知信息的量。直到这些信息被通知,不然不能在发新的信息到secondary副本。因为数据丢失会影响secondary副本的固化。这些没有发送的日志的数据就会被丢失。

 

诊断和解决:

 

日志高度重复,说明primary和secondary上的延迟很高。可以查看DMV的log_send_rate和性能指标log bytes flushed/sec对比。如果flushed速度大于发送的速度,那么数据丢失会越来越大。

 

通过检查性能指标,SQL Server:Availability Replica> Flow Control Time(ms/sec)和SQL Server:Availability Replica > Flow Comtrol/sec。这2个性能指标可以说明上一秒有多少时间用来等待flow control清理。Flow control等待越久,发送速度越小。

 

以下是一组指标可以用来诊断网络延迟和吞吐量,也可以用一些Windows工具,比如ping,Resource Monitor, 和Network Monitor :

 

·  DMV sys.dm_hadr_database_replica_states, log_send_queue_size

 

·  DMV sys.dm_hadr_database_replica_states, 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

 

3.磁盘I/O瓶颈降低secondary副本的日志固化

 

根据数据库文件部署,日志固化会因为IO争用被降低。

 

原因:

 

只要日志被固化到磁盘,就可以防止数据丢失。因此隔离日志文件和数据文件的IO变的很重要。如果日志文件和数据文件使用同一个物理磁盘,IO密集型查询会消耗日志固化需要的IO能力。日志固化变慢会间接导致primary通知变慢,导致flow control等待时间变长。

 

诊断和解决:

 

如果你诊断了网络,没有很高的延迟或者很低的吞吐量,然后你应该看看secondary是否有IO争用问题。

 

以下脚本可以让你知道每个数据文件和日志文件的读写次数。

SELECT DB_NAME(database_id) AS
   [Database Name] ,
   file_id ,
   io_stall_read_ms ,
   num_of_reads ,
   CAST(io_stall_read_ms /( 1.0 + num_of_reads ) AS NUMERIC(10, 1)) AS [avg_read_stall_ms] ,
   io_stall_write_ms ,
   num_of_writes ,
   CAST(io_stall_write_ms /( 1.0 + num_of_writes ) AS NUMERIC(10, 1)) AS [avg_write_stall_ms] ,
   io_stall_read_ms + io_stall_write_ms AS [io_stalls] ,
   num_of_reads + num_of_writes AS [total_io] ,
   CAST(( io_stall_read_ms + io_stall_write_ms ) /( 1.0 + num_of_reads
+ num_of_writes) AS NUMERIC(10,1)) AS [avg_io_stall_ms]
FROM sys.dm_io_virtual_file_stats(NULL, NULL)
WHERE DB_NAME(database_id) IN(SELECT DISTINCT database_name FROM sys.dm_hadr_database_replica_cluster_states)
ORDER BY avg_io_stall_ms DESC;

下面脚本提供了某个时间点IO请求被挂起的快照:

SELECT DB_NAME(mf.database_id) AS [Database] ,
   mf.physical_name ,
   r.io_pending ,
   r.io_pending_ms_ticks ,
   r.io_type ,
   fs.num_of_reads ,
   fs.num_of_writes
FROM sys.dm_io_pending_io_requests AS r
INNER JOIN sys.dm_io_virtual_file_stats(NULL, NULL) AS fs ON r.io_handle = fs.file_handle
INNER JOIN sys.master_files AS mf ON fs.database_id = mf.database_id
AND fs.file_id = mf.file_id
ORDER BY r.io_pending , r.io_pending_ms_ticks DESC;

你可以通过读写IO,来识别是否有IO争用问题。以下是一些关于IO的性能指标:

·  Physical Disk: all counters

 

·  Physical Disk: Avg. Disk sec/Transfer

 

·  SQL Server: Databases > Log Flush Wait Time

 

·  SQL Server: Databases > Log Flush Waits/sec

 

·  SQL Server: Databases > Log Pool Disk Reads/sec

 

如果你发现有IO瓶颈,并且log文件和数据文件在同一个磁盘下,第一件要做的事情就是把日志文件和数据文件分开。

点击复制链接 与好友分享!回本站首页
相关TAG标签
上一篇:[AlwaysOn Availability Groups]排查:AG超过RTO
下一篇:[AlwaysOn Availability Groups]排查:Primary上的修改无法在Secondary体现
相关文章
图文推荐
点击排行

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站