如何防止實時伺服器檢測到強制故障轉移？
我們在 Windows Server 2016 上的 SQL 2017 中使用 AlwaysOn 可用性組，它由我們主站點上的兩台伺服器和遠端站點上的一台 DR 伺服器組成。
我們最近進行了一次內部 IT 災難恢復測試作為概念驗證，在此期間公司其他人員繼續使用主站點。我們隔離了遠端 DR 網路以模擬主站點的災難性故障，並測試了 DR 站點以確保我們可以啟動並成功使用它。到目前為止，測試進行得非常順利，但是在將事情恢復正常時我們遇到了一個重大問題。
由於測試期間主站點仍在使用，我主要關心的是確保實時數據庫不會被測試期間也使用的DR數據庫損壞，所以我在打開VPN之前刪除了DR數據庫我希望主站點開始自動播種回 DR 站點。但是，因為我必須在 DR 站點上強制進行故障轉移，所以在重新建立網路連結後，主站點檢測到 DR 伺服器已使用強制仲裁開關 (/fq) 啟動，它基本上關閉了兩個實時伺服器。我無法強制故障轉移回 Live 伺服器，不得不重建集群。
問題：如何防止 Live 伺服器檢測到在 DR 站點上執行了強制故障轉移？
我確實考慮在打開網路連結之前關閉 DR 伺服器，但我仍然不確定當它聯機時會發生什麼。在任何情況下，遠端數據庫都需要從 Live 重新播種。
快照
假設使用虛擬機，請在源站點斷開後對 DR 伺服器進行快照。我可能會建議先關閉伺服器，以便快照處於良好、乾淨的狀態。完成 DR 測試後，關閉 DR 伺服器，然後將其恢復為快照。這既簡單又便宜。唯一的缺點是源站點在測試期間不受保護，並且由於快照的原因，DR 節點可能會慢一些，具體取決於您的儲存基礎架構。哦，您的主數據庫必須有足夠的磁碟空間來排隊數據庫複製，直到站點重新連接。
使用複製
假設您正在使用虛擬機並且有足夠的磁碟空間，複製 DR 節點，關閉原始 DR 節點，然後對複製進行測試。完成後，刪除複製並使原始 DR 節點聯機。這解決了兩個問題：1）您不必重新同步整個數據庫，2）您不必逐出/加入集群節點。
這種方法的缺點是在測試期間，主伺服器必須對所有數據進行排隊，因此事務日誌可能會變得非常大。在您執行的測試中，這種情況正在發生，因此您顯然有足夠的磁碟空間來儲存日誌，這不是問題。
使用更多複製
一些組織在 DR 站點創建了一個“氣泡”網路，無法與生產 DR 網路通信。然後複製基礎設施伺服器（域控制器、DNS 等），並在氣泡中使複製上線。然後將需要參與 DR 測試的其他伺服器複製到氣泡中。這允許您在 DR 測試期間保持真實的 DR 伺服器線上和正常執行。除了真正的故障排除之外，這幾乎是最安全的，因為如果主站點在 DR 測試開始 5 小時後被破壞會發生什麼？如果您斷開了站點的連接，您將失去 5 小時的數據。
當然，這樣做的缺點是它可能成為一項艱鉅的任務，需要大量的員工時間、硬體等。
Evict and Rejoin
正如上面評論中提到的，您可以在 DR 站點重新連接之前從集群中驅逐 DR 節點，然後將其重新加入集群並將節點添加回可用性組。這相當簡單並且需要最少的硬體，但它確實有一個缺點，就是在 DR 測試期間讓您的主站點不受保護。