案例分享：數據庫鏡像故障轉移失敗

案例分享：數據庫鏡像故障轉移失敗

對于關鍵性數據庫，我們配置了帶有見證服務器的同步數據庫鏡像，來允許自動故障轉移。一切運行正常，直到有一次數據中心的突然斷電。數據庫鏡像執行了故障轉移，但是運維反饋說應用程序掛起了。當我們手動切換回來，應用程序又正常工作。為什么應用程序沒有也故障轉移呢？

這是使用數據庫鏡像的合理的常見問題，像這樣的生產應用失敗，是因為在鏡像部署后沒有做故障轉移測試。在失敗的故障轉移之后我們感到棘手。

為了避免生產應用停機，我們在測試環境復制了線上的鏡像環境。在確認應用和數據庫鏡像正常工作后，我們將主服務器關機，應用完全掛起。

我們檢查了，鏡像服務器已經成功初始化了一個故障轉移，并在線作為主服務器。我們也檢查了鏡像數據庫為在線狀態，可以被新的主服務器本地訪問，并且主服務器也可以像被應用程序使用一樣被遠程客戶端訪問。

然后，我們來檢查應用程序。和開發聊了下，他確認應用程序是使用ADO.NET來連接SQL Server，并使用顯式客戶端重定向，在SqlConnection的ConnectionString屬性指定鏡像服務器名。（順便說一句，使用顯式客戶端重定向總是比隱式客戶端重啟定向要好，隱式依賴于客戶端連接建立時自動緩存的鏡像服務器名）

那為什么應用程序沒有故障轉移呢？

我深入探究應用程序是如何處理連接失敗，發現根本沒有應對存在的連接失敗的代碼！基本上，當應用程序初始化，應用會打開一個到SQL Server的連接，并且絕不嘗試重連。

結果發現：盡管DBA部署了數據庫鏡像，沒有和開發討論過高可用性，因此應用程序代碼沒有改變。在開發修復后，應用程序連接層可以應對連接失敗和執行重連邏輯，在數據庫故障轉移之后可以完美工作。

這個故事告訴我們，需要重新構建應對發生的連接失敗和重連，來讓故障轉移正確工作。在這個案例中，如果我們在部署在生產環境之前，在測試環境嘗試了數據庫鏡像故障轉移，那客戶端就會發現這個問題了。

具體原理和應用程序的代碼示例，可參考以下文章：   

• 將客戶端連接到數據庫鏡像會話（https://msdn.microsoft.com/zh-cn/library/ms175484.aspx）    

• Implementing Application Failover with Database Mirroring（https://technet.microsoft.com/en-us/library/cc917713.aspx#EDAA）    

• Sample Application to test database mirroring failover（https://blogs.msdn.microsoft.com/grahamk/2009/01/16/sample-application-to-test-database-mirroring-failover/）