設定被定義為具狀態服務的分割區中的副本及其角色。
重新設定是將一個組態移至另一個組態的程式。 它會變更某個狀態服務分割區的副本集。 舊的組態稱為先前的組態 （PC），而新的組態稱為目前的組態 （CC）。 Azure Service Fabric 中的重新設定通訊協定會保留一致性，並在複本集的任何變更期間維護可用性。
故障轉移管理器會針對系統中發生的不同事件啟動重新配置。 例如，如果主要節點失敗，則會啟動重新配置，將作用中的次要節點升級為主要節點。 另一個範例是當應用程式需要升級時，可能需要將主要節點移至另一個節點以便升級該節點。
重新設定類型
重新設定可分為兩種類型：
主要項目正在變更的重新配置：
- 故障轉移：故障轉移是對運行中的主要伺服器發生故障時進行重新配置。
- SwapPrimary：交換是重新設定，其中 Service Fabric 需要將執行的主要節點從某個節點移至另一個節點，通常是為了回應負載平衡或升級。
主要項目的重新配置位置未變。
重新設定階段
重新設定會在數個階段中繼續進行：
階段0：此階段會在交換主要重新設定中發生，其中目前的主要複本將狀態傳輸至新的主要複本，並轉換為作用中次要。
階段 1：此階段會在主伺服器變更的重新配置期間發生。 在此階段中，Service Fabric 會識別目前複本之間的正確主要複本。 在主要角色轉移重新配置期間不需要此階段，因為已選擇新的主節點。
階段2：在此階段期間，Service Fabric 可確保目前組態的大部分復本都能使用所有數據。
有數個其他階段僅供內部使用。
停滯的重新配置
重新設定可能會因為各種原因 而停滯不前 。 一些常見原因包括：
- 停機的副本：某些重新設定階段需要配置中的大部分副本為運行狀態。
- 網路或通訊問題：重新設定需要不同節點之間的網路連線能力。
- API 失敗：重新設定通訊協定需要服務實作完成特定 API。 例如，不接受可靠服務中的取消令牌會導致 SwapPrimary 重新設定停滯。
使用系統元件的健康情況報告，例如 System.FM、System.RA 和 System.RAP，診斷重新設定停滯的位置。 系統健康情況報告頁面描述這些健康情況報告。
後續步驟
如需 Service Fabric 概念的詳細資訊，請參閱下列文章：