在適用於 PostgreSQL 的 Azure 資料庫單一伺服器中讀取複本

適用於：適用於 PostgreSQL 的 Azure 資料庫 - 單一伺服器

重要

適用於 PostgreSQL 的 Azure 資料庫 - 單一伺服器即將淘汰。 強烈建議您升級至 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器。 如需移轉至 適用於 PostgreSQL 的 Azure 資料庫 - 彈性伺服器的詳細資訊，請參閱單一伺服器 適用於 PostgreSQL 的 Azure 資料庫 發生什麼事？。

讀取複本功能可讓您將資料從適用於 PostgreSQL 的 Azure 資料庫伺服器複寫到唯讀伺服器。 複本會使用 PostgreSQL 引擎的原生實體複寫技術以非同步方式更新。 您可以從主要伺服器複寫到最多五個複本。

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

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

何時應該使用讀取複本

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

常見的案例是讓 BI 與分析工作負載使用讀取複本做為報告的資料來源。

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

考量

此功能適用於可接受延遲且用於卸載查詢的案例。 這不適用於預期複本資料為最新狀態的同步複寫案例。 主要伺服器和複本之間會有顯著的延遲情形。 視工作負載和主要伺服器與複本之間的延遲而定，這可能需要幾分鐘或甚至數小時的時間。 複本上的資料，最終仍會與主要伺服器上的資料保持一致。 請針對可接受此延遲的工作負載使用此功能。

注意

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

注意

針對設定最多 4TB 儲存體設定的複本伺服器，會執行自動備份。

跨區域複寫

您可以從主要伺服器在不同的區域中建立讀取複本。 跨區域複寫有助於災害復原規劃或讓資料更接近使用者之類的案例。

注意

基本層伺服器僅支援相同區域複寫。

您可以在任何適用於 PostgreSQL 的 Azure 資料庫區域中擁有主要伺服器。 主要伺服器可以在其配對區域或全球的複本區域中擁有複本。 下圖顯示根據您的主要區域而可供使用的複本區域。

全球的複本區域

無論您的主要伺服器位於何處，您都可以在下列任何區域中建立讀取複本。 以下是通用複本區域：

澳大利亞東部、澳大利亞東南部、巴西南部、加拿大中部、加拿大東部、美國中部、東亞、美國東部、美國東部 2、日本東部、日本西部、南韓中部、南韓南部、美國中北部、北歐、美國中南部、東南亞、英國南部、英國西部、西歐、美國西部、美國西部 2、美國中西部。

配對的區域

除了全球的複本區域外，您還可以在主要伺服器的 Azure 配對區域中，建立讀取複本。 如果您不知道所在區域的配對，則可以從 Azure 配對區域一文深入了解。

如果您使用跨區域複本來規劃災害復原，建議您在配對區域中建立複本，而不要在其他區域之一建立。 配對區域可避免同時更新，並排定實體隔離和資料落地的優先順序。

其中有一些限制需要考慮：

• 單向配對：某些 Azure 區域只會單向配對。 這些區域包括印度西部、巴西南部。 這表示位於印度西部的主要伺服器可以在印度南部建立複本。 但位於印度南部的主要伺服器無法在印度西部建立複本。 其原因是印度西部的次要區域是印度南部，但印度南部的次要區域卻不是印度西部。

建立複本

當您開始建立複本的工作流程時，系統會建立空白的「適用於 PostgreSQL 的 Azure 資料庫」伺服器。 新的伺服器會有主要伺服器上的資料。 建立時間取決於主要伺服器上的資料量，以及距離上次執行每週完整備份所經過的時間。 時間的範圍可能介於數分鐘到數小時。

每個複本都會啟用儲存體自動成長。 自動成長功能可讓複本跟上複寫至其中的資料，並防止因儲存空間不足的錯誤而造成複寫中斷。

讀取複本功能會使用 PostgreSQL 的實體複寫，而非邏輯複寫。 使用複寫位置的串流複寫是預設作業模式。 必要時，系統會使用記錄傳送來跟上進度。

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

如果您的來源 PostgreSQL 伺服器使用客戶自控金鑰來加密，請參閱此文件以取得其他考量。

連線到複本

當您建立複本時，其不會繼承主要伺服器的防火牆規則或 VNet 服務端點。 您必須個別針對複本設定這些規則。

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

