Sql-Server
高可用性解決方案中修補 SQL 節點的良好做法
我們的數據庫結構在 Window Failover Cluster Manager 中使用了兩個角色。
- 一種是用於 FCI - 在主數據中心的主動/被動節點之間切換。
- 一種是 SQL 可用性組設置將數據從主數據中心複製到 DR 數據中心。這也用於發生災難情況時的手動故障轉移。
我們的 IT 團隊希望在預定的停機時間定期對這些伺服器執行作業系統修補，發生這種情況時應用程序將處於離線狀態。這對我們有點幫助，因為我們不必擔心在修補另一個節點時故障轉移到另一個節點，但是我們可以假設我們可以在修補期間使數據庫完全離線。
我的問題是最好的方法是什麼，因為 IT 團隊可能對 FCI 或數據庫知之甚少。我不希望我們的數據庫意外故障轉移，因為在此過程中，活動 SQL 節點之一可能需要重新啟動。我正在考慮給他們以下指示。
- RDP進入節點活動集群組，可以通過執行powershell命令找到這個：Get-ClusterGroup並找到“集群組”的OwnerNodeValue。
- 打開故障轉移集群管理器擴展到角色，有兩個角色，一個用於 AG，一個用於 FCI。
- 右鍵點擊每個並選擇“停止角色”
- 執行更新檔，重新啟動等..
- 完成後，RDP 重新進入並在“Start Role”上恢復這兩個角色。
這會起作用嗎？它被認為是好的做法嗎？我希望強制故障轉移服務停止，以便 SQL 節點在伺服器重新啟動期間不會故障轉移到另一個節點。
通過分別考慮每個 SQL 實例來解決此問題。
修補 SQLDR\Inst_B
這是一個輔助副本，因此可以獨立修補/重新啟動。
- 將 SQLDR\Inst_B 切換為 ASYNC 副本（如果還沒有）
- 修補 SQLDB\Inst_B 並重新啟動（Windows 更新檔、SQL 更新檔等）
- 驗證 SQLDR 恢復並且 AG 正常。
- 如果需要，切換回 SYNC。
注意：當 Inst_B 離線時，Inst_A 上的 T-Logs 將保留，以便在 Inst_B 返回時重播。我不建議在 Inst_A 上進行索引維護或大數據載入時修補 Inst_B。如果 Inst_B 長時間停機（想想幾天），那麼您可能想要破壞 AG 副本。
修補 SQLFCIPrimary\Inst_A
- 修補被動節點並重新啟動。
- 故障轉移到被動節點。這將導致您的（希望是短暫的，例如 < 1 分鐘）中斷。
- 確認 AG 健康
- 修補新的被動節點並重新啟動。
- 如果需要，進行故障回复。
注意：由於您使用的是 MANUAL 故障轉移，因此不會有意外故障轉移到 Inst_B 的風險。
這是完成定期修補的最簡單方法，只需要一到兩次 FCI 故障轉移。沒有理由停止 WSFC 角色。
不管你先做 Inst_A 還是 Inst_B 都沒有關係，但我是風險不利的，所以我會從 Inst_B 開始。