介紹
物理故障、作業系統故障或 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
總結
無法檢測到主資料庫之外的資料庫中的故障。 此外，也不太可能檢測到資料磁碟故障，除非資料庫因為資料磁碟故障而重新啟動，僅在出現軟錯誤時，才對可用性副本執行有效的錯誤檢查。
|
備註： 作者：pursuer.chen 部落格：http://www.cnblogs.com/chenmh 本站點所有隨筆都是原創，歡迎大家轉載；但轉載時必須註明文章來源，且在文章開頭明顯處給明連結。 《歡迎交流討論》 |