在停機時間和資料遺失最少的情況下升級及更新可用性群組伺服器

當您將伺服器執行個體從 SQL Server 2012 更新或升級至某個 Service Pack 或較新的版本時，您可以透過執行輪流更新或升級，將可用性群組的停機時間減少至只有單一手動容錯移轉的時間。 如果要升級 SQL Server 版本，這稱為輪流升級；如果要以 Hotfix 或 Service Pack 更新目前的 SQL Server 版本，則稱為輪流更新。

這個主題僅限討論 SQL Server 升級/更新。 如果是高可用性 SQL Server 執行個體執行所在的作業系統相關升級/更新，請參閱針對作業系統升級進行 AlwaysOn 可用性群組的跨叢集移轉

AlwaysOn 可用性群組的輪流升級/更新最佳作法

當您執行伺服器升級/更新時，應該要觀察以下最佳作法，好讓停機時間及可用性群組的資料遺失情況降至最低：

• 在開始輪流升級/更新之前，

  • 至少在其中一個同步認可複本上執行手動容錯移轉練習

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

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

• 一定要先升級/更新遠端次要複本節點，然後是本機次要複本節點，最後是主要複本節點。

• 在進行升級的資料庫上，不會發生備份。 在升級次要複本之前，請設定自動備份喜好設定，只在主要複本上執行備份。 在升級主要複本之前，請修改此設定，只在次要複本上執行備份。

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

• 先將可用性群組容錯移轉到包含次要複本的已升級節點之前，請勿升級主要複本節點。 否則，用戶端應用程式在主要複本的升級/更新期間可能會受困於停機時間延長。

• 一定要將可用性群組容錯移轉到同步認可的次要複本節點。 如果您容錯移轉到非同步認可的次要複本，資料庫將會遭受資料遺失之苦，而且資料移動會自動暫停，直到您手動繼續資料移動為止。

• 在您升級/更新其他任何次要複本節點之前，請勿升級/更新主要複本節點。 已升級的主要複本將無法再傳送記錄到尚未升級至相同版本的次要複本。 當移至次要複本的資料移動作業暫停時，該複本無法進行自動容錯移轉，而且您的可用性資料庫很容易發生資料遺失。

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

輪流升級/更新程序

實際上，確切的程序將取決於一些因素，例如可用性群組的部署拓撲和每個複本的認可模式。 但是在最簡單的案例中，輪流升級/更新是多階段的程序，其最簡單的形式包含以下步驟：

1. 在所有同步認可複本上移除自動容錯移轉

2. 升級/更新執行非同步認可次要複本的所有遠端伺服器執行個體

3. 升級/更新目前未執行主要複本的所有本機伺服器執行個體

4. 手動將可用性群組容錯移轉到同步認可的次要複本

5. 升級/更新之前裝載主要複本的伺服器執行個體

6. 視需要設定自動容錯移轉夥伴

必要時，您可以執行額外的手動容錯移轉，讓可用性群組回到原始的組態。

具有一個遠端次要複本的可用性群組

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

在此情況下，您必須在輪流升級/更新期間，將可用性群組容錯移轉至非同步認可的次要複本。 為了防止資料遺失，請將認可模式變更為同步認可，並等候次要複本同步處理，然後再容錯移轉可用性群組。 因此，輪流升級/更新程序可能如下所示：

1. 升級/更新遠端伺服器

2. 將認可模式變更為同步認可

3. 等到同步處理狀態變成 SYNCHRONIZED

4. 將可用性群組容錯移轉到遠端站台

5. 升級/更新本機 (主要站台) 伺服器

6. 將可用性群組容錯移轉到主要站台

7. 將認可模式變更為非同步認可

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

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

• 在主要站台上升級/更新 SQL Server 時，請將可用性模式變更回非同步認可，當您再次準備好要容錯移轉至主要站台時，再還原成同步認可模式。

包含容錯移轉叢集執行個體節點的可用性群組

如果可用性群組包含容錯移轉叢集執行個體 (FCI) 節點，您應該先升級/更新非使用中節點，然後再升級/更新使用中節點。 下圖說明具有 FCI 的常見可用性群組案例 (為了擁有本機高可用性及 FCI 之間用於遠端災害復原的非同步認可) 以及升級順序。

1. 升級/更新 REMOTE2

2. 將 FCI2 容錯移轉到 REMOTE2

3. 升級/更新 REMOTE1

4. 升級/更新 PRIMARY2

5. 將 FCI1 容錯移轉到 PRIMARY2

6. 升級/更新 PRIMARY1

升級/更新具有多個可用性群組的 SQL Server 執行個體

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

可用性群組	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

此升級/更新順序的平均停機時間少於每個可用性群組的兩次容錯移轉。 產生的組態如下表所示。

可用性群組	Node1	Node2	Node3
AG1		Primary
AG2	Primary
AG3			Primary

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