主體“硬停機”的故障轉移方案

我的公司有一對故障轉移 SQL Server 2005 實例，它們為 UL 許可的警報/呼叫中心提供數據庫可用性，其中正常執行時間和可用性對於生命安全至關重要。

下面是來自一個業務關鍵應用程序的 connectionStrings 的範例行（為了我們的保護而進行了清理）：

<add name="MyCompany.MyApp.Properties.Settings.MyDbConnectionString"
connectionString="Data Source=Principal-DB;Failover Partner=Mirror-DB;
Initial Catalog=MyDb; Integrated Security=True; Persist Security Info=True;"
providerName="System.Data.SqlClient" />

大約半小時前，這是我們認為的場景：

1. DBA 在指定時間向所有使用者報告 Principal-DB 伺服器上的硬體維護需求，並建議他們在遇到數據庫連接問題時關閉並重新啟動客戶端應用程序。
2. DBA 從 Principal-DB 故障轉移到 Mirror-DB。客戶端應用程序不受影響。
3. DBA 關閉 Principal-DB 伺服器。
4. 一些客戶端應用程序開始在池連接上超時（正如預期的那樣）。遇到這些錯誤的使用者按照 DBA 的建議關閉並重新啟動。
5. 由於無法從數據庫接收響應，這些客戶端應用程序現在無法完全啟動。
6. 歡鬧隨之而來。

我們的理論是，由於 Principal-DB 根本不處於響應連接請求的狀態*，*當它通常會在處於恢復狀態時快速拒絕此類連接時，客戶端應用程序最終會等待整個分配的連接超時（預設，20 秒）讓主伺服器響應，然後返回超時錯誤，而無需嘗試連接到列出的故障轉移夥伴。

快速解決方法是將更新推送到包含交換數據源和故障轉移夥伴實例的 App.config 的客戶端應用程序，因此 Mirror-DB 現在是應用程序首先嘗試連接的伺服器。當我們故障回復到 Principal-DB 時，我們將不得不通過另一個應用程序更新來撤消此更改。

我需要一個更永久的修復。這不是我們對故障轉移對的預期行為，並且不能允許它再次發生。必須有一種方法來配置客戶端應用程序，以便它在這種情況下正確地嘗試連接到故障轉移夥伴，然後返回錯誤。

我發現了問題。

SQL Native Client 和 .NET SQL 數據提供程序應無縫連接到故障轉移夥伴，即使主伺服器已關閉；但是，這兩個提供程序的預設配置是嘗試 TCP/IP 和命名管道。

這個配置很好，並且可以正常工作，當伺服器仍然可用但主伺服器故障轉移到備份伺服器時，因為網路層連接會成功，但應用程序層連接會立即被拒絕，導致客戶端嘗試鏡子。但是，如果主伺服器沒有響應，客戶端將浪費整個預設的 20 秒超時時間，只是等待主伺服器響應，首先通過 TCP/IP，然後通過命名管道（它本身俱有預設的 20 到 30 -第二個網路級別的超時時間），因此在這種情況下，它會在沒有嘗試備份鏡像的情況下返回錯誤。

根據這篇 TechNet 文章，解決方案是強制客戶端以一種或另一種方式僅使用 TCP/IP 進行連接，這將很快失敗，客戶端有足夠的時間嘗試兩個合作夥伴。您可以手動配置數據提供程序來執行此操作，也可以通過指定要在連接字元串中使用的正確協議來逐個覆蓋其預設設置。包含強制 TCP/IP 的參數是Network=dbmssocn;. 最重要的是，SQL 客戶端在放棄並嘗試故障轉移鏡像之前有一個“三擊”方法，因此連接超時應該設置得足夠長，以便它能夠通過這個過程並至少嘗試一次故障轉移夥伴。30 秒的超時應該足夠了。

當我們的主數據庫伺服器再次斷電時，我們嘗試了這個修復，它確實有效。現在我們正在更新我們所有內部應用程序的配置文件（我們至少有六個桌面應用程序和內部網站點以這個故障轉移對為目標；它是一個深受喜愛的堆棧）。

引用自：https://dba.stackexchange.com/questions/50514