您可以使用複本的主機名稱和有效的使用者帳戶來連線到該複本，如同連線到一般適用於 PostgreSQL 的 Azure 資料庫伺服器一樣。 若伺服器名稱為 my replica，且統管理員使用者名稱為 myadmin，則您可以使用 psql 來連線到複本：

psql -h myreplica.postgres.database.azure.com -U myadmin@myreplica -d postgres

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

監視複寫

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

[複本之間的最大延隔時間] 計量會顯示主要伺服器和最大延隔複本之間的延隔 (位元組)。 此計量僅適用於主要伺服器，而且只有在至少一個讀取複本連線到主要伺服器且主要伺服器處於串流複寫模式時，才能使用。 當複本在檔案傳送複寫模式中使用主要伺服器的封存記錄來趕上主要伺服器時，延遲資訊不會顯示詳細資料。

[複本延隔時間] 計量會顯示自最後一次重新執行交易已經過的時間。 如果主要伺服器上沒有發生交易，計量會反映此時間延隔。 此計量僅適用於複本伺服器。 複本延隔時間會從 pg_stat_wal_receiver 檢視中計算：

SELECT EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp());

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

如需其他見解，請直接查詢主要伺服器以取得所有複本的複本延隔時間 (以位元組為單位)。

注意

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

停止複寫/升階複本

您可以隨時停止主要伺服器與複本之間的複寫。 停止動作會導致複本重新啟動，並將複本升階為獨立且可讀寫的伺服器。 獨立伺服器中的資料是複寫停止時，複本伺服器上的可用資料。 主要伺服器上的任何後續更新都不會傳播至複本。 不過，複本伺服器可能已有尚未套用的累積記錄。 在重新啟動過程中，複本會先套用所有擱置的記錄，再接受用戶端連線。

注意

目前不支援在複本伺服器上重設管理員密碼。 此外，也不支援在相同的要求中更新管理員密碼以及升階複本作業。 如果您想要這樣做，您必須先升階複本伺服器，然後個別更新新升階伺服器上的密碼。

考量

• 在您停止讀取複本上的複寫之前，請檢查複寫延遲，以確定該複本上已經有您所需要的所有資料。
• 由於讀取複本必須先套用所有擱置的記錄，才能成為獨立伺服器，因此當停止複寫發生時，RTO 對於大量寫入工作負載而言可能較高，因為複本可能會有顯著的延遲。 規劃升階複本時，請注意這一點。
• 升階的複本伺服器無法再次設定為複本伺服器。
• 如果您將複本升階為主要伺服器，則無法建立複寫回到舊的主要伺服器。 如果您想要回到舊的主要區域，您可以使用新的名稱建立新的複本伺服器 (或) 刪除舊的主要伺服器，並使用舊的主要伺服器名稱建立複本。
• 如果您有多個讀取複本，而且如果您將其中一個複本升階為主要伺服器，其他複本伺服器仍會連線到舊的主要伺服器。 您可能必須從新的升階伺服器重新建立複本。

當您停止複寫時，複本會失去與其先前主要伺服器和其他複本的所有連結。

了解如何停止複寫至複本。

容錯移轉至複本

如果主要伺服器失敗，不會自動容錯移轉至讀取複本。

因為複寫是非同步，所以主要伺服器與複本之間可能會有相當長的延遲。 延隔時間量會受到一些因素影響，例如在主要伺服器上執行的工作負載類型，以及主要與複本伺服器之間的延遲。 在標稱寫入工作負載的一般情況下，複本延隔時間預期會在幾秒鐘到幾分鐘之間。 不過，如果主要伺服器執行非常大量的寫入密集型工作負載，且複本無法快速趕上，延隔時間可能會更高。 您可以使用 [複本延隔時間] 計量來追蹤每個複本的複寫延隔時間。 此計量會顯示自複本最後一次重新執行交易已經過的時間。 建議您藉由觀察複本在一段時間內的延遲情形，來識別平均延隔時間。 您可以設定複本延隔時間的警示，當延遲情況超出預期範圍時，便會通知您採取行動。

提示

如果您容錯移轉至複本，則當您從主要伺服器取消複本連結時，延遲會指出遺失的資料數量。

當您決定要容錯移轉至複本之後，

