將伺服器實例從 SQL Server 2012 更新或升級至 Service Pack 或更新版本時，您可以藉由執行循序更新或升級，將可用性群組的停機時間減少為單一手動故障轉移。 若要升級 SQL Server 版本，稱為滾動升級;若要使用 Hotfix 或 Service Pack 更新目前的 SQL Server 版本，則稱為滾動更新。
本主題將討論限制為僅限 SQL Server 升級/更新。 如需有關高可用性 SQL Server 實例所執行的作業系統相關升級/更新，請參閱作業系統升級的 AlwaysOn 可用性群組跨叢集遷移
AlwaysOn 可用性群組的滾動升級/更新最佳做法
執行伺服器升級/更新時，應該觀察下列最佳做法，以將可用性群組的停機時間和數據遺失降到最低：
在開始進行滾動升級或更新之前，
在至少一個同步提交的複本上執行手動故障轉移演練
在每一個可用性資料庫上執行完整資料庫備份來保護資料
在每個可用性資料庫上執行 DBCC CHECKDB
一律先升級/更新遠程次要復本節點，然後是下一個本機次要復本節點，最後一個是主要復本節點。
備份無法發生在正在升級的資料庫上。 在升級次要複本之前，請設定自動備份喜好設定，只在主要複本上執行備份。 升級主要複本之前，請先修改此設定，只在次要複本上執行備份。
若要防止可用性群組在升級/更新程式期間發生非預期的故障轉移，請在開始之前移除所有同步認可複本的可用性故障轉移。
不要在可用性群組故障轉移到具有次要複本的升級節點之前升級主要複本節點。 否則，在主要複本的升級/更新期間，用戶端應用程式可能會遭受延長停機時間。
一律將可用性群組故障轉移至同步認可次要復本節點。 如果您故障轉移至異步認可次要複本，資料庫將會遺失數據，而且數據移動會自動暫停，直到您手動繼續數據移動為止。
升級/更新任何其他次要復本節點之前，請勿升級/更新主要復本節點。 升級的主要復本無法再將記錄寄送至尚未升級至相同版本的任何次要複本。 當資料移至次要複本的作業暫停時，該次要複本將無法進行自動容錯移轉，並且您的可用性資料庫將面臨資料遺失的風險。
在執行可用性群組的故障轉移之前，請確認故障轉移目標的同步處理狀態為 SYNCHRONIZED。
滾動升級/更新流程
實際上，確切的過程將取決於您可用性群組的架構及每個復本的認可模式等因素。 但在最簡單的案例中，滾動升級/更新是多階段程式，其最簡單的形式涉及下列步驟：
在所有同步認可複本上移除自動容錯移轉
更新或升級所有執行異步提交副本的遠端伺服器實例
升級/更新目前未執行主要複本的所有本地伺服器實例
手動將可用性群組切換至同步提交的次要複本
升級/更新先前裝載主要複本的伺服器實例
視需要設定自動故障轉移夥伴
如有必要，您可以執行額外的手動故障轉移，將可用性群組恢復到原始設定。
具有一個遠端次要複本的可用性群組
如果您只針對災難復原部署可用性群組，您可能需要將可用性群組故障轉移至異步提交的次要複本。 下圖說明這類組態：
在此情況下，您必須在滾動升級/更新期間，將可用性群組故障移轉到異步提交次級複本。 若要防止資料遺失，請將認可模式變更為同步認可，並等候次要複本同步處理，再對可用性群組進行故障轉移。 因此，滾動升級/更新程式可能如下所示：
升級/更新遠端伺服器
將認可模式變更為同步認可
等候同步處理狀態為SYNCHRONIZED
將可用性群組故障轉移至遠端站點
升級/更新本機 （主要月臺） 伺服器
將可用性群組故障轉移至主要月臺
將認可模式變更為非同步認可
由於同步認可模式不是數據同步處理至遠端站點的建議設定，因此用戶端應用程式可能會在設定變更之後立即注意到資料庫延遲增加。 此外，執行故障轉移會導致捨棄所有未驗證的記錄訊息。 由於兩個網站之間的網路延遲很高，因此棄置的日誌訊息數量可能會相當大，導致用戶端遭遇大量交易失敗。 您可以執行下列動作，將用戶端應用程式的影響降至最低：
謹慎選擇維護期間，使其發生於用戶端流量較低的期間
在主站點上升級/更新 SQL Server 時，請將可用性模式變更回異步提交，然後在準備好再次切換到主站點時切換回同步提交。
具有故障轉移叢集實例節點的可用性群組
如果可用性群組包含故障轉移叢集實例 （FCI） 節點，您應該先升級/更新非使用中的節點，再升級/更新作用中節點。 下圖說明了一個常見的可用性群組情境，其中包含本機高可用性的 FCI，以及 FCI 之間的遠端災難復原用異步提交，並且說明升級的順序。
升級/更新REMOTE2
將FCI2故障轉移至REMOTE2
升級/更新REMOTE1
升級/更新PRIMARY2
將FCI1故障轉移至PRIMARY2
升級/更新PRIMARY1
使用多個可用性群組升級/更新 SQL Server 實例
如果您在不同的伺服器節點上運行具有主要副本的多個可用性群組（活躍/活躍配置），升級或更新路徑將涉及更多故障轉移步驟，以在過程中保持高可用性。 假設您在三個伺服器節點上執行三個高可用性群組，如下表所示，且所有次要複本都以同步提交模式執行。
| 可用性群組 | Node1 | Node2 | Node3 |
|---|---|---|---|
| AG1 | 主要 | ||
| AG2 | 主要 | ||
| AG3 | 主要 |
根據您的情況，依照以下順序進行負載平衡的滾動升級/更新可能相當適合：
將 AG2 故障轉移至 Node3 （釋放 Node2）
升級/更新 Node2
將 AG1 切換至 Node2，以便釋放 Node1 的資源。
升級/更新 Node1
將 AG2 和 AG3 切換至 Node1，以釋放 Node3
升級/更新 Node3
將 AG3 故障轉移至 Node3
此升級/更新順序的平均停機時間在每個可用性群組中少於兩次切換。 產生的組態會顯示在下表中。
| 可用性群組 | Node1 | Node2 | Node3 |
|---|---|---|---|
| AG1 | 主要 | ||
| AG2 | 主要 | ||
| AG3 | 主要 |
根據您的特定實作，升級/更新路徑可能會有所不同，用戶端應用程式體驗的停機時間也可能有所不同。