升級可用性群組副本

適用於：SQL Server

將裝載 Always On 可用性群組 (AG) 的 SQL Server 執行個體升級為新的 SQL Server 版本、新的 SQL Server Service Pack 或累積更新，或安裝至新的 Windows Service Pack 或累積更新時，您可透過執行輪流升級來將主要複本的停機時間減少至僅單一手動容錯移轉 (容錯回復為原始主要複本時則為兩次手動容錯移轉)。

在升級過程中，無法使用次要複本進行容錯移轉或唯讀作業，而且在升級完成之後，次要複本可能需要一些時間才能趕上主要複本節點，視主要複本節點的活動量而定 (因此預期會有很高的網路流量)。

另請注意，在初始容錯移轉至執行較新版 SQL Server 的次要複本之後，該 AG 中的資料庫將會進行升級，以更新到最新版本。 在這段期間內，這些資料庫都不會有可讀取的複本。 首次故障切換之後的停機時間長短，取決於 AG 中的資料庫數目。 如果您打算容錯回復為原始的主要複本，此步驟在您進行容錯回復時不會重複。

注意

本文僅限討論 SQL Server本身的升級。 其未涵蓋包含 Windows Server 容錯移轉叢集 (WSFC) 的作業系統升級。 在 Windows Server 2012 R2 之前的作業系統版本中，Windows 作業系統無法針對裝載容錯移轉叢集的系統進行升級。 若要升級在 Windows Server 2012 R2 上執行的叢集結點，請參閱叢集作業系統輪流升級 \(機器翻譯\)。

Prerequisites

在開始之前，請檢閱以下重要資訊：

• 支援的版本與版次升級：確認您是否可以從您的 Windows 作業系統版本和 SQL Server 版本升級至最新版的 SQL Server。 例如，如果您直接從 SQL Server 2005 執行個體升級，則會升級您的資料庫相容性層級。

• 選擇資料庫引擎升級方法：若要依正確順序升級，除了根據您所檢閱的＜支援的版本與版次升級＞，也請根據您環境中安裝的其他元件，來選取適當的升級方法和步驟。

• 計劃和測試資料庫引擎升級計畫：檢閱版本資訊與已知的升級問題、升級前檢查清單，並開發和測試升級計畫。

• 安裝 SQL Server 的硬體和軟體需求：檢閱安裝 SQL Server 的軟體需求。 如果需要其他軟體，請先將其安裝在每個節點上，然後開始升級程序，以將任何停機時間降到最低。

• 檢查是否針對任何 AG 資料庫使用異動資料擷取或複寫：如果啟用 AG 中的任何資料庫進行異動資料擷取 (CDC)，請完成這些指示。

注意

不支援在同一個可用性群組 (AG) 中混用不同版本的 SQL Server 執行個體，除非在進行滾動升級時。而升級應該快速進行，因此不應長時間維持在這種狀態。 升級 SQL Server 2016 (13.x) 和更新版本的另一個選項，是透過使用分散式可用性群組。

注意

不支援使用叢集感知更新 （CAU） Windows 功能來更新 AlwaysOn 可用性群組。

可用性群組的循環升級基礎概念

當您執行伺服器升級或更新時，請遵循下列指導方針，好讓停機時間及 AG 的資料遺失情況降至最低：

• 開始輪流升級之前：

  • 至少在其中一個同步認可複本執行個體上進行手動故障轉移練習。

  • 在每一個可用性資料庫上執行完整資料庫備份來保護資料

  • 在每一個可用性資料庫上執行 DBCC CHECKDB

• 請務必先升級遠端次要複本執行個體，然後是本機次要複本執行個體，最後是主要複本執行個體。

• 對於正在進行升級的資料庫，無法進行備份。 在升級次要複本之前，請設定自動備份喜好設定，只在主要複本上執行備份。 執行版本升級時，無法讀取任何複本或使用其執行備份。 執行非版本升級時，您可先設定要在次要複本上執行的自動備份，然後再升級主要複本。

• 在版本升級期間，於升級可讀取的次要複本之後，以及在將主要複本切換至已升級的次要複本或直接升級主要複本之前，皆無法存取可讀取的次要複本。

