SQL Server 可用性組 LeaseTimeout 和慢 IO
我們的 5 個主數據庫在單個可用性組中的物理（2 * 8 核，512GB，超執行緒）SQL Server 2016 SP2 Enterprise 上執行，有時我們會收到租約超時已過期的錯誤。我的理解是，如果租約無法更新，則存在系統範圍的問題。
當我
sp_server_diagnostics在主副本的日誌文件夾中檢查（SQLDIAG.xel 文件）的輸出時，在超時時間前後，我總是發現掛起的 IO 操作。<ioSubsystem ioLatchTimeouts=“0” intervalLongIos=“0” totalLongIos=“1”>
<longestPendingRequests>
<pendingRequest duration=“26566” filePath="?\F:\SqlLogs\db1.ldf" offset=“80824832” handle= “0x8d10” /> <pendingRequest duration=“1987” filePath="?\O:\SqlLogs\db2.ldf" offset=“3880740352” handle=“0x1330” /> <pendingRequest duration=“1093” filePath="\ ?\O:\SqlLogs\db3.ldf" offset=“288143360” handle=“0x132c” /> <pendingRequest duration=“974” filePath="?\O:\SqlLogs\db3.ldf" offset=“288145408” handle=“0x132c” /> <pendingRequest duration=“937” filePath="?\O:\SqlLogs\db3.ldf"offset=“288146944” handle=“0x132c” />
</longestPendingRequests>
</ioSubsystem>
這是我在主副本的集群日誌中找到的：
WARN [RES] SQL Server 可用性組：[hadrag] 無法檢索數據列。返回程式碼 -1
ERR [RES] SQL Server 可用性組：[hadrag] 檢測到故障，診斷檢測信號失去
ERR [RES] SQL Server 可用性組 <AG_Name>：[hadrag] 可用性組在給定的 HealthCheckTimeout 和 FailureConditionLevel
ERR [ RES] SQL Server 可用性組 <AG_Name>：[hadrag] 資源活動結果 0。
ERR [RES] SQL Server 可用性組：[hadrag] 檢測到故障，診斷心跳失去
ERR [RES] SQL Server 可用性組 <AG_Name>：[ hadrag] 可用性組在給定的 HealthCheckTimeout 和 FailureConditionLevel 情況下不健康
ERR [RES] SQL Server 可用性組 <AG_Name>：[hadrag] Resource Alive 結果 0。WARN
[RHS] Resource AG_Name IsAlive 指示失敗。
這是 SQL Server 錯誤日誌中的錯誤：
錯誤：19407，嚴重性：16，狀態：1
SQL Server 託管可用性組“AG_Name”在租用超時期限內未收到來自 Windows Server 故障轉移群集的程序事件信號。
錯誤：19407，嚴重性：16，狀態：1
可用性組“AG_Name”和 Windows Server 故障轉移群集之間的租約已過期。SQL Server 實例與 Windows Server 故障轉移群集之間出現連接問題。若要確定可用性組是否正確進行故障轉移，請檢查 Windows Server 故障轉移群集中相應的可用性組資源。
Always On：可用性組“AG_Name”的本地副本離線，因為租約過期或租約續訂失敗。這只是一條資訊性消息。無需使用者操作。
這是來自的輸出
SELECT @@version：Microsoft SQL Server 2016 (SP2-CU15) (KB4577775) - 13.0.5850.14 (X64) Sep 17 2020 22:12:45 版權所有 (c) Microsoft Corporation Enterprise Edition：Windows Server 2012 R2 上基於核心的許可（64 位）標準 6.3（內部版本 9600：）
在我們的監控中，沒有高 CPU 使用率的跡象。出現問題時也不會創建記憶體轉儲。
由於此超時，WSFC 服務重新啟動集群資源“AG_Name”。之後，此資源重新啟動，一切都再次完美執行。
我不明白的是：緩慢的 IO 請求如何導致租約超時？許多待處理的 IO 請求會導致租約超時嗎？
在我們的監控工具中檢查等待統計資訊後，我注意到在問題發生的那一刻，有兩種領先的等待類型，等待時間為 526000 毫秒/秒，PREEMPTIVE_SP_SERVER_DIAGNOSTICS和PREEMPTIVE_HADR_LEASE_MECHANISM。
如果我正確地解釋了這一點，那麼 PREEMPTIVE 部分意味著 SQLOS 之外的執行緒正在執行命令。在這種情況下，執行 SP_SERVER_DIAGNOSTICS 並更新租約。
高等待時間表明 SQL Server 正在等待這些執行緒完成。所以我認為這是作業系統沒有響應的問題。
我們的系統管理員還提到，在超時的那一刻，系統日誌中有幾個event-id 153的警告：
Device\MPIODisk0 目前處於降級狀態。一條或多條路徑失敗，但該過程現已完成。
所以我的結論是由於磁碟問題作業系統在定義的超時設置內沒有響應並導致集群資源重新啟動。
緩慢的 IO 請求如何導致租約超時？許多待處理的 IO 請求會導致租約超時嗎？
不，緩慢的 I/O 請求不能直接導致租約超時。
但是，如果伺服器完全過載（CPU 為 100%），則會導致掛起的 I/O 請求和租用超時。預設租用超時為 20 秒，而您的待處理 I/O 為 26 秒。高 CPU 或其他一些伺服器/作業系統級別的問題更可能是這裡的問題。
另一個原因是 SQL Server 遇到了一個嚴重錯誤，並且正在生成轉儲文件（這會導致程序暫停，可能足夠長的時間讓 WSFC 認為租約超時）。
有關更多可能性，請參閱文件：
作業系統無響應、虛擬記憶體不足、工作集分頁、生成轉儲、固定 CPU、WSFC 關閉（失去仲裁）
您應該查看 SQL Server 錯誤日誌以查看是否創建了轉儲。如果您從這些事件發生時開始進行監控，您還可以檢查 CPU 是否已用盡。