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

  • 發行項

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

讀取複本功能可讓您將資料從適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體複寫到唯讀伺服器。 複本會使用 PostgreSQL 引擎的原生實體複寫技術以非同步方式更新。 使用複寫位置的串流複寫是預設作業模式。 必要時，系統會使用檔案型記錄傳送來跟上進度。 您可以從主要伺服器複寫到最多五個複本。

複本是新伺服器，管理方式類似於一般適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體。 針對每個讀取複本，系統每月會針對在虛擬核心中所佈建的計算量，以及在儲存體中所佈建的容量 (以 GB 為單位) 向您收費。

了解如何建立及管理複本。

何時應該使用讀取複本

讀取複本功能可針對需大量讀取的工作負載，協助改善效能及調整能力。 讀取工作負載可隔離至複本，而寫入工作負載可以導向到主要伺服器。 讀取複本也可以部署在不同的區域，而且可以在需要災害復原時升級為讀寫伺服器。

典型的案例是讓 BI 和分析工作負載使用讀取複本作為報表的資料來源。

由於複本是唯讀狀態，因此不會直接降低主要伺服器上的寫入容量負擔。

考量

讀取複本主要是針對卸載查詢很有用的案例所設計，而且可管理稍微延遲的情況。 它們經過最佳化，可為大部分工作負載提供來自主要工作負載的近乎即時更新，使其成為大量讀取案例的絕佳解決方案。 不過，請務必注意，它們不適用於需要最新資料正確性的同步複寫案例。 雖然複本上的資料最終會與主要複本保持一致，但可能會有延遲，通常範圍從幾秒到數分鐘，而在某些繁重的工作負載或高延遲案例中，此延遲可能會延長到數小時。 一般而言，與主要伺服器相同的區域中讀取複本的延隔時間比異地複寫的複本少，因為後者通常要處理地理距離造成的延遲。 如需異地複寫效能影響的詳細資訊，請參閱 異地複寫 一文。 複本上的資料，最終仍會與主要伺服器上的資料保持一致。 請針對可接受此延遲的工作負載使用此功能。

注意

對於大部分的工作負載，讀取複本會從主要伺服器提供近乎即時的更新。 不過，持續大量寫入密集主要工作負載時，複寫延遲時間可能會繼續增加，且可能無法跟上主要伺服器。 這也可能會增加主要伺服器的儲存體使用量，因為預寫記錄檔 (WAL) 檔案會在複本收到這些檔案後才刪除。 如果此情況持續發生，在需要大量寫入的工作負載完成後，刪除並重新建立讀取複本，是讓複本回到延隔時間良好狀態的選項。 非同步讀取複本不適合這類大量寫入工作負載。 評估應用程式讀取複本時，請監視複本上的延隔時間，以取得涵蓋其尖峰與非尖峰時間的完整應用程式工作負載週期，以便存取工作負載週期的各個時間點可能的延隔時間和預期的 RTO/RPO。

建立複本

適用於 PostgreSQL 的 Azure 資料庫彈性伺服器主要伺服器可以部署在支援服務的任何區域中。 您可以將主要伺服器複本建立在適用於 PostgreSQL 的 Azure 資料庫彈性伺服器可供使用的相同區域內或跨不同全域 Azure 區域中。 建立複本的功能現在會延伸到一些特殊的 Azure 區域。 如需可建立複本的特殊區域清單，請參閱 異地複寫 一文。

當您開始建立複本的工作流程時，系統會建立空白的適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體。 新的伺服器會填入主要伺服器上的資料。 針對在相同區域中建立複本，會使用快照集方法。 因此，建立時間與資料的大小無關。 會使用主要執行個體的基底備份建立異地複本，然後透過網路傳輸，因此建立的所需時間會視主要執行個體大小而定，從數分鐘到數小時不等。

只有在符合兩個條件時，才會將複本視為成功建立：必須將主要執行個體的整個備份複製到複本，而變更檔必須同步處理，且不超過 1 GB 的延隔時間。