• 為了避免 AG 在升級程序期間發生意外的容錯移轉，請從所有同步認可複本中移除可用性容錯移轉，再開始操作。

• 在將 AG 容錯移轉至已升級的包含次要複本的執行個體之前，請勿升級主要複本執行個體。 否則，客戶端應用程式在主要副本執行個體升級期間可能會面臨較長的停機時間。

• 一定要將 AG 容錯移轉至同步認可的次要複本執行個體。 若您故障轉移到非同步提交的次要副本執行個體，資料庫將會面臨資料遺失的風險，而且資料移動將自動暫停，直到您手動恢復資料移動為止。

• 在您升級或更新其他任何次要複本執行個體之前，請勿升級主要複本執行個體。 已升級的主要複本將無法再傳送記錄到尚未升級 SQL Server 執行個體至相同版本的次要複本。 當資料移至次要複本的作業暫停時，該次要複本將無法進行自動容錯移轉，並且您的可用性資料庫將面臨資料遺失的風險。 這也適用於輪流升級期間，當您從舊的主要手動容錯移轉至新的主要時。 因此，在升級舊主要之後，您可能需要繼續同步處理。

• 在容錯移轉 AG 之前，請確認容錯移轉目標的同步處理狀態為 SYNCHRONIZED。

  警告

  在已安裝舊版 SQL Server 的伺服器上安裝 SQL Server 的新執行個體或新版本時，可能會意外導致舊版 SQL Server 所裝載的任何可用性群組中斷。這是因為在 SQL Server 執行個體或版本的安裝期間，SQL Server 高可用性模組 (RHS.EXE) 會開始升級。 這會導致伺服器上擔任主要角色的現有可用性群組暫時中斷。 因此，當您在已裝載較舊 SQL Server 版本 (具有可用性群組) 的系統中安裝新版 SQL Server 時，強烈建議您執行下列其中一項：

  • 在維護期間安裝新版 SQL Server。

  • 將可用性群組容錯移轉至次要複本，使其在新的 SQL Server 執行個體安裝期間不是主要的。

輪流升級程序

實際上，具體程序取決於多種因素，例如 您的 AG 的部署拓撲結構以及每個複本的提交模式。 但是在最簡單的案例中，輪流升級是多階段的程序，其最簡單的形式包含以下步驟：

1. 在所有同步認可複本上移除自動容錯移轉
2. 升級所有非同步提交的次要複本執行個體。
3. 升級所有遠端同步提交之次要複本執行個體。
4. 升級所有本機同步提交的次要副本執行個體。
5. 手動將 AG 容錯移轉至 (新升級的) 本機同步認可次要複本。
6. 升級或更新先前承載主要複本的本機複本執行個體。
7. 視需要設定自動容錯移轉夥伴。

必要時，您可以執行額外的手動容錯移轉，讓 AG 回到原始的設定。

注意

升級同步提交的複本並使其離線，並不會延遲主伺服器的交易。 在次要複本中斷連線後，交易會在主要複本上立即認可，而不會等候記錄強行寫入至次要複本。

如果將 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 設定為 1 或 2，在更新過程中，當有相對數量的同步次要副本無法使用時，主要副本可能無法用於讀取或寫入。

注意

當您將次要復本就地升級至較新版本的 SQL Server 時，可用性群組內的資料庫會維持在同步處理/復原或同步處理/在復原狀態中，直到可用性群組手動故障轉移為止，這會完成復原並升級資料庫。 升級後的主要複本無法再將記錄傳送至任何較低版本的次要複本，且資料移動會停止，此外該複本不會發生自動容錯移轉，且您的可用性資料庫很可能會遺失資料。 在升級舊的主要伺服器之後，您可能需要恢復同步。 建議您先升級所有次要複本，再故障切換至具有新版本的複本。 如此一來，您可以選擇在資料庫升級為新格式之後執行容錯移轉。

具有一個遠端次要複本的 AG

如果您部署 AG 只是為了災害復原，您可能必須將 AG 容錯移轉至非同步認可的次要複本。 下圖說明這類組態：

