連續封存可以用於建立一個高可用性 (HA) 集群配置，其中包含一個或多個備用伺服器，以便在主要伺服器發生故障時接管操作。 這種能力被廣泛稱為暖備份或日誌傳輸。
主要伺服器和備用伺服器協同工作以提供此功能，儘管伺服器之間僅鬆散耦合。 主要伺服器以連續封存模式運作，而每個備用伺服器以連續恢復模式運作，從主要伺服器讀取 WAL 檔案。 無需更改資料庫表即可啟用此功能，因此與其他一些複製解決方案相比，它提供了較低的管理開銷。 此配置對主要伺服器的性能影響也相對較小。
將 WAL 記錄從一個資料庫伺服器直接移動到另一個資料庫伺服器通常被描述為日誌傳輸。PostgreSQL 通過一次傳輸一個檔案（WAL 區段）來實現基於檔案的日誌傳輸。 無論是到相鄰系統、同一站點的另一個系統還是地球另一端的另一個系統，WAL 檔案 (16MB) 都可以輕鬆且廉價地傳輸。 此技術所需的頻寬根據主要伺服器的事務速率而有所不同。 基於記錄的日誌傳輸更精細，並通過網路連接以遞增方式串流 WAL 更改（請參閱第 26.2.5 節）。
應該注意的是，日誌傳輸是異步的，即 WAL 記錄在事務提交後傳輸。 因此，如果主要伺服器發生災難性故障，則存在數據丟失的窗口； 尚未傳輸的事務將丟失。 基於檔案的日誌傳輸中數據丟失窗口的大小可以通過使用 archive_timeout 參數來限制，該參數可以設置為低至幾秒。 然而，如此低的設置將大大增加檔案傳輸所需的頻寬。 串流複製（請參閱第 26.2.5 節）允許更小的數據丟失窗口。
恢復性能非常好，一旦激活，備用伺服器通常會在很短的時間內完全可用。 因此，這被稱為提供高可用性的暖備用配置。 從封存的基礎備份和前滾恢復伺服器將需要更長的時間，因此該技術僅提供災難恢復的解決方案，而不是高可用性。 備用伺服器也可以用於只讀查詢，在這種情況下，它被稱為熱備用伺服器。 有關更多資訊，請參閱第 26.4 節。
通常明智的做法是創建主要伺服器和備用伺服器，使其盡可能相似，至少從資料庫伺服器的角度來看是這樣。 尤其是，與表空間關聯的路徑名將未經修改地傳遞，因此如果使用了該功能，則主要伺服器和備用伺服器必須具有相同的表空間掛載路徑。 請記住，如果在主要伺服器上執行了 CREATE TABLESPACE，則在其執行之前，必須在主要伺服器和所有備用伺服器上創建它所需的新掛載點。 硬體不必完全相同，但經驗表明，維護兩個相同的系統比在應用程式和系統的生命週期內維護兩個不同的系統更容易。 無論如何，硬體架構必須相同——從 32 位系統傳輸到 64 位系統將無法工作。
通常，在運行不同主要 PostgreSQL 發布級別的伺服器之間進行日誌傳輸是不可能的。 PostgreSQL 全球開發組的策略是不在次要版本升級期間更改磁盤格式，因此在主要伺服器和備用伺服器上運行不同的次要版本級別可能會成功。 但是，不提供對此的正式支持，並且建議您盡可能使主要伺服器和備用伺服器保持在相同的發布級別。 在更新到新的次要版本時，最安全的策略是首先更新備用伺服器——新的次要版本更有可能讀取以前的次要版本的 WAL 檔案，而不是反之亦然。
如果伺服器啟動時資料目錄中存在 standby.signal 檔案，則伺服器進入備用模式。
在待機模式下，伺服器會持續套用從主伺服器接收到的 WAL。待機伺服器可以從 WAL 封存檔讀取 WAL（請參閱 restore_command），或直接透過 TCP 連線從主伺服器讀取（串流複製）。待機伺服器也會嘗試還原在待機叢集的 pg_wal 目錄中找到的任何 WAL。通常在伺服器重新啟動後會發生這種情況，屆時待機伺服器會重新播放在重新啟動之前從主伺服器串流的 WAL，但您也可以隨時手動將檔案複製到 pg_wal 以便重新播放。
啟動時，待機伺服器會先還原封存位置中所有可用的 WAL，並呼叫 restore_command。一旦它到達可用的 WAL 結尾，且 restore_command 失敗，它會嘗試還原 pg_wal 目錄中任何可用的 WAL。如果該操作失敗，且已設定串流複製，則待機伺服器會嘗試連線到主伺服器，並從在封存檔或 pg_wal 中找到的最後一個有效記錄開始串流 WAL。如果該操作失敗或未設定串流複製，或者如果連線稍後中斷，待機伺服器會返回步驟 1，並再次嘗試從封存檔還原檔案。這種從封存檔、pg_wal 和透過串流複製重試的迴圈會一直持續，直到伺服器停止或升級為止。
當執行 pg_ctl promote 命令，或呼叫 pg_promote() 函數時，會退出待機模式，並且伺服器切換到正常操作。在容錯移轉之前，將會還原封存檔或 pg_wal 中任何可立即使用的 WAL，但不會嘗試連線到主伺服器。
在主伺服器上設定持續封存到可從待機伺服器存取的封存目錄，如 第 25.3 節 中所述。即使主伺服器已關閉，待機伺服器也應該可以存取封存位置，也就是說，它應該位於待機伺服器本身或另一個受信任的伺服器上，而不是位於主伺服器上。
如果您想要使用串流複製，請在主伺服器上設定驗證，以允許來自待機伺服器的複製連線；也就是說，建立一個角色，並在 pg_hba.conf 中提供一個或多個適當的項目，並將資料庫欄位設定為 replication。此外，請確保在主伺服器的組態檔中將 max_wal_senders 設定為足夠大的值。如果將使用複製槽，請確保 max_replication_slots 也設定得足夠高。
取得基本備份，如 第 25.3.2 節 中所述，以啟動待機伺服器。
若要設定待機伺服器，請還原從主伺服器取得的基本備份（請參閱 第 25.3.5 節）。在待機伺服器的叢集資料目錄中建立一個檔案 standby.signal。將 restore_command 設定為一個簡單的命令，以從 WAL 封存檔複製檔案。如果您計畫擁有多個待機伺服器以實現高可用性，請確保 recovery_target_timeline 設定為 latest（預設值），以使待機伺服器遵循在容錯移轉到另一個待機伺服器時發生的時間軸變更。
如果檔案不存在，restore_command 應立即傳回；如果需要，伺服器將再次重試該命令。
如果您想要使用串流複製，請在 primary_conninfo 中填寫 libpq 連線字串，包括主機名稱（或 IP 位址）以及連線到主伺服器所需的任何其他詳細資訊。如果主伺服器需要密碼進行驗證，則也需要在 primary_conninfo 中指定密碼。
如果您正在設定待機伺服器以實現高可用性，請設定 WAL 封存、連線和驗證，就像主伺服器一樣，因為待機伺服器在容錯移轉後將充當主伺服器。
如果您使用 WAL 封存檔，可以使用 archive_cleanup_command 參數將其大小最小化，以移除待機伺服器不再需要的檔案。pg_archivecleanup 公用程式專門設計為與典型單一待機配置中的 archive_cleanup_command 一起使用，請參閱 pg_archivecleanup。但是請注意，如果您將封存檔用於備份目的，則您需要保留至少從最新基本備份還原所需的檔案，即使待機伺服器不再需要它們也是如此。
一個簡單的組態範例是
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass options=''-c wal_sender_timeout=5000''' restore_command = 'cp /path/to/archive/%f %p' archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'
您可以擁有任意數量的待機伺服器，但如果您使用串流複製，請確保在主伺服器中將 max_wal_senders 設定得足夠高，以允許它們同時連線。
串流複製允許待機伺服器比基於檔案的日誌傳輸更即時地保持最新狀態。待機伺服器連線到主伺服器，主伺服器在生成 WAL 記錄時將其串流傳輸到待機伺服器，而無需等待 WAL 檔案填滿。
串流複製預設是異步的（請參閱 第 26.2.8 節），在這種情況下，在主伺服器中提交交易與變更在待機伺服器中可見之間存在很小的延遲。但是，此延遲比基於檔案的日誌傳輸小得多，通常在假設待機伺服器功能強大到足以跟上負載的情況下，延遲小於一秒。使用串流複製，不需要 archive_timeout 來減少資料遺失窗口。
如果您在沒有基於檔案的持續封存的情況下使用串流複製，伺服器可能會在待機伺服器收到它們之前回收舊的 WAL 段。如果發生這種情況，則需要從新的基本備份重新初始化待機伺服器。您可以將 wal_keep_size 設定為足夠大的值，以確保 WAL 段不會過早回收，或者為待機伺服器設定複製槽，來避免這種情況。如果您設定了一個可從待機伺服器存取的 WAL 封存檔，則不需要這些解決方案，因為只要它保留足夠的段，待機伺服器始終可以使用該封存檔來趕上進度。
若要使用串流複寫，請按照第 26.2 節所述，設定一個基於檔案的日誌傳輸備援伺服器。將基於檔案的日誌傳輸備援伺服器轉換為串流複寫備援伺服器的步驟是設定 primary_conninfo，使其指向主伺服器。在主伺服器上設定 listen_addresses 和驗證選項（請參閱 pg_hba.conf），以便備援伺服器可以連線到主伺服器上的 replication 虛擬資料庫（請參閱第 26.2.5.1 節）。
在支援 keepalive socket 選項的系統上，設定 tcp_keepalives_idle、tcp_keepalives_interval 和 tcp_keepalives_count 有助於主伺服器迅速注意到斷線。
設定來自備援伺服器的並行連線數上限（詳情請參閱 max_wal_senders）。
當備援伺服器啟動且 primary_conninfo 設定正確時，備援伺服器將在重播封存中所有可用的 WAL 檔案後連線到主伺服器。如果連線成功建立，您將在備援伺服器中看到一個 walreceiver，並在主伺服器中看到一個相應的 walsender 程序。
replication 的存取權限的設定非常重要，應確保只有受信任的使用者可以讀取 WAL 串流，因為從中可以輕易提取敏感資訊。備援伺服器必須以具有 REPLICATION 權限或超級使用者的帳戶驗證主伺服器。建議建立一個專用的使用者帳戶，並授予其 REPLICATION 和 LOGIN 權限以用於複寫。雖然 REPLICATION 權限賦予了非常高的權限，但它不允許使用者修改主系統上的任何資料，而 SUPERUSER 權限則可以。
replication 的客戶端驗證由 pg_hba.conf 記錄控制，該記錄在 database 欄位中指定 replication。例如，如果備援伺服器在主機 IP 192.168.1.100 上執行，且 replication 的帳戶名稱為 foo，則管理員可以將以下行新增到主伺服器上的 pg_hba.conf 檔案中：
# Allow the user "foo" from host 192.168.1.100 to connect to the primary # as a replication standby if the user's password is correctly supplied. # # TYPE DATABASE USER ADDRESS METHOD host replication foo 192.168.1.100/32 md5
主伺服器的主機名稱和連接埠號碼、連線使用者名稱和密碼在 primary_conninfo 中指定。密碼也可以在備援伺服器上的 ~/.pgpass 檔案中設定（在 database 欄位中指定 replication）。例如，如果主伺服器在主機 IP 192.168.1.50、連接埠 5432 上執行，replication 的帳戶名稱為 foo，且密碼為 foopass，則管理員可以將以下行新增到備援伺服器上的 postgresql.conf 檔案中：
# The standby connects to the primary that is running on host 192.168.1.50 # and port 5432 as the user "foo" whose password is "foopass". primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
串流複寫的一個重要健康指標是在主伺服器中產生但尚未在備援伺服器中套用的 WAL 記錄量。您可以通過比較主伺服器上的當前 WAL 寫入位置與備援伺服器接收的最後一個 WAL 位置來計算此延遲。可以使用主伺服器上的 pg_current_wal_lsn 和備援伺服器上的 pg_last_wal_receive_lsn 檢索這些位置（詳情請參閱表格 9.95 和 表格 9.96）。備援伺服器中的最後一個 WAL 接收位置也會顯示在使用 ps 命令顯示的 WAL 接收器程序的程序狀態中（詳情請參閱第 27.1 節）。
您可以通過 pg_stat_replication 檢視檢索 WAL 發送器程序的清單。pg_current_wal_lsn 與檢視的 sent_lsn 欄位之間的大差異可能表示主伺服器處於重負載下，而備援伺服器上的 sent_lsn 與 pg_last_wal_receive_lsn 之間差異可能表示網路延遲，或者備援伺服器處於重負載下。
在熱備援伺服器上，可以通過 pg_stat_wal_receiver 檢視檢索 WAL 接收器程序的狀態。pg_last_wal_replay_lsn 與檢視的 flushed_lsn 之間的大差異表示接收 WAL 的速度快於重播速度。
複寫槽提供了一種自動化的方法，可確保主伺服器在所有備援伺服器收到 WAL 片段之前不會移除它們，並且即使在備援伺服器斷線時，主伺服器也不會移除可能導致復原衝突的列。
除了使用複寫槽之外，也可以使用 wal_keep_size 阻止移除舊的 WAL 片段，或使用 archive_command 或 archive_library 將片段儲存在封存中。這些方法的一個缺點是，它們通常會保留比需要更多的 WAL 片段，而複寫槽僅保留已知需要的片段數量。
同樣，單獨使用 hot_standby_feedback，而不使用複寫槽，可以防止真空移除相關列，但在備援伺服器未連線的任何時間段內均不提供保護。
請注意，複寫槽可能會導致伺服器保留過多的 WAL 片段，以致於填滿為 pg_wal 分配的空間。可以使用 max_slot_wal_keep_size 限制複寫槽保留的 WAL 檔案大小。
每個複寫槽都有一個名稱，該名稱可以包含小寫字母、數字和底線字元。
現有的複寫槽及其狀態可以在 pg_replication_slots 檢視中看到。
可以通過串流複寫協議（請參閱第 53.4 節）或通過 SQL 函數（請參閱第 9.28.6 節）建立和刪除槽。
您可以像這樣建立一個複寫槽：
postgres=# SELECT * FROM pg_create_physical_replication_slot('node_a_slot');
slot_name | lsn
-------------+-----
node_a_slot |
postgres=# SELECT slot_name, slot_type, active FROM pg_replication_slots;
slot_name | slot_type | active
-------------+-----------+--------
node_a_slot | physical | f
(1 row)
若要將備援伺服器配置為使用此槽，應在備援伺服器上配置 primary_slot_name。這是一個簡單的範例：
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass' primary_slot_name = 'node_a_slot'
串聯式複寫功能允許備援伺服器接受複寫連線，並將 WAL 紀錄串流傳輸到其他備援伺服器，充當轉發中繼站。這可用於減少與主伺服器的直接連線數，並最大程度地減少站點間頻寬的開銷。
作為接收者和發送者的備援伺服器被稱為串聯式備援伺服器。更直接連接到主伺服器的備援伺服器被稱為上游伺服器，而更遠的備援伺服器則稱為下游伺服器。串聯式複寫不限制下游伺服器的數量或排列方式，但每個備援伺服器僅連接到一個最終連結到單個主伺服器的上游伺服器。
串聯式備援伺服器不僅發送從主伺服器收到的 WAL 紀錄，還發送從封存檔還原的紀錄。因此，即使某些上游連線中的複寫連線終止，只要有新的 WAL 紀錄可用，串流複寫就會在下游繼續進行。
串聯式複寫目前是異步的。同步複寫（請參閱Section 26.2.8）設定目前對串聯式複寫沒有任何影響。
無論串聯式排列如何，熱備援回饋都會向上游傳播。
如果上游備援伺服器被提升為新的主伺服器，如果 recovery_target_timeline 設定為 'latest'（預設值），則下游伺服器將繼續從新的主伺服器串流資料。
要使用串聯式複寫，請設定串聯式備援伺服器，使其可以接受複寫連線（也就是說，設定 max_wal_senders 和 hot_standby，並設定 基於主機的身份驗證）。您還需要在下游備援伺服器中設定 primary_conninfo，以指向串聯式備援伺服器。
PostgreSQL 串流複寫預設為異步。如果主伺服器崩潰，則某些已提交的事務可能尚未複寫到備援伺服器，從而導致資料遺失。資料遺失量與故障轉移時的複寫延遲成正比。
同步複寫提供確認事務的所有變更已傳輸到一個或多個同步備援伺服器的能力。這擴展了事務提交提供的標準持久性層級。在計算機科學理論中，此保護等級稱為 2-safe 複寫，當 synchronous_commit 設定為 remote_write 時，稱為 group-1-safe（group-safe 和 1-safe）。
當請求同步複寫時，寫入事務的每個提交將等待，直到收到確認，確認提交已寫入主伺服器和備援伺服器磁碟上的預寫日誌中。資料可能遺失的唯一可能性是主伺服器和備援伺服器同時發生崩潰。這可以提供更高的持久性等級，但前提是系統管理員對兩台伺服器的位置和管理保持謹慎。等待確認會增加用戶對變更不會在伺服器崩潰時遺失的信心，但也必然會增加請求事務的回應時間。最短等待時間是主伺服器和備援伺服器之間的往返時間。
唯讀事務和事務回滾不需要等待備援伺服器的回覆。子事務提交不需要等待備援伺服器的回應，只有頂層提交需要等待。長時間運行的動作（例如資料載入或索引建立）不會等到最終的提交訊息。所有兩階段提交動作都需要提交等待，包括準備和提交。
同步備援伺服器可以是實體複寫備援伺服器或邏輯複寫訂閱者。它也可以是任何其他實體或邏輯 WAL 複寫串流消費者，它知道如何發送適當的回饋訊息。除了內建的實體和邏輯複寫系統之外，還包括特殊程式（例如 pg_receivewal 和 pg_recvlogical）以及某些第三方複寫系統和自訂程式。有關同步複寫支援的詳細資訊，請查看各自的文件。
設定串流複寫後，設定同步複寫只需要一個額外的設定步驟：synchronous_standby_names 必須設定為非空值。synchronous_commit 也必須設定為 on，但由於這是預設值，因此通常不需要更改。（請參閱Section 19.5.1 和 Section 19.6.2。）此設定將導致每個提交都等待，直到確認備援伺服器已將提交紀錄寫入持久性儲存裝置。 synchronous_commit 可以由個別用戶設定，因此可以在組態檔中、針對特定用戶或資料庫進行設定，也可以由應用程式動態設定，以便按事務控制持久性保證。
在提交紀錄已寫入主伺服器上的磁碟後，WAL 紀錄會傳送到備援伺服器。每當新的一批 WAL 資料寫入磁碟時，備援伺服器都會發送回覆訊息，除非備援伺服器上的 wal_receiver_status_interval 設定為零。如果 synchronous_commit 設定為 remote_apply，則備援伺服器會在重新執行提交紀錄時發送回覆訊息，使事務可見。如果根據主伺服器上的 synchronous_standby_names 設定將備援伺服器選為同步備援伺服器，則會將來自該備援伺服器的回覆訊息與來自其他同步備援伺服器的回覆訊息一起考慮，以決定何時釋放等待確認已收到提交紀錄的事務。這些參數允許管理員指定哪些備援伺服器應為同步備援伺服器。請注意，同步複寫的設定主要在主伺服器上。已命名的備援伺服器必須直接連接到主伺服器；主伺服器不知道使用串聯式複寫的下游備援伺服器。
將 synchronous_commit 設定為 remote_write 將導致每個提交都等待，直到確認備援伺服器已收到提交紀錄並將其寫出到其自己的作業系統，而不是將資料刷新到備援伺服器上的磁碟。此設定提供的持久性保證比 on 弱：備援伺服器可能會在作業系統崩潰時遺失資料，但不會在 PostgreSQL 崩潰時遺失資料。但是，它在實踐中是一個有用的設定，因為它可以縮短事務的回應時間。只有在主伺服器和備援伺服器都崩潰，並且主伺服器的資料庫同時損毀時，才會發生資料遺失。
將 synchronous_commit 設定為 remote_apply 會導致每個提交 (commit) 都等待，直到目前的同步備用伺服器報告它們已重播 (replayed) 該交易，使其對使用者查詢可見。在簡單情況下，這允許使用因果一致性進行負載平衡。
如果請求快速關機，使用者將停止等待。然而，如同使用非同步複製一樣，伺服器不會完全關機，直到所有未完成的 WAL 記錄傳輸到目前連接的備用伺服器為止。
同步複製支援一個或多個同步備用伺服器；交易將等待，直到所有被視為同步的備用伺服器確認收到它們的資料。交易必須等待回覆的同步備用伺服器數量在 synchronous_standby_names 中指定。此參數也指定一個備用伺服器名稱清單以及選擇同步備用伺服器的方法（FIRST 和 ANY）。
方法 FIRST 指定基於優先順序的同步複製，並使交易提交等待，直到它們的 WAL 記錄被複製到基於其優先順序選擇的指定數量的同步備用伺服器。名稱在清單中較早出現的備用伺服器具有較高的優先順序，並且將被視為同步的。此清單中稍後出現的其他備用伺服器代表潛在的同步備用伺服器。如果任何目前的同步備用伺服器因任何原因斷開連接，它將立即被下一個最高優先順序的備用伺服器替換。
基於優先順序的多個同步備用伺服器的 synchronous_standby_names 範例為：
synchronous_standby_names = 'FIRST 2 (s1, s2, s3)'
在此範例中，如果四個備用伺服器 s1、s2、s3 和 s4 正在運行，則兩個備用伺服器 s1 和 s2 將被選為同步備用伺服器，因為它們的名稱在備用伺服器名稱清單中較早出現。s3 是一個潛在的同步備用伺服器，並且在 s1 或 s2 發生故障時將接管同步備用伺服器的角色。s4 是一個非同步備用伺服器，因為它的名稱不在清單中。
方法 ANY 指定基於仲裁的同步複製，並使交易提交等待，直到它們的 WAL 記錄被複製到清單中 至少 指定數量的同步備用伺服器。
基於仲裁的多個同步備用伺服器的 synchronous_standby_names 範例為：
synchronous_standby_names = 'ANY 2 (s1, s2, s3)'
在此範例中，如果四個備用伺服器 s1、s2、s3 和 s4 正在運行，則交易提交將等待來自 s1、s2 和 s3 中至少任意兩個備用伺服器的回覆。s4 是一個非同步備用伺服器，因為它的名稱不在清單中。
可以使用 pg_stat_replication 檢視查看備用伺服器的同步狀態。
同步複製通常需要仔細規劃和放置備用伺服器，以確保應用程式的效能在可接受範圍內。等待不會利用系統資源，但交易鎖會一直持有，直到確認傳輸為止。因此，不謹慎地使用同步複製會因增加的響應時間和更高的競爭而降低資料庫應用程式的效能。
PostgreSQL 允許應用程式開發人員指定透過複製所需的持久性級別。這可以針對整個系統指定，但也可以針對特定使用者或連線，甚至個別交易指定。
例如，一個應用程式工作負載可能包含：10% 的變更重要的客戶詳細資訊，而 90% 的變更是不太重要的数据，如果丟失，企業可以更容易地生存，例如使用者之間的聊天訊息。
透過在應用程式層級（在主伺服器上）指定的同步複製選項，我們可以為最重要的變更提供同步複製，而不會減慢總體工作負載的大部分。應用程式層級選項是一個重要且實用的工具，可允許高效能應用程式受益於同步複製。
您應該考慮網路頻寬必須高於 WAL 資料的產生速率。
synchronous_standby_names 指定當 synchronous_commit 設定為 on、remote_apply 或 remote_write 時，交易提交將等待回覆的同步備用伺服器的數量和名稱。如果任何一個同步備用伺服器崩潰，此類交易提交可能永遠無法完成。
實現高可用性的最佳解決方案是確保您保持盡可能多的同步備用伺服器。這可以透過使用 synchronous_standby_names 命名多個潛在的同步備用伺服器來實現。
在基於優先順序的同步複製中，名稱在清單中較早出現的備用伺服器將被用作同步備用伺服器。如果目前的備用伺服器之一發生故障，則在這些之後列出的備用伺服器將接管同步備用伺服器的角色。
在基於仲裁的同步複製中，清單中出現的所有備用伺服器將被用作同步備用伺服器的候選者。即使其中一個發生故障，其他備用伺服器也將繼續執行同步備用候選者的角色。
當備用伺服器首次連接到主伺服器時，它尚未正確同步。這被描述為 catchup 模式。一旦備用伺服器和主伺服器之間的延遲首次達到零，我們就會進入即時 streaming 狀態。在建立備用伺服器後，補追 (catch-up) 持續時間可能很長。如果備用伺服器關閉，則補追週期將根據備用伺服器關閉的時間長度而增加。備用伺服器只有在達到 streaming 狀態後才能成為同步備用伺服器。可以使用 pg_stat_replication 檢視來查看此狀態。
如果主伺服器在提交等待確認時重新啟動，一旦主資料庫恢復，那些等待中的交易將被標記為完全提交。無法確定所有備用伺服器在主伺服器崩潰時已收到所有未完成的 WAL 資料。某些交易可能不會顯示在備用伺服器上已提交，即使它們顯示在主伺服器上已提交。我們提供的保證是，在所有同步備用伺服器都安全收到 WAL 資料之前，應用程式不會收到成功提交交易的明確確認。
如果您真的無法保持所需數量的同步備用伺服器，則應減少交易提交必須等待來自 synchronous_standby_names 的回覆的同步備用伺服器數量（或禁用它），然後在主伺服器上重新載入設定檔。
如果主伺服器與剩餘的備用伺服器隔離，則應故障轉移到其他剩餘備用伺服器中的最佳候選者。
如果您需要在交易等待期間重新建立備用伺服器，請確保函數 pg_backup_start() 和 pg_backup_stop() 是在 synchronous_commit = off 的會話中執行的，否則這些請求將永遠等待備用伺服器的出現。
當在備用伺服器中使用持續 WAL 封存時，有兩種不同的情境：WAL 封存可以在主要伺服器和備用伺服器之間共享，或者備用伺服器可以有自己的 WAL 封存。當備用伺服器有自己的 WAL 封存時，將 archive_mode 設定為 always，備用伺服器將對它收到的每個 WAL 段呼叫封存命令，無論是透過從封存還原還是透過串流複製。共享封存可以用類似的方式處理，但 archive_command 或 archive_library 必須測試被封存的檔案是否已經存在，以及現有檔案是否具有相同的內容。這需要在 archive_command 或 archive_library 中更加謹慎，因為它必須小心不要用不同的內容覆蓋現有檔案，但如果完全相同的檔案被封存兩次，則返回成功。而且所有這些都必須在沒有競爭條件的情況下完成，如果兩台伺服器同時嘗試封存同一個檔案。
如果 archive_mode 設定為 on，則封存器在復原或備用模式期間不會啟用。如果備用伺服器被提升，它將在提升後開始封存，但不會封存它自己未產生的任何 WAL 或時間軸歷史檔案。要在封存中獲得完整的 WAL 檔案序列，您必須確保在所有 WAL 到達備用伺服器之前，都已將其封存。這在使用基於檔案的日誌傳輸時本質上是真的，因為備用伺服器只能還原在封存中找到的檔案，但如果啟用了串流複製則不行。當伺服器不在復原模式時，on 和 always 模式之間沒有區別。
如果您在文件中發現任何不正確、與您使用特定功能的經驗不符或需要進一步澄清的地方，請使用此表格來回報文件問題。