若要成功建立作業，請避免在高異動負載期間建立複本。 例如，您應該避免在從其他來源移轉至適用於 PostgreSQL 的 Azure 資料庫彈性伺服器或在繁重大量載入作業期間建立複本。 如果您要移轉資料或載入大量資料，最好先完成這項工作。 完成之後，您就可以開始設定複本。 移轉或大量載入作業完成後，請檢查變更檔大小是否已回到其正常大小。 一般而言，變更檔大小應該接近執行個體在 max_wal_size 伺服器參數中定義的值。 您可以使用 [已使用的變更檔儲存體] 計量來追蹤變更檔儲存體使用量，以深入解析變更檔所使用的儲存體數量。 藉由監視此計量，您可以確定變更檔大小在預期的範圍內，而且可能會啟動複本建立流程。

重要

一般用途和記憶體最佳化伺服器計算層目前支援讀取複本。 不支援高載伺服器計算層。

重要

執行複本建立、刪除和升級作業時，主要伺服器會進入更新狀態。 在此期間，伺服器管理作業，例如修改伺服器參數、變更高可用性選項，或新增或移除防火牆將無法使用。 請務必注意，更新狀態只會影響伺服器管理作業，而且不會影響資料平面作業。 這表示您的資料庫伺服器會保持完整運作並能夠接受連線，以及提供讀取和寫入流量。

了解如何在 Azure 入口網站中建立讀取複本。

設定管理

為適用於 PostgreSQL 的 Azure 資料庫彈性伺服器設定讀取複本時，請務必瞭解可以調整的伺服器設定、繼承自主要伺服器的設定，以及任何相關限制。

繼承的組態

建立讀取複本時，它會從主要伺服器繼承特定的伺服器組態。 這些組態可以在複本建立期間或設定之後變更。 不過，特定設定，例如異地備份，不會複寫到讀取複本。

在複本建立期間的組態

  • 階層，儲存大小：針對「升階至主要伺服器」作業，它必須與主要伺服器相同。 針對「升級至獨立伺服器並從複寫中移除」作業，它可以是相同或高於主要伺服器。
  • 效能層級 (IOPS)：可調整。
  • 資料加密：可調整，包括從服務管理的密鑰移至客戶自控金鑰。

建立後的組態

  • 防火牆規則：可以新增、刪除或修改。
  • 階層，儲存大小：針對「升階至主要伺服器」作業，它必須與主要伺服器相同。 針對「升級至獨立伺服器並從複寫中移除」作業，它可以是相同或高於主要伺服器。
  • 效能層級 (IOPS)：可調整。
  • 驗證方法：可調整的選項包括從 PostgreSQL 驗證切換至 Microsoft Entra。
  • 伺服器參數：大部分都是可調整的。 不過，影響共用記憶體大小的參數應該與主要伺服器一致，特別是針對潛在的「升階至主要伺服器」案例。 針對「升級至獨立伺服器並從複寫中移除」作業，這些參數應該是相同或高於主要伺服器者。
  • 維護排程：可調整。

讀取複本上不支援的功能

某些功能僅限於主要伺服器，且無法在讀取複本上設定。 包括：

  • 備份，包括異地備份。
  • 高可用性 (HA)

如果您的來源適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體使用客戶自控金鑰加密，請參閱 文件 以了解其他考量。

連線到複本

當您建立複本時，其會繼承主要伺服器的防火牆規則或虛擬網路服務端點。 這些規則可能會在建立複本期間以及之後的任何時間點變更。

複本會從主要伺服器繼承系統管理員帳戶。 系統會將主要伺服器上的所有使用者帳戶，複寫至讀取複本。 您只能使用主要伺服器上可用的使用者帳戶，以連線到讀取複本。

有兩種方法可以連線到複本：

  • 直接連線至複本執行個體：您可以使用複本的主機名稱和有效的使用者帳戶來連線到複本，就像在一般適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體上一樣。 若伺服器名稱為 myreplica，且系統管理員使用者名稱為 myadmin，則您可以使用 psql 來連線到複本：
