「提升」是指命令複本結束其複本模式，並轉換為完整讀寫作業的程序。
這很重要
晉升操作並非自動進行。 如果主要伺服器上發生失敗，系統並不會獨立切換到讀取複本。 提升作業一律需要使用者的操作。
你可以用兩種不同的方式推廣複製品：
提升至主要伺服器
此動作會將複本提升為主要伺服器的角色。 在此程序中，目前的主要伺服器會降級為複本角色，兩者的角色會交換。 若要成功升級，您需要為目前的主要執行個體設定虛擬端點做為寫入者端點，並為預定要升級的複本設定虛擬端點做為讀取者端點。 只有在讀取器端點設定中包含目標複本時，提升才會成功。 具有來源伺服器上 Microsoft.DBforPostgreSQL/servers/write 權限的使用者可以執行切換作業。
如果主伺服器有任何損壞的副本，請先移除這些副本，再啟動升格到主要伺服器的操作。 在此程序中，讀取複本會升階成為新的主要伺服器。 此作業可能會造成約 1 至 3 分鐘的短暫停機，具體時間取決於進行升級時的複寫延遲情況 (若為計畫性升級)。 升階完成後，先前的主要伺服器會重新設定為讀取複本。
下圖顯示升遷前伺服器的配置及升遷操作成功完成後的狀態。
提升至獨立伺服器並從複寫中移除
當您選擇此選項時，複本會提升為獨立伺服器，並從複寫程序中移除。 因此，主要伺服器和提升的伺服器都會作為兩部獨立的讀寫伺服器運作。 雖然你可以設定虛擬端點，但這並非此操作的必要條件。 即使讀取器端點先前指向該伺服器，新提升的伺服器已不再是任何現有虛擬端點的一部分。 如果應用程式應連線至新升級的複本，請更新應用程式的連線字串，使其指向新升級的複本。
下圖顯示伺服器在升級前的設置方式，以及成功成為獨立伺服器後的配置。
這很重要
提升至獨立伺服器並從複寫中移除動作，與先前的提升功能回溯相容。
這很重要
伺服器對稱性：若要使用「提升至主要伺服器」作業成功完成提升，主要伺服器和複本伺服器都必須有相同的層級和儲存體大小。 例如，若主伺服器有 2 個 vCore，而副本有 4 個 vCore，唯一可行的選項是使用「升遷至獨立伺服器並移除複製」動作。 此外，它們還需要共享分配 共享記憶體的參數值。
對於兩種推廣方式，請考慮以下選項：
已規劃：此選項可確保在提升之前同步處理資料。 它在接受客戶端連線之前會套用所有擱置的記錄，以確保資料一致性。
強制：此選項可以在發生區域中斷等案例中實現快速復原。 一旦伺服器處理達成最接近一致狀態所需的 WAL 檔案，伺服器就會開始運作，而無需等候同步處理主要伺服器中的所有資料。 如果你用這個選項推廣副本，當你將副本從主節點解除連結時的延遲，就代表損失了多少資料。
這很重要
「強制」提升選項專為解決區域性中斷問題，在這種情況下，其會跳過所有檢查 (包括伺服器對稱性需求) 並繼續提升。 此優先事項是即時伺服器可用性以應對災難情境。 然而，若未符合文件中所述的讀取複本要求，尤其是伺服器對稱性的要求，則不允許在區域關閉情境之外使用 Forced 選項，因為這可能導致複寫中斷等問題。
了解如何將讀取複本切換到主要伺服器和提升至獨立伺服器並從複寫中移除。
組態管理
控制平面會把讀取副本當作獨立伺服器，所以你可以獨立管理設定。 此方法為讀取調整案例提供了彈性。 然而，當你使用複本進行災難復原時，必須確保設定符合需求。
提升作業不會延續特定的組態和參數。 以下是一些值得注意的項目：
- PgBouncer：在提升過程中不會複寫內建的 PgBouncer 連線集區的設定和狀態。 如果您在主要伺服器啟用 PgBouncer，但沒有在複本啟用，升級後複本上的 PgBouncer 仍會保持停用。 要在新升級的伺服器上使用 PgBouncer，必須在升級動作前或之後啟用。
- 異地備援備份儲存體：不會轉移異地備份設定。 由於複本無法啟用異地備份，因此提升的主要伺服器 (先前為複本) 在提升之後就沒有主要伺服器。 你只能在建立標準伺服器時啟用這個功能（不能在複製伺服器上）。
- 參數：如果主要伺服器與唯讀複本上的值不同，升級為主要伺服器時也不會變更。 影響共享記憶體大小的參數必須在主記憶體與副本上擁有相同的值。 此要求詳述於 參數 章節。
- Microsoft Entra 認證：如果主副本已設定 Microsoft Entra 認證，但副本使用 PostgreSQL 認證，促銷不會自動將副本切換為 Microsoft Entra 認證。 副本保留 PostgreSQL 認證。 您需要在升級程序之前或之後，於升級後的複本上手動設定 Microsoft Entra 驗證。
- 高可用性（HA）：若升遷後需啟用 HA ，必須在角色反轉後於新升升的主伺服器上設定。
考慮事項
提升期間的伺服器狀態
在計畫性與強制升遷情境中，伺服器（主伺服器與副本伺服器）必須處於 準備狀態 。 如果伺服器狀態不是 「準備好 」（例如 更新 或 重新啟動），促銷通常無法順利進行。 不過，發生區域性中斷時，發生一個例外狀況。
在區域性中斷期間，無論主伺服器狀態如何，都可以實施強制升級方式。 這種方法可讓您快速採取行動，以回應潛在的區域災害，略過對伺服器可用性的正常檢查。
如果之前主要伺服器在提升複本期間發生錯誤而無法復原，則唯一的選項就是刪除先前的主要伺服器並重新建立複本伺服器。
在非配對的區域中提升期間的多個複本可見度
當你處理多個副本且主區域缺乏 配對區域時，就需要特別注意。 如果區域性中斷影響到主要伺服器，新升級的複本不會自動辨識任何其他複本。 雖然您仍可將應用程式導向已升級的複本繼續運作，但未識別的複本在停機期間仍會中斷連線。 這些額外的複製體只有在原始主要區域恢復後才會重新結合並恢復其角色。
升級時的還原時間點
無論是在計畫性提升還是強制提升的情境中，都必須能夠取得最新的自動備份，以確保時間點還原（PITR）作業能成功執行。 有一個已知問題：在執行容錯移轉和容錯回復作業後，PITR 作業可能會遇到下列錯誤。 此問題已排程在即將發行的版本中解決。 為確保 PITR 操作順利至最新時間，請在升遷操作後等待自動備份完成。
Error : Point-in-time-restore of server to the period when the siteswap operation for this server was in-progress or when the server was replica is not allowed.
常見問題
如果我的主要伺服器已啟用高可用性 (HA)，我可以提升複本嗎？
可以，無論您的主要伺服器是否啟用 HA，您都可以提升其讀取複本。 將讀取複本提升至主要伺服器的功能與主要伺服器的 HA 組態無關。
如果我有一個已啟用 HA 的主要伺服器和一個讀取複本，然後將該複本升級為主要伺服器，再切換回原始主要伺服器，該伺服器仍處於 HA 狀態嗎？
不，升級程序會停用 HA，因為適用於 PostgreSQL 的 Azure 資料庫不支援已啟用 HA 的讀取複本。 將讀取複本升級為主要執行個體，表示原本的主要執行個體會將其角色變更為複本。 如果要切換回來，則必須在原始主要伺服器上啟用 HA。