讀取複本功能允許你將資料從 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器複製到唯讀副本。 副本會使用 PostgreSQL 引擎的原生實體複寫技術進行 非同步 更新。 使用複寫位置的串流複寫是預設作業模式。 必要時，系統會使用檔案型記錄傳送來跟上進度。 您可以從主要伺服器複寫到最多五個複本。
複本是由您管理的新伺服器，與一般的 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器類似。 針對每個讀取複本，您需按月支付已佈建的 vCore 計算資源費用，以及以 GB 為單位的儲存體費用。
瞭解如何 建立讀取複本。
何時應該使用讀取複本
讀取複本功能有助於提升讀取密集型工作負載的效能與規模。 你可以將讀取工作負載隔離給副本，而寫入工作負載則直接導向主副本。 你也可以在不同區域部署讀取副本，並在需要災難復原時將其升級為讀寫伺服器。
典型的案例是讓 BI 和分析工作負載使用讀取複本作為報表的資料來源。
由於複本是唯讀狀態，因此不會直接降低主要伺服器上的寫入容量負擔。
考慮事項
讀取複本主要是針對卸載查詢很有用的案例所設計，而且可管理稍微延遲的情況。 它們經過最佳化，可在大多數工作負載下從主要節點提供近乎即時的更新，因此非常適合讀取密集型情境。 不過，請務必注意，它們不適用於需要最新資料正確性的同步複寫案例。 雖然複本上的資料最終會與主要複本保持一致，但可能會有延遲，通常範圍從幾秒到數分鐘，而在某些繁重的工作負載或高延遲案例中，此延遲可能會延長到數小時。 通常，與主要複本位於同一區域的讀取複本，其延遲通常比異地複寫複本更低，因為後者往往必須處理由地理距離所造成的延遲。 如需異地複寫效能影響的詳細資訊，請參閱 異地複寫 一文。 複本上的資料，最終仍會與主要伺服器上的資料保持一致。 請針對可接受此延遲的工作負載使用此功能。
備註
對於大部分的工作負載，讀取複本會從主要伺服器提供近乎即時的更新。 不過，持續大量寫入密集主要工作負載時，複寫延遲時間可能會繼續成長，且可能無法跟上主要工作負載。 這種情況也可能增加主記憶體的儲存空間，因為 WAL 檔案只會在副本收到後才會被刪除。 如果此情況持續發生，在需要大量寫入的工作負載完成後，刪除並重新建立讀取複本，即可將複本回復至良好的延遲狀態。 非同步讀取複本不適合處理這麼重的寫入工作負載。 評估應用程式讀取複本時，請監視複本上的延隔時間，以取得涵蓋其尖峰與非尖峰時間的完整應用程式工作負載週期，以便存取工作負載週期的各個時間點可能的延隔時間和預期的 RTO/RPO。
建立複本
你可以在任何支援該服務的區域部署 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器的主要伺服器。 你可以在同一區域內建立主伺服器的複製品，或跨跨不同全球 Azure 區域，這些區域有 適用於 PostgreSQL 的 Azure 資料庫 可用。 你也可以在某些 Azure 區域的主權雲中建立副本。 關於可以建立複製品的主權雲端區域列表，請參閱 Geo-replica 條目。
當你開始建立副本工作流程時，這個流程會建立一個空白的 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器。 新的伺服器會填入主要伺服器上的資料。 在相同區域建立副本時，流程採用快照（snapshot）方法。 因此，建立時間與資料的大小無關。 地理複本是利用主備份的基礎備份建立，然後透過網路傳輸。 因此，製作時間可能從幾分鐘到數小時不等，視主要尺寸而定。
只有當符合兩個條件時，複本才被視為成功建立：主備份的全部複製到副本，且交易日誌同步延遲不超過1 GB。
若要成功建立作業，請避免在高異動負載期間建立複本。 例如，從其他來源遷移到 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器或大量批量載入作業時，避免建立副本。 如果你正在遷移資料或載入大量資料，請先完成這項任務。 完成之後，您就可以開始設定複本。 遷移或批量載入操作結束後，檢查交易日誌大小是否回復正常大小。 通常，交易日誌大小應該接近你伺服器參數中定義的 max_wal_size 值。 你可以透過「 交易日誌儲存已使用 」指標追蹤交易日誌儲存空間，該指標能提供交易日誌所佔容量的洞見。 透過監控此指標，您可以確保交易日誌大小在預期範圍內，並能啟動副本建立流程。
這很重要
目前讀取複本支援一般用途和記憶體最佳化伺服器計算層。 不支援高載伺服器計算層。
這很重要
當你執行複製品的建立、刪除和升遷操作時，主伺服器會進入 更新狀態。 在此期間，伺服器管理操作如參數修改、變更高可用性選項，或新增或移除防火牆都無法使用。 更新狀態只影響伺服器管理操作，不影響 資料平面 操作。 此條件表示您的資料庫伺服器保持完整功能，能接受連線，並能處理讀寫流量。
瞭解如何 建立讀取複本。
組態管理
當你為 適用於 PostgreSQL 的 Azure 資料庫 靈活伺服器設定讀副本時，你需要了解可以調整哪些伺服器配置、副本繼承主伺服器的哪些設定，以及相關的限制。
繼承的組態
當你建立讀取副本時，它會繼承主伺服器的特定伺服器設定。 你可以在建立副本時或設定副本後更改這些設定。 不過，讀取副本不會繼承主伺服器的特定設定，例如地理備份。
在複本建立期間的組態
- 層級、儲存容量：為了升級 為主要伺服器 ，層級與儲存容量必須與主伺服器相符。 對於升級為獨立伺服器並移出複寫作業，層級和儲存體大小可以與主伺服器相同或更高。
- 效能層級 (IOPS)：可調整。
- 資料加密：可調整，包括從服務管理金鑰轉換為客戶管理金鑰。
創建後的配置
- 防火牆規則：你可以新增、刪除或修改規則。
- 層級、儲存容量：為了升級 為主要伺服器 ，層級與儲存容量必須與主伺服器相符。 針對升級為獨立伺服器並從複寫中移除作業，層級和儲存體大小可以與主要伺服器相同或更大。
- 效能層級 (IOPS)：可調整。
- Authentication Method：可調整，選項包括從 PostgreSQL 認證切換為 Microsoft Entra。
- 參數：大多數參數可調整。 然而， 影響共享記憶體大小 的部分應與主伺服器保持一致，特別是針對潛在的 升級至主伺服器 情境。 對於 升級為獨立伺服器並從複寫中移除 作業，這些參數應與主要伺服器上的參數相同或更高。
- 維護排程：可調整。
讀取複本上不支援的功能
主要伺服器支援某些你無法在讀取副本上設定的功能。 這些功能包括：
- 備份，包括異地備份。
- 高可用性（HA）。
如果您的來源 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器使用客戶管理的金鑰加密，請參閱文件以了解其他注意事項。
建立串聯讀取複本
連鎖式讀取複本可協助分散讀取工作負載，減少主伺服器上的負擔。 在不同區域部署讀取複本（跨區域讀取複本）可協助將讀取流量分散到不同地理位置的使用者。 你可以在 適用於 PostgreSQL 的 Azure 資料庫 伺服器上新增階層式讀取副本。 此功能允許你在現有讀取副本之上建立新的讀取副本，而現有的讀取副本則作為下一層的來源。
第一層讀取複本會以異步方式從主伺服器複寫數據。 接著你可以利用第一層副本作為來源，建立第二層級的讀取副本，形成兩層複製階層。 此架構提升可擴展性，支援最多 30 台讀取副本伺服器，主伺服器最多可容納五個讀取副本，且每個副本支援五個額外副本。 若要將串接讀取副本加入 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器，請選擇現有的讀取副本（從主伺服器建立），前往複寫標籤，選擇建立副本。
舉例來說，你的主伺服器最多可以有五個讀取副本（等級 1）。 其中一個，例如 read-replica-1，作為另一個複本 read-replica-2 的來源，而該複本成為（第 2 層）的一部分。
重要考慮
- 每個來源讀取複本最多可建立五個讀取複本，並支援兩層複寫。
- 切換操作支援中間讀取副本（原始碼）及串接讀取副本。
- 升級到主要作業不支援含有串接讀取複本的中間讀取複本。
- 虛擬端點不支援層疊副本。
- 使用 PostgreSQL 14 版及更新版本的中繼複本支援階層式讀取複本。
連線到複本
當你建立副本時，它不會繼承主伺服器的防火牆規則或虛擬網路服務端點。 你可以在複製品建立時設定這些規則，之後再更改。
複本會從主要伺服器繼承系統管理員帳戶。 系統會將主要伺服器上的所有使用者帳戶，複寫至讀取複本。 您只能使用主要伺服器上可用的使用者帳戶，以連線到讀取複本。
你可以用兩種方法連接到複本：
-
直接連接到副本：你可以用副本的主機名稱和有效的使用者帳號連接副本，就像一般 適用於 PostgreSQL 的 Azure 資料庫 彈性伺服器一樣。 若伺服器名稱為 myreplica，且系統管理員使用者名稱為 myadmin，則您可以使用
psql來連線到複本：
psql -h myreplica.postgres.database.azure.com -U myadmin postgres
在出現提示時，請輸入使用者帳戶的密碼。
為了讓連線流程更簡單，Azure 入口網站提供了現成可用的連線字串。 你可以在 Connect 頁面找到這些連接字串。 它們包含 libpq 變數和專為 Bash 控制台量身打造的連接串。
- 透過虛擬端點：另一種連接方式使用虛擬端點。 欲了解更多資訊，請參閱 虛擬端點。 透過虛擬端點，你可以將唯讀端點設定為一律指向複本，無論目前由哪一部伺服器擔任複本角色。
監視複寫
適用於 PostgreSQL 的 Azure 資料庫 中的讀取複本功能依賴於複製槽機制。 複寫位置的主要優點是，它們會自動調整所有複本伺服器所需的變更檔 (WAL 區段) 數目。 此調整有助於防止複本失去同步，因為它可避免在複本收到 WAL 區段之前，就先在主節點上刪除這些 WAL 區段。 此方法的缺點是，如果複寫位置長時間維持非作用中狀態，主要伺服器就有空間耗盡的風險。 在這種情況下，主記憶體會累積 WAL 檔案，導致儲存空間使用量逐漸增加。 當儲存空間使用量達到 95% 或可用容量低於 5 GiB，伺服器會自動切換為唯讀模式，以避免磁碟滿溢時的錯誤。
因此，監視複寫延遲和複寫位置狀態對於讀取複本至關重要。
針對儲存空間使用量或儲存百分比設定警示規則，以及當複製延遲超過特定閾值時，這樣你才能主動採取行動，增加儲存空間並刪除延遲的讀取副本。 例如，如果儲存體百分比超過 80% 使用量，而且複本延遲高於 5 分鐘，您可以設定警示。 交易記錄儲存體使用量指標可顯示 WAL 檔案的累積是否是儲存體使用量過高的主要原因。
監視指標
適用於 PostgreSQL 的 Azure 資料庫 服務提供以下監控複寫的指標。
您可以將增強的計量用於監控和警示讀取複本。
啟用增強型計量
- 大部分的新計量依預設是停用的。 然而，仍有幾個例外狀況，且依預設會啟用。 下表最右邊的欄指出每個計量是否會依預設啟用。
- 若要啟用預設為停用的這些指標，請將參數
metrics.collector_database_activity設為ON。 此參數是動態，不需要執行個體重新啟動。
邏輯複寫
| 顯示名稱 | 計量識別碼 | 單位 | Description | 尺寸 | 預設為啟用 |
|---|---|---|---|---|---|
| 邏輯複寫延遲上限 | logical_replication_delay_in_bytes |
Bytes | 所有邏輯複寫位置的延遲上限。 | 不適用 | Yes |
重複
| 顯示名稱 | 計量識別碼 | 單位 | Description | 尺寸 | 預設為啟用 |
|---|---|---|---|---|---|
| 實體複寫延遲上限 | physical_replication_delay_in_bytes |
Bytes | 所有非同步實體複寫位置的延遲上限。 | 不適用 | Yes |
| 讀取複本延遲 | physical_replication_delay_in_seconds |
秒 | 讀取副本延遲時間（秒） | 不適用 | Yes |
若要深入了解，請參閱讀取複本操作說明文章。
[最大實體複寫延隔] 計量顯示主要伺服器和最大延隔複本之間的延隔。 此指標僅適用於主伺服器，且僅在至少一個讀取副本連接到主伺服器時可用。 當複本正在趕上主要複本、建立複本期間或複寫變成非使用中時，也會顯示延隔資訊。
[讀取複本延隔] 計量會顯示自最後一次重新執行異動已經過的時間。 例如，如果您的主要伺服器上沒有任何交易進行，且最後一筆交易已在 5 秒前重新執行，讀取複本延遲會顯示延遲為 5 秒。 此計量僅適用且於複本上提供。
請設定警示，以在複本延隔時間接近您工作負載無法接受的值時通知您。
如需其他見解，請直接查詢主要伺服器以取得所有複本的複寫延隔時間。
備註
如果主要伺服器或讀取複本重新啟動，其重新啟動完畢並跟上進度所花費的時間將會反映在 [複本延隔時間] 計量中。
複寫狀態
若要監控複製的進度與狀態並促進操作，請參考Azure入口網站中的複製狀態欄位。 此資料行位於複寫頁面中，並顯示各種狀態，以深入了解讀取複本的目前狀況及其主要複本的連結。 對於依賴 Azure Resource Manager API 的使用者，當呼叫 GetReplica API 時，狀態會顯示在 replica 屬性包中以 ReplicationState 形式出現。
下列為可能的值：
| 複寫狀態 | 說明 | 升階排序 | 讀取複本建立順序 |
|---|---|---|---|
| 重新設定 | 等候複本-主要連結的啟動。 例如，如果複本或其區域 (因災害等) 而無法使用，它可能會維持較長的時間。 | 1 | N/A |
| 佈建 | 讀取副本正在配置中，兩台伺服器之間的複寫尚未開始。 在佈建完成之前，您無法連線到讀取複本。 | N/A | 1 |
| 更新中 | 在升級或讀取複本建立等觸發動作之後，正在準備伺服器設定。 | 2 | 2 |
| 同步中 | 正在複本上套用WAL 檔案。 升級期間此階段的持續時間取決於選擇的資料同步選項 - 已規劃或強制。 | 3 | 3 |
| 作用中 | 健康狀態，表示讀取複本已成功連接到主副本。 如果伺服器已停止，但先前已成功連線，會維持作用中狀態。 | 4 | 4 |
| 已中斷 | 狀況不良狀態，表示升級作業可能已失敗，或複本因某些原因而無法連線到主要複本。 要解決此狀態，丟棄副本並重新建立副本。 | N/A | N/A |
了解如何監視複寫。
考慮事項
本節將摘要說明有關讀取複本功能的考量。 以下幾點適用。
- 電源操作：你可以對主伺服器和副本伺服器套用電源操作，包括 啟動 和 停止 動作。 然而，為了維護系統完整性，請遵循特定的順序。 停止讀取複本之前，請先確定主要伺服器已停止。 開始作業時，請先在複本伺服器上起始啟動動作，再啟動主要伺服器。
- 如果伺服器有讀取副本，先刪除讀取副本，再刪除主伺服器。
- 適用於 PostgreSQL 的 Azure 資料庫彈性伺服器的就地主要版本升級，需要移除伺服器上已啟用的所有讀取複本和串聯讀取複本。 當副本被刪除後，你可以將主要伺服器升級到想要的主版本。 升級完成後，您可以重新建立複本以繼續複寫流程。
- 重設管理員密碼：目前不支援重設副本伺服器的管理員密碼。 此外，也不支援在同一請求中同時更新系統管理員密碼並升級複本作業。 如果你想執行這些操作，先升級副本伺服器，然後分別更新新升級伺服器的密碼。
新複本
您建立一個讀取複本，做為新的適用於 PostgreSQL 的 Azure 資料庫彈性伺服器。 您無法將現有伺服器變成複本。
資源移動
您可以在與主要伺服器不同的資源群組中建立讀取複本。 不過，並不支援在建立後將讀取複本移至其他資源群組。 此外，不支援將複本移至其他訂用帳戶。 不支援將具有讀取複本的主要伺服器移至另一個資源群組或訂用帳戶。
儲存體自動成長
當你為 適用於 PostgreSQL 的 Azure 資料庫 靈活伺服器設定讀取副本時，請確保副本上的儲存自動成長設定與主伺服器一致。 儲存體自動成長功能可讓資料庫儲存體自動增加，以避免空間不足，這可能會導致資料庫中斷。 以下說明如何有效地管理儲存體自動成長設定：
- 不論主要伺服器設定為何，您都可以在任何複本上啟用儲存體自動成長。
- 如果在主要伺服器上啟用儲存體自動成長，也必須在複本上啟用它，以確保儲存體縮放行為的一致性。
- 若要在主要複本上啟用儲存體自動成長，您必須先在複本上啟用它。 這項作業順序對於維護複寫完整性至關重要。
- 相反地，如果您想要停用儲存體自動成長，請先在主要伺服器上停用它，以避免複寫複雜。
備份及還原
當你管理 適用於 PostgreSQL 的 Azure 資料庫 靈活伺服器的備份與還原時，請記得該伺服器在不同升遷情境中目前及過去的角色。 請記住以下幾個重點：
提升至主要伺服器
- 不會從讀取複本進行備份：無論讀取複本伺服器先前曾擔任何種角色，系統都不會從中進行備份。
- 保存過去備份：若伺服器曾是主伺服器，系統在此期間進行備份，系統會保存這些備份至使用者定義的保留期限。
- 還原操作限制：即使伺服器過去有備份並轉換到讀取副本，還原操作仍受限制。 只有當伺服器被升回主要角色時，才能啟動還原操作。
為了清楚起見，下表說明了這些重點：
| 伺服器角色 | 已擷取的備份 | 允許的還原 |
|---|---|---|
| Primary | Yes | Yes |
| 讀取複本 | 否 | 否 |
| 將複本升階為主要複本 | Yes | Yes |
提升至獨立伺服器並從複寫中移除
雖然伺服器是讀取複本，但系統不會備份。 然而，一旦你將它升遷到獨立伺服器，系統會同時備份被升遷的伺服器和主伺服器。 你可以在兩台伺服器上還原備份。
網路
讀取副本支援 適用於 PostgreSQL 的 Azure 資料庫 靈活伺服器所支援的所有網路選項。
這很重要
主伺服器與讀取副本之間的雙向通訊對於 適用於 PostgreSQL 的 Azure 資料庫 的設定至關重要。 Azure 虛擬網路子網路必須允許在目的埠 5432 上發送與接收流量。
此要求不僅促進同步流程，也確保促進機制的正常運作。 複本可能需要以反向順序通訊 (從複本到主要伺服器)，尤其是在升級到主要伺服器作業期間。 此外，您必須允許連接儲存 Write-Ahead 日誌（WAL）檔案的Azure儲存帳號，以維持資料的穩定性並促進有效的復原流程。
若想了解更多如何為你的讀副本設定私有存取（虛擬網路整合）以及理解在私有網路情境下跨 Azure 區域與虛擬網路複製的影響，請參閱「跨 Azure 區域與虛擬網路的私有網路複製」文章。
複寫位置問題風險降低
在罕見的情況下，複寫位置所造成的高延遲可能會導致主要伺服器上的儲存體使用量因為累積的 WAL 檔案而增加。 如果儲存體使用量達到 95%，或可用容量低於 5 GiB，伺服器會自動切換為唯讀模式，以防止磁碟滿載錯誤。
維護主要伺服器的健康與功能是優先事項。 在這類極端情況下，伺服器可能會刪除複寫插槽，以確保主要伺服器仍可正常處理讀寫流量。 因此，複寫會切換至檔案型記錄傳送模式，這可能會導致較高的複寫延遲。
密切監控儲存使用與複製延遲，並採取必要措施在問題升級前加以防範。
Parameters
當你建立讀取副本時，它會繼承主伺服器的參數。 這種繼承確保了穩定且可靠的起點。 不過，建立讀取副本後，對主伺服器參數所做的任何更改都不會自動被複製。 此行為提供個別微調讀取複本的優點，例如，在不修改主要伺服器參數的情況下，增強讀取密集型作業的效能。 雖然這種行為提供了彈性與客製化選項，但當需要參數一致性時，也需要謹慎且手動管理，以維持主副本與其副本之間的一致性。
管理員可以在讀取副本伺服器上更改參數，並設定與主伺服器不同的值。 唯一的例外狀況是可能會影響複本復原的參數，如下列「縮放」一節所述：max_connections、max_prepared_transactions、max_locks_per_transaction、max_wal_senders、max_worker_processes。 為確保讀取副本的恢復無縫且不會遇到共享記憶體限制，請務必將這些特定參數設定為與 主伺服器設定的值等同或更大。 在降低讀取副本伺服器的參數值前，請確保複製延遲最小，或副本已完全追上主伺服器，以避免潛在的複製或復原問題。
Scale
你可以擴增或縮減計算資源（vCore）、將服務層級從「一般用途」變更為「記憶體最佳化」（或反之亦然），以及擴充儲存空間。 然而，以下幾點仍適用。
針對計算調整：
適用於 PostgreSQL 的 Azure 資料庫服務要求複本的多項參數必須大於或等於主 ，以確保複本在復原時不會耗盡共享記憶體。 受影響的參數為：
max_connections、max_prepared_transactions、max_locks_per_transaction、max_wal_sendersmax_worker_processes、。擴大：先擴大複本的計算，然後擴大主要伺服器。
縮小：先縮小主要伺服器的計算，然後縮小複本。
主要伺服器上的計算一律必須等於或小於最小複本的計算。
針對儲存體縮放：
擴大：先擴大複本的儲存體，然後再擴大主要複本。
主副本的儲存容量必須始終等於或小於最小副本的儲存容量。