psql -h myreplica.postgres.database.azure.com -U myadmin postgres

在出現提示時，請輸入使用者帳戶的密碼。

此外，為了簡化連線流程，Azure 入口網站提供現成可用的連接字串。 您可以在 [連線] 頁面中找到這些項目。 它們同時包含為 bash 控制台量身打造的 libpq 變數和連接字串。

  • 透過虛擬端點：使用虛擬端點有替代的連線方法，如 虛擬端點 一文所述。 藉由使用虛擬端點，您可以將唯讀端點設定為一致地指向複本，而不論哪個伺服器目前保留複本角色。

監視複寫

適用於 PostgreSQL 的 Azure 資料庫彈性伺服器中的讀取複本功能依賴複寫位置機制。 複寫位置的主要優點是，它們會自動調整所有複本伺服器所需的變更檔 (WAL 區段) 數目。 這有助於防止複本不同步，因為它避免在傳送至複本之前刪除主要伺服器上的 WAL 區段。 此方法的缺點是，如果複寫位置長時間維持非使用中狀態，則在主要伺服器上有空間不足的風險。 在這種情況下，主要伺服器會累積 WAL 檔案，導致儲存體使用量的累加成長。 為了避免因為磁碟滿載的情形而發生錯誤，當儲存體使用量達到 95% 或可用容量小於 5 GiB 時，伺服器會自動切換為唯讀模式。
因此，監視複寫延遲和複寫位置狀態對於讀取複本至關重要。

建議您設定儲存體使用或儲存體百分比的警示規則，以及在複寫延遲超過特定閾值時，讓您可以主動採取行動、增加儲存大小，以及刪除延遲讀取複本。 例如，如果儲存體百分比超過 80% 使用量，而且複本延遲高於 5 分鐘，您可以設定警示。 [已使用的變更檔儲存體] 計量會顯示 WAL 檔案累積是儲存體使用過度的主要原因。

適用於 PostgreSQL 的 Azure 資料庫提供用於監視複寫的兩個計量。 這兩個計量是 [最大實體複寫延隔] 和 [讀取複本延隔]。 若要了解如何檢視這些計量，請參閱讀取複本操作說明文章的監視複本一節。

[最大實體複寫延隔] 計量顯示主要伺服器和最大延隔複本之間的延隔。 此計量僅適用且於主要伺服器上提供，而且只有在至少有一個讀取複本連線到主要伺服器時才可用。 當複本正在趕上主要複本、建立複本期間或複寫變成非使用中時，也會顯示延隔資訊。

[讀取複本延隔] 計量會顯示自最後一次重新執行異動已經過的時間。 例如，如果您的主要伺服器上沒有發生任何異動，且前次異動是在 5 秒前重新執行，則讀取複本延隔會顯示 5 秒的延遲。 此計量僅適用且於複本上提供。

請設定警示，以在複本延隔時間接近您工作負載無法接受的值時通知您。

如需其他見解，請直接查詢主要伺服器以取得所有複本的複寫延隔時間。

注意

如果主要伺服器或讀取複本重新啟動，其重新啟動完畢並跟上進度所花費的時間將會反映在 [複本延隔時間] 計量中。

複寫狀態

若要監視複寫和升級作業的進度和狀態，請參閱 Azure 入口網站中的 複寫狀態 資料行。 此資料行位於複寫頁面中，並顯示各種狀態，以深入了解讀取複本的目前狀況及其主要複本的連結。 對於依賴 Azure Resource Manager API 的使用者，在叫用 GetReplica API 時，狀態會顯示為 replica 屬性包中的 ReplicationState。

下列為可能的值：