在這種情況下，您必須在進行逐步升級時，將 AG 切換到非同步提交的次要副本。 為了防止資料遺失，請將認可模式變更為同步認可，並等候次要複本完成同步化，再容錯移轉 AG。 因此，輪流升級程序可能如下所示：

1. 升級位於遠程站台的次要複本執行個體
2. 將認可模式變更為同步認可
3. 等到同步狀態變成 SYNCHRONIZED
4. 將 AG 容錯移轉至遠端站台上的次要複本
5. 升級或更新主要站台的本地複本執行個體
6. 將 AG 容錯移轉回主要站台
7. 將認可模式變更為非同步認可

因為同步提交模式不是建議用於與遠端站台資料同步的設定，所以客戶端應用程式可能會注意到設定變更後資料庫延遲會立即增加。 此外，執行容錯移轉會導致所有未認可的日誌訊息被丟棄。 捨棄的記錄訊息數量可能很龐大，這是因為兩個站台之間的高度網路延遲，導致用戶端遭遇大量的交易失敗。 您可以執行下列動作，讓用戶端應用程式的影響降至最低：

• 謹慎選擇維護期間，使其發生於用戶端流量較低的期間

• 在主要站台升級或更新 SQL Server 時，請將可用性模式更改為非同步提交，當您準備再次切換至主要站台時，將其還原為同步提交模式。

具有容錯移轉叢集執行個體節點的 AG

若 AG 包含容錯移轉叢集實例 (FCI) 節點，您應該先升級不活動的節點，再升級活動的節點。 下圖說明一個常見的 AG 情境，其中具備 FCI 提供本地高可用性，並且在 FCI 之間進行異地災害復原的非同步提交，還包括升級順序。

1. 升級或更新 REMOTE2
2. 將 FCI2 容錯移轉至 REMOTE2
3. 升級或更新 REMOTE1
4. 升級或更新 PRIMARY2
5. 將 FCI1 容錯移轉至 PRIMARY2
6. 升級或更新 PRIMARY1

升級或更新具有多個 AG 的 SQL Server 執行個體

若您正在執行多個 AG，而其中的主要複本位於不同的伺服器節點上 (主動/主動設定)，則升級路徑會牽涉到更多的容錯移轉步驟，以保留程序中的高可用性。 假設您在三個伺服器節點上執行三個可用性群組（AG），且其所有複本都是以同步認可模式進行，如下表所示：

AG	Node1	Node2	Node3
AG1	Primary
AG2		Primary
AG3			Primary

在您的案例中，可能適合依照以下順序執行負載平衡的輪流升級：

1. 將 AG2 切換至 Node3 (以釋放 Node2)
2. 升級或更新 Node2
3. 將 AG1 容錯移轉至 Node2 (以釋放 Node1)
4. 升級或更新 Node1
5. 將 AG2 和 AG3 同時容錯移轉至 Node1 (以釋放 Node3)
6. 升級或更新 Node3
7. 將 AG3 容錯移轉至 Node3

此升級順序的平均停機時間少於每個可用性群組（AG）的兩次故障切換。 產生的設定如下表所示。

AG	Node1	Node2	Node3
AG1		Primary
AG2	Primary
AG3			Primary

根據您的特定實作方式，您的升級路徑可能會有不同，用戶端應用程式遇到的停機時間也可能會有差異。

注意

在許多情況下，您在完成滾動升級後會回退至原始主要複本。

分散式可用性群組的輪流升級

若要執行分散式可用性群組的輪流升級，請先升級所有次要複本。 接下來，進行轉發器的容錯移轉，然後升級第二個可用性群組中最後剩餘的執行個體。 在所有其他複本都升級後，請進行全域主節點的故障轉移，然後升級第一個可用性群組中最後剩餘的執行個體。 下方提供包含步驟的詳細圖表。

根據您的特定實作方式，您的升級路徑可能會有不同，用戶端應用程式遇到的停機時間也可能會有差異。

注意

在許多情況下，在完成滾動升級後，您會切換回原始主要副本。

升級分散式可用性群組的一般步驟

