Windows 和 SQL Server 更新檔超過 3 年未應用時的更新檔策略
我所在的公司已經有一段時間沒有為他們的生產伺服器打更新檔了，SQL 2012 或 Windows 2012 都沒有。當我說“有一段時間”時，我的意思是，實際上“從不”——自安裝以來沒有更新檔或更新2012 年末。他們正在使用具有自動故障轉移功能的同步 AG 來實現冗餘，因此我們可以一次升級一個節點。
計劃是禁用自動故障轉移，更新第二個節點，故障轉移數據庫，然後更新第一個節點。
問題：你建議如何處理這個問題？一次將 3 年的數據庫和作業系統更新檔全部應用到第二個節點，然後故障轉移到該節點？節點可以有多少不同步並且仍然期望 AG 數據庫的無故障故障轉移？是先進行 Windows 更新還是 SQL CU 更好？
目標是最大限度地減少停機時間和故障轉移/故障回复的數量。
恕我直言，我建議將更新分解為主要的 SP 和作業系統與 SQL。這樣，如果有任何問題，您可以更輕鬆地回滾並查明問題。例如，推出 Server 2012 SP1 讓它成熟一兩個星期，然後做一個 SQL SP 等待一兩個星期，等等……
您的方法聽起來很適合修補輔助節點、故障轉移、修補主節點，然後平衡集群。
從修補作業系統開始。根據需要在輔助節點上安裝最新的 Windows Service Pack 和所有更新。當輔助節點完全修補後，將 SQL Server 故障轉移到輔助節點，如果一切正常，則開始更新主節點，直到兩個節點都完全修補。
對於 SQL Server，您需要在安裝累積更新之前在兩台主機之間安裝服務包和故障轉移，並且以相同的方式執行此操作。在輔助/故障轉移上安裝服務包，更新主/故障轉移。在輔助/故障轉移上安裝 CU，在主上安裝 CU 並慶祝。
因此，整個過程至少需要 6 次 sql 服務故障轉移，但滾動更新的好處是您可以在白天修補不活動的伺服器，並且故障轉移時間非常短，因此您可以儘早安排您喜歡的早晨或深夜。
我還會考慮在您使用伺服器時更新伺服器的韌體和驅動程序，與伺服器管理員（或文件）核實，某些伺服器喜歡在更新韌體之前更新驅動程序。