複寫狀態 說明 升階排序 讀取複本建立順序
重新設定 等候複本-主要連結的啟動。 例如，如果複本或其區域 (因災害等) 而無法使用，它可能會維持較長的時間。 1 N/A
提供 正在佈建讀取複本，且兩部伺服器之間的複寫尚未啟動。 在佈建完成之前，您無法連線到讀取複本。 N/A 1
更新中 在升級或讀取複本建立等觸發動作之後，正在準備伺服器設定。 2 2
Catchup 正在複本上套用WAL 檔案。 升級期間此階段的持續時間取決於選擇的資料同步選項 - 已規劃或強制。 3 3
作用中 狀況良好，表示讀取複本已成功連線到主要伺服器。 如果伺服器已停止，但先前已成功連線，會維持作用中狀態。 4 4
已中斷 狀況不良狀態，表示升級作業可能已失敗，或複本因某些原因而無法連線到主要複本。 請卸除複本並重新建立複本，以解決此問題。」 N/A N/A

了解如何監視複寫。

考量

本節將摘要說明有關讀取複本功能的考量。 適用下列考量。

  • Power 作業：Power 作業，包括啟動和停止動作，可以同時套用至主要和複本伺服器。 不過，若要保留系統完整性，應該遵循特定的順序。 停止讀取複本之前，請先確定主要伺服器已停止。 開始作業時，請先在複本伺服器上起始啟動動作，再啟動主要伺服器。
  • 如果伺服器有讀取複本，則應該在刪除主要伺服器之前先刪除讀取複本。
  • 適用於 PostgreSQL 的 Azure 資料庫中的就地主要版本升級需要移除伺服器上目前啟用的任何讀取複本。 一旦刪除複本，主要伺服器就可以升級為所需的主要版本。 升級完成後，您可以重新建立複本以繼續複寫流程。
  • 進階 SSD v2：自目前版本起，如果主伺服器使用進階 SSD v2 作為儲存體，則不支援建立讀取複本。
  • 重設系統管理員密碼：目前不支援重設複本伺服器上的系統管理員密碼。 此外，也不支援在相同的要求中更新管理員密碼以及升階複本作業。 如果您想這樣做，您必須先升階複本伺服器，然後個別更新新升階伺服器上的密碼。

新複本

讀取複本會建立為新的適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體。 現有伺服器無法設定為複本。 您無法建立另一個讀取複本的複本，也就是不支援串聯式複寫。

資源移動

使用者可以在與主要資源群組不同的資源群組中建立讀取複本。 不過，不支援在建立讀取複本之後，將它們移至另一個資源群組。 此外，不支援將複本移至不同的訂用帳戶，並將具有讀取複本的主要複本移至另一個資源群組或訂用帳戶。

儲存體自動成長

為適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體設定讀取複本時，請務必確保複本上的儲存體自動成長設定符合主要伺服器的設定。 儲存體自動成長功能可讓資料庫儲存體自動增加，以避免空間不足，這可能會導致資料庫中斷。 以下說明如何有效地管理儲存體自動成長設定：

  • 不論主要伺服器設定為何，您都可以在任何複本上啟用儲存體自動成長。
  • 如果在主要伺服器上啟用儲存體自動成長，也必須在複本上啟用它，以確保儲存體縮放行為的一致性。
  • 若要在主要複本上啟用儲存體自動成長，您必須先在複本上啟用它。 這項作業順序對於維護複寫完整性至關重要。
  • 相反地，如果您想要停用儲存體自動成長，請先在主要伺服器上停用它，以避免複寫複雜。

備份及還原

管理適用於 PostgreSQL 的 Azure 資料庫彈性伺服器執行個體的備份和還原時，請務必記住伺服器在不同升級案例中目前和先前的角色。 以下是一些要記住的重點：

升階至主要伺服器

  1. 不會從讀取複本擷取備份：備份永遠不會從讀取複本伺服器取得，不論其過去的角色為何。

  2. 保留過去的備份：如果伺服器曾經是主要伺服器，並在該期間進行備份，則會保留這些備份。 它們最多會保留到使用者定義的保留期間。

  3. 還原作業限制：即使已轉換至讀取複本的伺服器有過去的備份，還原作業也會受到限制。 您只能在伺服器已升級回主要角色時起始還原作業。

為了清楚起見，以下列表格說明這些重點：

伺服器角色 已擷取的備份 允許的還原
主要 Yes Yes
讀取複本 No No
將複本升階為主要複本 Yes Yes

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

