[AlwaysOn Availability Groups]排查：AG超過RPO

排查：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文件和數據文件在同一個磁盤下，第一件要做的事情就是把日志文件和數據文件分開。

?