持續歸檔可用於建立具有一個或多個備用伺服器的高可用性 (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 歸檔（請參閱 restore_command）讀取 WAL，或直接透過 TCP 連線（流複製）從主伺服器讀取 WAL。備用伺服器還將嘗試恢復備用叢集的 pg_wal 目錄中找到的任何 WAL。這通常發生在伺服器重新啟動後，備用伺服器在重新啟動前再次重放從主伺服器流式傳輸的 WAL，但您也可以隨時手動將檔案複製到 pg_wal 以便進行重放。
啟動時，備用伺服器將透過呼叫 restore_command 來恢復歸檔位置中所有可用的 WAL。一旦到達那裡可用的 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 選項的系統上，設定 tcp_keepalives_idle、tcp_keepalives_interval 和 tcp_keepalives_count 有助於主伺服器及時發現連線中斷。
設定來自備用伺服器的最大併發連線數（有關詳細資訊，請參閱 max_wal_senders）。
當備用伺服器啟動且 primary_conninfo 設定正確時，備用伺服器將在重放歸檔中所有可用的 WAL 檔案後連線到主伺服器。如果連線成功建立，您將在備用伺服器上看到一個 walreceiver，並在主伺服器上看到一個相應的 walsender 程序。
設定複製的訪問許可權以僅允許受信任的使用者讀取 WAL 流非常重要，因為它很容易從中提取特權資訊。備用伺服器必須作為具有 REPLICATION 許可權或超級使用者許可權的帳戶進行身份驗證。建議建立一個具有 REPLICATION 和 LOGIN 許可權的專用使用者帳戶用於複製。雖然 REPLICATION 許可權提供了非常高的許可權，但它不允許使用者修改主系統上的任何資料，而 SUPERUSER 許可權則可以。
複製的客戶端身份驗證由 pg_hba.conf 記錄控制，該記錄在資料庫欄位中指定 replication。例如，如果備用伺服器執行在主機 IP 192.168.1.100 上，並且用於複製的帳戶名為 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 檔案中設定（在資料庫欄位中指定 replication）。例如，如果主伺服器執行在主機 IP 192.168.1.50 上，埠為 5432，用於複製的帳戶名為 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.97 和 表 9.98）。備用伺服器中的最後一個 WAL 接收位置也顯示在 WAL 接收器程序的程序狀態中，使用 ps 命令顯示（有關詳細資訊，請參閱 第 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（而不使用複製槽）可以防止 vacuum 刪除相關行，但在備用伺服器未連線的任何時間段內都無法提供保護。
請注意，複製槽可能導致伺服器保留過多的 WAL 段，從而填滿為 pg_wal 分配的空間。max_slot_wal_keep_size 可用於限制複製槽保留的 WAL 檔案的大小。
每個複製槽都有一個名稱，該名稱可以包含小寫字母、數字和下劃線字元。
可以在 pg_replication_slots 檢視中檢視現有的複製槽及其狀態。
可以透過流複製協議（請參閱 第 54.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 記錄。因此，即使在某個上游連線中複製連線中斷，只要有新的 WAL 記錄可用，流複製就會在下游繼續。
級聯複製目前是非同步的。同步複製（請參閱 第 26.2.8 節）設定目前對級聯複製沒有影響。
熱備用反饋會傳播到上游，無論級聯排列如何。
如果上游備用伺服器被提升為新的主伺服器，下游伺服器將繼續從新主伺服器流式傳輸，前提是 recovery_target_timeline 設定為 'latest'（預設值）。
要使用級聯複製，請設定級聯備用伺服器，使其能夠接受複製連線（即，設定 max_wal_senders 和 hot_standby，並配置 基於主機的身份驗證）。您還需要在下游備用伺服器上設定 primary_conninfo 以指向級聯備用伺服器。
PostgreSQL 流複製預設是非同步的。如果主伺服器崩潰，那麼已提交的一些事務可能尚未複製到備用伺服器，從而導致資料丟失。資料丟失量與故障轉移時複製延遲成正比。
同步複製提供了確認一個或多個同步備用伺服器上的所有事務更改已完成的能力。這擴充套件了事務提交提供的標準永續性級別。這種保護級別在計算機科學理論中被稱為 2-安全複製，當 synchronous_commit 設定為 remote_write 時，稱為 group-1-safe（組安全和 1-安全）。
請求同步複製時，每個寫事務的提交將等待確認，即提交已寫入主伺服器和備用伺服器的磁碟寫預日誌。唯一可能丟失資料的情況是主伺服器和備用伺服器同時發生崩潰。這可以提供更高水平的永續性，但前提是系統管理員謹慎地放置和管理這兩個伺服器。等待確認會增加使用者對更改不會在伺服器崩潰時丟失的信心，但它也必然會增加請求事務的響應時間。最小等待時間是主伺服器和備用伺服器之間的往返時間。
只讀事務和事務回滾不需要等待來自備用伺服器的響應。子事務提交不需要等待來自備用伺服器的響應，只有頂層提交才需要。長時間執行的操作（如資料載入或索引構建）不會等到最終的提交訊息。所有兩階段提交操作都需要等待提交，包括準備和提交。
同步備用伺服器可以是物理複製備用伺服器或邏輯複製訂閱者。它也可以是任何其他物理或邏輯 WAL 複製流使用者，它們知道如何傳送適當的反饋訊息。除了內建的物理和邏輯複製系統外，這還包括 pg_receivewal 和 pg_recvlogical 等特殊程式，以及一些第三方複製系統和自定義程式。請檢視各自的文件以瞭解同步複製支援的詳細資訊。
一旦配置了流複製，配置同步複製只需要一個額外的配置步驟：必須將 synchronous_standby_names 設定為非空值。還必須將 synchronous_commit 設定為 on，但由於這是預設值，通常不需要更改。（請參閱 第 19.5.1 節和 第 19.6.2 節。）此配置將導致每個提交等待確認備用伺服器已將提交記錄寫入持久儲存。 synchronous_commit 可以由單個使用者設定，因此可以針對特定使用者或資料庫在配置檔案中進行配置，或者由應用程式動態配置，以在每個事務的基礎上控制永續性保證。
在提交記錄寫入主伺服器磁碟後，WAL 記錄隨後會發送到備用伺服器。除非在備用伺服器上將 wal_receiver_status_interval 設定為零，否則備用伺服器會在每次將新的 WAL 資料塊寫入磁碟時傳送響應訊息。如果 synchronous_commit 設定為 remote_apply，則備用伺服器會在提交記錄重放並使事務對使用者可見時傳送響應訊息。如果根據主伺服器上的 synchronous_standby_names 設定，備用伺服器被選為同步備用伺服器，則該備用伺服器的響應訊息將與其他同步備用伺服器的訊息一起考慮，以決定何時釋放正在等待已接收提交記錄的事務。這些引數允許管理員指定哪些備用伺服器應該是同步備用伺服器。請注意，同步複製的配置主要在主伺服器上。命名的備用伺服器必須直接連線到主伺服器；主伺服器對使用級聯複製的下游備用伺服器一無所知。
將 synchronous_commit 設定為 remote_write 將導致每個提交等待確認備用伺服器已接收到提交記錄並將其寫入其自己的作業系統，但不是等待資料重新整理到備用伺服器的磁碟。此設定提供的永續性保證比 on 弱：備用伺服器可能在作業系統崩潰的情況下丟失資料，但在 PostgreSQL 崩潰的情況下不會。但是，這在實踐中是一個有用的設定，因為它可能會縮短事務的響應時間。只有當主伺服器和備用伺服器同時崩潰並且主伺服器的資料庫同時損壞時，才可能發生資料丟失。
將 synchronous_commit 設定為 remote_apply 將導致每個提交等待，直到當前同步備用伺服器報告它們已重放事務，從而使其對使用者查詢可見。在簡單的情況下，這可以實現因果一致性的負載均衡。
當請求快速關閉時，使用者將停止等待。但是，與使用非同步複製一樣，伺服器在所有掛起的 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狀態。備用伺服器建立後立即可能需要很長時間才能趕上。如果備用伺服器關閉，那麼趕上持續時間將根據備用伺服器關閉的時間長度而增加。只有當備用伺服器達到streaming狀態後，它才能成為同步備用伺服器。可以使用 pg_stat_replication 檢視檢視此狀態。
如果主伺服器在提交等待確認時重新啟動，則在主資料庫恢復後，這些等待的事務將被標記為完全提交。在主伺服器崩潰時，無法確保所有備用伺服器都已接收到所有掛起的 WAL 資料。某些事務可能不會在備用伺服器上顯示為已提交，即使它們在主伺服器上顯示為已提交。我們提供的保證是，在 WAL 資料已知已被所有同步備用伺服器安全接收之前，應用程式不會收到事務成功提交的明確確認。
如果確實無法保留請求數量的同步備用伺服器，則應減小 synchronous_standby_names 中事務提交必須等待響應的同步備用伺服器的數量（或停用它），然後重新載入主伺服器上的配置檔案。
如果主伺服器與剩餘的備用伺服器隔離，則應故障轉移到這些其他剩餘備用伺服器中的最佳候選。
如果需要在事務等待時重新建立備用伺服器，請確保在 synchronous_commit = off 的會話中執行 pg_backup_start() 和 pg_backup_stop() 函式，否則這些請求將永遠等待備用伺服器出現。
當在備用伺服器中使用持續 WAL 歸檔時，有兩種不同情況：WAL 歸檔可以在主伺服器和備用伺服器之間共享，或者備用伺服器可以擁有自己的 WAL 歸檔。當備用伺服器擁有自己的 WAL 歸檔時，將 archive_mode 設定為 always，備用伺服器將為它收到的每個 WAL 段呼叫歸檔命令，無論它是透過從歸檔恢復還是透過流複製。共享歸檔也可以類似地處理，但是 archive_command 或 archive_library 必須測試要歸檔的檔案是否已存在，並且現有檔案是否具有相同的內容。這需要 archive_command 或 archive_library 更加小心，因為它必須小心不要用不同的內容覆蓋現有檔案，但如果同一個檔案被歸檔兩次則返回成功。如果兩個伺服器嘗試同時歸檔同一個檔案，所有這些都必須在沒有競爭條件的情況下完成。
如果將 archive_mode 設定為 on，則在恢復或備用模式期間不啟用歸檔器。如果備用伺服器被提升，它將在提升後開始歸檔，但不會歸檔它自己未生成的任何 WAL 或時間線歷史檔案。要獲得完整的 WAL 檔案系列歸檔，您必須確保在所有 WAL 到達備用伺服器之前將其歸檔。基於檔案的日誌傳輸在本質上是正確的，因為備用伺服器只能恢復在歸檔中找到的檔案，而流複製啟用時則不能。當伺服器未處於恢復模式時，on 和 always 模式之間沒有區別。
如果您在文件中發現任何不正確之處、與您對特定功能的實際體驗不符之處，或者需要進一步澄清之處，請使用 此表單 報告文件問題。