SQL Server故障轉移群集數據庫訪問層的最佳實踐是什么？

Question

原則上，SQL Server故障轉移群集將其自身表現為虛擬機，應用程序可以連接到該虛擬機，而不必擔心SQL Server實際上是服務器的群集，因此，原則上，在應用程序的數據庫訪問層內不需要其他邏輯。

我的問題是以上情況是否正確，以及是否在使用故障轉移群集時對數據庫訪問層的操作方式進行了最佳實踐修改。 例如，大概在發生故障轉移時，將存在可能導致數據庫訪問層出現超時錯誤的延遲，我們正在考慮在該層中放置邏輯以在發生超時時重試[某些]數據庫調用（我們已經重試了） DB死鎖的邏輯）。 這提供了另一級保護，以防止影響應用程序的錯誤。

如果發生故障切換，並導致較高的應用程序級別在服務調用上收到超時錯誤，則這不是無縫切換。 我們是否應該簡單地將超時設置為允許故障轉移的持續時間？

謝謝。

Answer 1

原則上，SQL Server故障轉移群集將其自身表現為虛擬機，應用程序可以連接到該虛擬機，而不必擔心SQL Server實際上是服務器群集

啊？ 真？ 這與文檔相矛盾。 基本上，群集不過是一個移動IP地址，在不同的服務器上安裝了不同的服務器，幾乎不是虛擬機。

原則上，在應用程序的數據庫訪問層內不需要其他邏輯。

是和否-發生故障的節點確實會殺死所有正在進行的事務和連接，因此CLIENT必須能夠對此做出反應並重試。 如果客戶端由於連接斷開而崩潰，則不會重試，這不會幫助您在一兩秒鍾后再次訪問服務器。

我們是否應該簡單地將超時設置為允許故障轉移的持續時間？

不可以，因為正在進行的事務狀態丟失，所以連接會因故障轉移而中斷。 您需要重新建立連接，然后再次啟動在事務中發出的所有Sql命令。

從安全角度考慮，群集是不好的，應該使用鏡像-群集節點故障的特定風險是數據庫文件損壞，在這種情況下，故障轉移將失敗。 鏡像更加健壯。