升級可用性群組副本

適用於：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） 和更新版本的另一個選項是使用分散式可用性群組。
• 不支援使用 Cluster-Aware 更新 （CAU） Windows 功能來更新 Always On 可用性群組。

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

當您執行伺服器升級或更新時，請遵循下列指導方針，好讓停機時間及 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：

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

   注意

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

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

如需背景資訊，請參閱 CDC 功能在升級至最新 CU 之後可能會中斷。

相關內容

• 使用安裝精靈升級 SQL Server (安裝程式)
• 在 Windows 中從命令提示字元安裝和設定 SQL Server