SQL 集群更新 - 故障轉移到未打更新檔的節點

所以當更新一個兩節點集群時，我們的程序是這樣的：

1. 備份所有數據庫。
2. 將所有 SQL 集群角色故障轉移到節點 A。
3. 在節點 B（被動）上安裝更新檔。
4. 重啟節點 B。
5. 將所有 SQL 集群角色故障轉移到節點 B。
6. 在節點 A（被動）上安裝更新檔。
7. 重啟節點 A

我的理解是，在第 5 步中，更新後的節點將在接收傳入連接之前執行一些更新，如日誌中所示。

如果在節點 A 更新之前發生另一個故障轉移會發生什麼？例如，如果我在節點 B 上更新到更高的 CU。故障轉移會失敗還是只是故障轉移並在較低的 CU 級別上自行啟動？

在使用更高版本的 SQL Server 程式碼修補節點 B 後，在節點 B 上打開數據庫時，該數據庫將通過一系列腳本進行升級。這些腳本使用與數據庫中完成的任何其他活動相同的 ACID 合規性進行管理。升級是通過事務控制的全有或全無操作。

如果在節點 B 上的數據庫升級期間發生集群故障轉移，任何未送出的更改都將在節點 A 上打開數據庫時作為恢復過程的一部分向後或向前滾動。這應該允許節點 A 可靠地打開數據庫。話雖如此，如果數據庫在故障轉移之前已經完全升級到新版本，如果沒有升級到與節點B相同的引擎程式碼，節點A將無法打開數據庫。您可以避免這種情況通過在集群中有第三個成員，這樣您首先升級未使用的節點 C，然後升級未使用的節點 B，然後故障轉移到節點 B，然後升級節點 A。如果節點 A 出現問題阻止升級或故障轉移在節點 A 的更新發生時，出於任何原因需要發生，您只需從節點 B 故障轉移到節點 C，

僅供參考，對於關鍵業務數據，步驟 1 中備份過程的一部分可能應該涉及通過還原到其他機器來測試該備份，以確保您擁有可靠的備份。

我的同事爭辯說，在 Hannah 的上述回答中，以下陳述是錯誤的：

如果沒有升級到與節點 B 相同的引擎程式碼，節點 A 將無法打開數據庫

在兩個節點集群上對其進行測試後，我的同事似乎是對的。故障轉移到未修補的節點時，SQL 伺服器降級回較低的 CU。見下文：

• 節點 A，活動節點，未打更新檔
• 節點 B，被動節​​點，未打更新檔

1. 節點 B，已修補，從 CU22 到 CU25

節點 A，活動，故障轉移前：

select @@VERSION;

Microsoft SQL Server 2017 (RTM-CU22) (KB4577467) - 14.0.3356.20 (X64)   
Aug 20 2020 22:33:27   
Copyright (C) 2017 Microsoft Corporation  
Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2019 Standard 10.0 <X64> (Build 17763: ) (Hypervisor) 

2. 故障轉移到節點 B

節點 B，活動，故障轉移後

select @@VERSION;
   
Microsoft SQL Server 2017 (RTM-CU25) (KB5003830) - 14.0.3401.7 (X64)   
Jun 25 2021 14:02:48   
Copyright (C) 2017 Microsoft Corporation  
Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2019 Standard 10.0 <X64> (Build 17763: ) (Hypervisor) 

3. 第二次故障轉移回節點 A

4. 節點 A，活動，故障轉移後

select @@VERSION;

Microsoft SQL Server 2017 (RTM-CU22) (KB4577467) - 14.0.3356.20 (X64)   
Aug 20 2020 22:33:27   
Copyright (C) 2017 Microsoft Corporation  Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2019 Standard 10.0 <X64> (Build 17763: ) (Hypervisor) 

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