共用方式為


提升適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器中的讀取複本

適用範圍:適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器

「提升」是指命令複本結束其複本模式,並轉換為完整讀寫作業的程序。

重要

提升作業不是自動化的。 當主要伺服器發生故障時,系統不會獨立切換到讀取複本。 提升作業一律需要使用者的操作。

複本的提升可以透過兩種不同的方式完成:

提升至主要伺服器

此動作會將複本提升為主要伺服器的角色。 在此程序中,目前的主要伺服器會降級為複本角色,兩者的角色會交換。 若要成功提升,必須為目前主要端點設定一個虛擬端點作為寫入器端點,以及設定要升級的複本作為讀取器端點。 只有在讀取器端點設定中包含目標複本時,提升才會成功。

下圖說明了提升前的伺服器組態,以及提升作業成功完成之後的最終狀態。

顯示提升至主要伺服器作業的圖表。

提升至獨立伺服器並從複寫中移除

當您選擇此選項時,複本會提升為獨立伺服器,並從複寫程序中移除。 因此,主要伺服器和提升的伺服器都會作為兩部獨立的讀寫伺服器運作。 請注意,雖然可以設定虛擬端點,但這並不是此作業的必要項目。 即使讀取器端點先前指向該伺服器,新提升的伺服器已不再是任何現有虛擬端點的一部分。 因此,如果應用程式應該連線到新提升的複本,就必須更新應用程式的連接字串,以指向新提升的複本。

此圖顯示伺服器在提升之前的設定,以及在成功成為獨立伺服器之後的設定。

此圖顯示提升至獨立伺服器並從複寫作業中移除。

重要

提升至獨立伺服器並從複寫中移除動作,與先前的提升功能回溯相容。

重要

伺服器對稱性:若要使用「提升至主要伺服器」作業成功完成提升,主要伺服器和複本伺服器都必須有相同的層級和儲存體大小。 例如,如果主要伺服器有 2vCore 且複本伺服器有 4vCore,則唯一可行的選項是使用「提升至獨立伺服器並從複寫中移除」動作。 此外,他們的用於配置共用記憶體的伺服器參數值必須相同。

對於這兩種提升方法,還可以考慮其他選項:

  • 已規劃:此選項可確保在提升之前同步處理資料。 它在接受客戶端連線之前會套用所有擱置的記錄,以確保資料一致性。

  • 強制:此選項可以在發生區域中斷等案例中實現快速復原。 一旦伺服器處理達成最接近一致狀態所需的 WAL 檔案,伺服器就會開始運作,而無需等候同步處理主要伺服器中的所有資料。 如果您使用此選項來提升複本,則取消與主要伺服器之間的連結時,延隔時間會指出遺失多少資料。

重要

「強制」提升選項專為解決區域性中斷問題,在這種情況下,它會跳過所有檢查 (包括伺服器對稱性需求) 並繼續提升。 這是因為它會優先考慮伺服器的即時可用性來處理災害案例。 但是,如果不符合檔案中指定的讀取複本需求 (特別是伺服器對稱性需求),則不允許在區域關閉案例之外使用「強制」選項,因為這可能會導致複寫中斷等問題。

了解如何將複本提升到主要伺服器提升至獨立伺服器並從複寫中移除

設定管理

讀取複本在控制平面組態中會被視為單獨的伺服器。 此方法為讀取調整案例提供了彈性。 但是,在使用複本進行災害復原時,使用者必須確保設定符合預期。

提升作業不會延續特定的組態和參數。 以下是一些值得注意的項目:

  • 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,因為我們不支援啟用 HA 的讀取複本。 將讀取複本提升為主要伺服器表示原始主要伺服器正在將其角色變更為複本。 如果要切換回來,則必須在原始主要伺服器上啟用 HA。