介紹

物理故障、操作系統故障或 SQL Server 故障都可能導致兩個可用性副本之間的會話失敗。 可用性副本不會定期檢查 Sqlservr.exe 所依賴的組件來驗證這些組件是在正常運行還是已出現故障。 但對於某些類型的故障，受影響的組件將向 Sqlservr.exe 報告錯誤。 由另一個組件報告的錯誤稱為「硬錯誤 」。 為了檢測可能忽略的其他故障，Always On 可用性組實施了自己的會話超時機制。 以秒為單位指定會話超時期限。 此超時期限是一個伺服器實例在考慮斷開另一實例的連接之前，等待接收來自該實例的 PING 消息的最長時間。 兩個可用性副本之間發生會話超時時，可用性副本將假定已發生故障並聲明一個「軟錯誤」。

可能的硬錯誤原因包括（但不限於）下列幾種情況：

• 連接或網線斷開
• 網卡出現故障
• 路由器更改
• 防火牆更改
• 端點重新配置
• 事務日誌駐留的驅動器丟失
• 操作系統或進程故障

例如，如果主資料庫中的日誌驅動器停止響應或失敗，操作系統會通知 Sqlservr.exe 出現嚴重錯誤。

某些組件（如網路組件和某些 IO 子系統）使用它們自己的超時設置來確定故障。 這些超時設置獨立於 Always On 可用性組，後者不了解它們，並且完全不能識別其行為。 在這些情況下，超時延遲會延長發生故障與可用性副本收到所引發硬錯誤之間的時間。

可能導致會話超時的情況包括（但不限於）下列各項：

• 諸如 TCP 鏈接超時、數據包被刪除或損壞或數據包順序錯誤等網路錯誤。
• 操作系統、伺服器或資料庫處於掛起狀態。
• Windows 伺服器超時。
• 計算資源不足，例如 CPU 或磁碟超負荷運轉，事務日誌填滿，或系統用完內存或線程。 在這些情況下，需要增加超時期限、降低工作負荷或更換硬體以處理相應的工作負荷。

回話超時機制

由於軟錯誤不能由伺服器實例直接檢測到，因此，軟錯誤可能導致一個可用性副本無限期等待會話中另一個可用性副本的響應。 為了防止發生這種情況， Always On 可用性組實施了會話超時機制，此機制基於以下條件：所連接的可用性副本會在每個打開的連接上按固定間隔發送 ping。 在超時期限內收到 ping 指示連接仍是開放的且伺服器實例正在通過此連接進行通信。 收到 ping後副本將重置此連接上的超時計數器。主副本和輔助副本相互 ping 以指示它們仍處於活動狀態， 會話超時限制是用戶可配置的副本屬性，默認值為 10 秒。

如果在會話超時期限內沒有收到來自另一個副本的ping，該連接將超時、連接將關閉；超時的副本進入 DISCONNECTED 狀態。 即使為同步提交模式的副本，事務也將不等待該副本重新連接暫時將該輔助副本切換到非同步提交模式。在該輔助副本重新與主副本連接後，它們將恢復同步提交模式。

參考：https://msdn.microsoft.com/zh-cn/library/ff877884(v=sql.120).aspx

總結

無法檢測到主資料庫之外的資料庫中的故障。 此外，也不太可能檢測到數據磁碟故障，除非資料庫因為數據磁碟故障而重新啟動，僅在出現軟錯誤時，才對可用性副本執行有效的錯誤檢查。

備註：

《歡迎交流討論》

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！