1. 停止複寫至複本
   若要讓複本伺服器成為獨立伺服器，而且能夠接受寫入，必須執行此步驟。 在此處理序中，複本伺服器會重新啟動並且與主要伺服器取消連結。 一旦您起始停止複寫，後端程序通常需要幾分鐘的時間，才能套用尚未套用的任何剩餘記錄，並將資料庫開啟為可讀寫的伺服器。 請參閱本文的停止複寫章節，以了解此動作的含意。

2. 將應用程式指向 (先前) 複本
   每部伺服器都具有唯一的連接字串。 更新您的應用程式連接字串，以指向 (先前) 複本而不是主要伺服器。

在應用程式順利處理讀取和寫入作業之後，您便完成容錯移轉。 應用程式的停機時間長度，是取決於您偵測到問題並完成上述步驟 1 和 2 的時間點。

災害復原

當發生重大災害事件，例如可用性區域層級或區域失敗時，您可以藉由升階讀取複本來執行災害復原作業。 您可以從 UI 入口網站瀏覽至讀取複本伺服器。 然後選取 [複寫] 索引標籤，您可以停止複本，將其升階為獨立的伺服器。 或者，您可以使用 Azure CLI 來停止和升階複本伺服器。

考量

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

必要條件

讀取複本和邏輯解碼都相依於 Postgres 預寫記錄檔 (WAL) 來取得相關資訊。 這兩個功能需要來自 Postgres 的不同記錄層級。 邏輯解碼需要比讀取複本更高的記錄層級。

若要設定正確的記錄層級，請使用 Azure 複寫支援參數。 Azure 複寫支援有三個設定選項：

• 關閉：在 WAL 中放入最少資訊。 大多數適用於 PostgreSQL 的 Azure 資料庫伺服器上都無法使用此設定。
• 複本：比關閉更詳細。 這是讓讀取複本運作所需的最低記錄層級。 此設定是大多數伺服器上的預設值。
• 邏輯：比複本更詳細。 這是讓邏輯解碼運作的最低記錄層級。 讀取複本也能在此設定中運作。

新複本

讀取複本會建立為最新適用於 PostgreSQL 的 Azure 資料庫伺服器。 現有伺服器無法設定為複本。 您無法為另一個讀取複本建立複本。

複本設定

複本是使用與主要伺服器相同的計算和儲存體設定所建立。 建立複本之後，可以變更數個設定，包括儲存體和備份保留期間。

建立複本時或以後，複本不會從主要伺服器繼承防火牆規則、虛擬網路規則和參數設定。

調整大小

在一般用途和記憶體最佳化之間調整虛擬核心：

• PostgreSQL 要求次要伺服器上的 max_connections 設定大於或等於主要伺服器上的設定，否則次要伺服器將不會啟動。
• 在適用於 PostgreSQL 的 Azure 資料庫中，每個伺服器允許的最大連線都會固定到計算 SKU，因為連線會佔用記憶體。 您可以深入了解 max_connections 與計算 SKU 之間的對應。
• 擴大：先擴大複本的計算，然後擴大主要伺服器。 此順序可防止違反 max_connections 需求的錯誤。
• 縮小：先縮小主要伺服器的計算，然後縮小複本。 如果您嘗試調整低於主要伺服器的複本，就會發生錯誤，因為這違反 max_connections 需求。

調整儲存體：

• 所有複本都已啟用儲存體自動成長，以防止儲存體完整複本發生複寫問題。 您無法停用此設定。
• 您也可以手動擴大儲存體，如同您在任何其他伺服器上所做的一樣

基本層

基本層伺服器僅支援相同區域複寫。

max_prepared_transactions

PostgreSQL 要求讀取複本上的 max_prepared_transactions 參數值大於或等於主要伺服器的值，否則讀取複本將不會啟動。 如果您想要變更主要伺服器上的 max_prepared_transactions，請先在複本上加以變更。

已停止的複本

如果您停止主要伺服器和讀取複本之間的複寫，複本將會重新啟動以套用變更。 停止的複本會變成支接受讀取和寫入的獨立伺服器。 獨立伺服器無法再次設定為複本。

已刪除的主要和獨立伺服器

刪除主要伺服器時，其所有讀取複本都會變成獨立伺服器。 這些複本將會重新啟動以反映此變更。

下一步

• 了解如何在 Azure 入口網站中建立及管理讀取複本。
• 了解如何在 Azure CLI 和 REST API 中建立及管理讀取複本。