雖然伺服器是讀取複本，但不會進行備份。 不過，一旦升級為獨立伺服器，升級的伺服器和主要伺服器都會建立備份，而且兩者都允許還原。

網路

讀取複本支援適用於 PostgreSQL 的 Azure 資料庫彈性伺服器所支援的所有網路選項。

重要

主要伺服器與讀取複本之間的雙向通訊對於適用於 PostgreSQL 的 Azure 資料庫彈性伺服器設定至關重要。 必須佈建在 Azure 虛擬網路子網路內的目的地埠 5432 上傳送和接收流量。

上述需求不僅有助於同步處理程序，還能確保升級機制正常運作，其中複本可能需要以反向順序進行通訊，就是從複本到主要複本，特別是在升級至主要作業期間。 此外，必須允許連線至儲存預先寫入記錄 (WAL)封存的 Azure 儲存體帳戶，才能維護資料持久性，並啟用有效率的復原程序。

如需如何為讀取複本設定私人存取 (虛擬網路整合) 的詳細資訊，並瞭解在私人網範圍內跨 Azure 區域和虛擬網路進行複寫的影響，請參閱 使用私人網路跨 Azure 區域和虛擬網路的複寫 頁面。

複寫位置問題風險降低

在罕見的情況下，複寫位置所造成的高延遲可能會導致主要伺服器上的儲存體使用量因為累積的 WAL 檔案而增加。 如果儲存體使用量達到 95%，或可用容量低於 5 GiB，伺服器會自動切換為唯讀模式，以防止磁碟滿載錯誤。

由於維護主要伺服器的健康情況和功能是優先順序，因此在這類邊緣情況下，可能會卸除複寫位置，以確保主要伺服器仍可運作讀取和寫入流量。 因此，複寫會切換至檔案型記錄傳送模式，這可能會導致較高的複寫延遲。

請務必密切監視儲存體使用量和複寫延隔時間，並在問題加劇前採取必要動作來降低潛在風險。

伺服器參數

建立讀取複本時，它會從主要伺服器繼承伺服器參數。 這是為了確保一致且可靠的起點。 不過，在建立讀取複本之後對主要伺服器上的伺服器參數所做的任何變更都不會自動複寫。 此行為提供個別微調讀取複本的優點，例如，在不修改主要伺服器參數的情況下，增強讀取密集型作業的效能。 雖然這提供彈性和自訂選項，但是當需要伺服器參數的統一性時，也需要謹慎和手動管理，以維持主要伺服器和其複本之間的一致性。

系統管理員可以變更讀取複本伺服器上的伺服器參數，並設定與主要伺服器上不同的值。 唯一的例外狀況是可能會影響複本復原的參數，如下列「縮放」一節所述：max_connections、max_prepared_transactions、max_locks_per_transaction、max_wal_senders、max_worker_processes。 為了確保讀取複本的復原順暢，而且不會遇到共用記憶體限制，這些特定參數應一律設定為等於或大於主要伺服器上設定的值。

調整

您可以隨意相應擴大和減少計算 (V 核心)，將服務層級從一般用途變更為記憶體最佳化 (或是相反)，並相應擴大儲存體，但請遵循下列注意事項。

針對計算調整：

  • 適用於 PostgreSQL 的 Azure 資料庫彈性伺服器需要複本上的數個參數大於或等於主要伺服器上的設定，以確保複本在復原期間不會耗盡共用記憶體。 受影響的參數包括：max_connections、max_prepared_transactions、max_locks_per_transaction、max_wal_senders、max_worker_processes。

  • 擴大：先擴大複本的計算，然後擴大主要伺服器。

  • 縮小：先縮小主要伺服器的計算，然後縮小複本。

  • 主要複本上的計算必須一律等於或小於最小複本上的計算。

針對儲存體縮放：

  • 擴大：先擴大複本的儲存體，然後再擴大主要複本。

  • 主要複本上的儲存大小必須一律等於或小於最小複本上的儲存大小。

相關內容