1. 備份所有資料庫，包括系統資料庫及參與可用性群組的資料庫。
2. 升級並重新啟動第二個可用性群組的所有次要副本（即下游）。
3. 升級並重新啟動第一個可用性群組的所有次要複本 (即上游)。
4. 將轉寄站的主要伺服器切換到次要可用性群組的已升級次要複本。
5. 請等候資料同步。 資料庫應在所有同步提交複本上顯示為已同步，且全域主要應與轉接器同步。
6. 升級並重新啟動次要可用性群組中最後剩餘的執行個體。
7. 將全域主伺服器切換到升級的次要伺服器的第一個可用性群組。
8. 升級主要可用性群組中最後剩餘的執行個體。
9. 重新啟動剛升級的伺服器。
10. (選擇性) 將兩個可用性群組都還原至其原始的主要複本。

重要

請在每個步驟之間驗證同步。 在繼續下一個步驟前，請確認您的同步提交複本在可用性群組內的確實同步，而且您的全域主節點與分散式 AG 中的中繼器同步。

建議：在您每次驗證同步時，請同時在 SQL Server Management Studio 中重新整理資料庫節點和分散式 AG 節點。 在所有項目都同步後，請儲存各複本狀態的螢幕擷取畫面。 這有助於您掌握當下進行到哪個步驟，證明在進行下一步之前一切運作正常，並在發生任何錯誤時協助您進行疑難排解。

分散式可用性群組輪流升級的圖表範例

可用性群組	主要副本	次要複本
AG1	NODE1\SQLAG	NODE2\SQLAG
AG2	NODE3\SQLAG	NODE4\SQLAG
DistributedAG	AG1 (全域)	AG2 (轉寄站)

如圖所示，升級實例的步驟如下：

1. 備份所有資料庫，包括系統資料庫及參與可用性群組的資料庫。
2. 升級 NODE4\SQLAG (AG2 的次要組件) 並重新啟動伺服器。
3. 升級 AG1 的次要元件 NODE2\SQLAG，然後重新啟動伺服器。
4. 將 AG2 從 NODE3\SQLAG 容錯移轉至 NODE4\SQLAG。
5. 升級 NODE3\SQLAG 並重新啟動伺服器。
6. 將 AG1 從 NODE1\SQLAG 容錯移轉至 NODE2\SQLAG。
7. 升級 NODE1\SQLAG 並重新啟動伺服器。
8. (選擇性) 恢復到原來的主要副本。
   1. 將 AG2 從 NODE4\SQLAG 切換至 NODE3\SQLAG。
   2. 將 AG1 從 NODE2\SQLAG 容錯回復至 NODE1\SQLAG。

如果每個可用性群組中各存在第三個複本，則會在 NODE3\SQLAG 和 NODE1\SQLAG 之前升級。

重要

請在每個步驟之間驗證同步。 在繼續下一步之前，請確認您的同步提交複本在可用性群組內已同步，並且您的全域主伺服器與分散式 AG 中的轉寄站已同步。

建議：每次確認同步處理時，都請重新整理 SQL Server Management Studio 中的資料庫節點和分散式 AG 節點。 在所有項目都同步處理後，請建立螢幕擷取畫面並加以儲存。 這有助於您掌握當下進行到哪個步驟，證明在進行下一步之前一切運作正常，並在發生任何錯誤時協助您進行疑難排解。

異動資料擷取或複寫的特殊步驟

根據所套用的更新，可能需要額外的步驟才能啟用 AG 複本資料庫進行異動資料擷取或複寫。 請參閱更新的版本資訊，以判斷是否需要下列步驟：

1. 升級每個次要複本。

2. 升級所有次要複本之後，將 AG 容錯移轉至已升級的執行個體。

3. 在裝載主要複本的執行個體上執行下列 Transact-SQL：

   SQL

   EXECUTE [master].[sys].[sp_vupgrade_replication];
   

   注意

   此命令可能需要幾分鐘才能完成執行。 如果使用 SQL Server 2019 CU1 或更新版本，請略過此步驟。 若要深入瞭解，請檢閱 KB4530283。

4. 升級原本為主要複本的執行個體。

如需背景資訊，請參閱 CDC functionality may break after upgrading to the latest CU (CDC 功能可能會在升級至最新版 CU 之後中斷)。

另請參閱

• 使用安裝精靈升級 SQL Server (安裝程式)
• 從命令提示字元安裝 SQL Server