2026 PostgreSQL 18 主備複製怎樣驗收？故障切換清單

PostgreSQL 官方版本政策為每個主要版本提供 5 年支援；這是版本生命週期資訊，不是主備可靠性的證明。官方版本政策指出支援週期後，PostgreSQL 18 主備複製驗收仍須逐項確認 WAL 接收與回放、計畫內提升、應用寫入恢復、下游邏輯複製槽，以及回退邊界。非同步複製可能遺失尚未送達備用節點的交易；主備複製也不能代替機外備份。

這篇適合負責 PostgreSQL 18 生產主庫與實體備用節點的 DBA，以及需要確認資源、網路與節點隔離的基礎設施工程師。
應用發布、值班與資料消費團隊也可用它核對切換後的寫入、連線恢復和放行責任。

先按團隊職責設定放行邊界

驗收不應由單一角色只看一個監控指標。開始演練前，先指定誰確認資料庫狀態、誰執行提升、誰驗證應用，以及誰有權停止或回退。

• DBA：確認主庫送出的 WAL、備用節點收到的 WAL 與實際回放位置；記錄複製槽及 WAL 保留風險。
• 基礎設施工程師：核實兩台伺服器間實際可用的網路路徑、存取控制、故障隔離和各自的硬體資源。不要把尚未驗證的網路或管理能力當成既有條件。
• 應用團隊：確認連線池重試、交易結果判斷與重複提交處理，並驗證新主庫的讀寫方向。
• 下游資料團隊：盤點 CDC、邏輯訂閱及其他依賴複製槽的消費者；沒有這類消費者時，明確標記不適用。
• 值班負責人：掌握停止條件、回退責任人和備份還原結果，再決定是否放行。

以三個 WAL 位置判讀複製狀態

PostgreSQL 的複製監控不能只看一個延遲欄位。官方流複製監控文件區分傳送端與備用端的狀態；驗收時至少要分開回答：主庫是否送出、備用端是否收到、收到的內容是否已回放。

在主庫檢查 pg_stat_replication，確認目標備用節點有對應連線，並查看 sent_lsn、write_lsn、flush_lsn、replay_lsn 等位置欄位。這些位置各自反映 WAL 傳送和處理進度，不能把連線存在直接等同於資料已回放。再於備用端檢查 pg_stat_wal_receiver，確認接收程序狀態和接收位置；使用 pg_last_wal_replay_lsn() 核對實際回放位置。相關欄位與管理函式可參照複製參數文件及管理函式文件。

-- 主庫：確認備用端連線與 WAL 位置
SELECT application_name, state, sent_lsn, write_lsn, flush_lsn, replay_lsn
FROM pg_stat_replication;

-- 備用端：確認接收程序
SELECT status, received_lsn, latest_end_lsn
FROM pg_stat_wal_receiver;

-- 備用端：確認是否仍處於 recovery，並查看回放位置
SELECT pg_is_in_recovery(), pg_last_wal_replay_lsn();

三類訊號要合併判讀：連線狀態正常、WAL 正持續接收，且回放位置依預期前進。若寫入位置持續前進、回放停滯，備用節點可能尚未套用已收到的變更；若連線中斷或接收位置落後，則要先排查網路、存取控制和複製程序。請在負載與演練條件下記錄結果，不要以未經本站實測的延遲或切換時間作放行標準。

複製槽也要列入檢查：確認槽是否存在、是否有消費者，以及 WAL 是否可能因槽而持續保留。參照複製槽檢視欄位說明核對實際狀態；若 WAL 保留量持續增加，先釐清消費端及磁碟空間風險，再考慮切換。非同步複製下，主庫已提交但未傳到備用節點的交易，不能因平時延遲看起來很低就視為安全。

用對照表判斷驗收證據是否足夠

如果目前只有「低延遲」或「可以連線」兩項，應先補上其餘證據，而不是直接放行。資料庫連線、角色狀態與應用交易結果，是不同層次的檢查。

按計畫完成提升演練與應用驗收

下列步驟用於受控的計畫內演練，不是自動故障轉移設定指南。PostgreSQL 官方備用伺服器故障切換文件說明相關行為；實際執行前，應按部署方式核對文件與操作程序。

1. 寫下演練範圍和停止條件：指定執行者、觀察者、應用驗證人，以及何種 WAL 或應用狀態不符合預期時必須停止。演練不得與未核准的生產變更混在一起。
2. 保存切換前狀態：記錄兩端的節點角色、複製連線、接收與回放位置、複製槽狀態，以及正在處理的應用交易。這份記錄是判斷演練結果的基線。
3. 由指定人員執行計畫內提升：依 PostgreSQL 18 官方流程提升備用節點，不要把手動操作描述成自動故障切換。提升後記錄角色和時間線相關變化，並確認節點是否已退出 recovery 狀態。
4. 以可回滾交易測試寫入：由應用負責人透過實際連線路徑執行可辨識、可回復的測試交易，驗證讀寫方向確實指向新主庫。只做連線測試不能驗證交易是否落在正確節點。
5. 確認應用如何恢復：觀察連線池是否重新建立連線，檢查中斷前未確認的交易如何處理，並測試重試是否可能造成重複提交。由應用團隊記錄舊主庫與新主庫的識別方式。
6. 核對下游與回退條件：若有 CDC 或邏輯訂閱，按邏輯複製故障切換文件檢查槽同步與消費端續接；新主庫啟用後，不可直接讓舊主庫以可寫角色重新加入。先依預定程序處理舊主庫，避免兩端同時接受寫入。
7. 由值班負責人簽署結果：彙整節點狀態、應用檢查、下游檢查和回退決策；任何必要項目無法驗證，就暫停上線放行。

把邏輯複製槽和資料保護分開驗收

物理流複製與邏輯複製用途不同，前者的健康狀態不能證明後者的複製槽已備妥。PostgreSQL 18 邏輯複製概覽及邏輯複製故障切換文件可用來核對適用設定。若系統使用 CDC 或邏輯訂閱，應記錄每個消費者所依賴的槽、槽在切換前後的狀態，以及消費端如何重新連線；未使用邏輯複製的系統則應寫明不適用，不要以物理複製結果代替驗收。

資料保護也要獨立簽核。主備複製可能同步錯誤操作，也可能因非同步傳送而留下尚未送達的交易；軟體 RAID 或複製都不能取代機外備份。依官方備份與還原文件制定備份及還原程序，並實際驗證備份能否還原到預期狀態。若所選伺服器沒有硬體 RAID，需自行規劃軟體 RAID 或其他複製方案，同時把備份放在主機之外。

常見問題

備用節點可登入，是否就代表已準備好提升？

不能。還須核對 WAL 接收與回放位置，並按受控程序提升後檢查節點角色與 recovery 狀態。完成提升後，還要驗證新主庫能否接受預期寫入，以及應用能否辨識新舊節點。連線成功只是其中一項證據，不足以單獨作為放行條件。

複製延遲看起來正常，為什麼仍可能有資料風險？

延遲是觀察指標，並不等同於所有已提交交易都已在備用節點回放。非同步複製可能在主庫故障時留下未送達的交易，因此切換前必須清楚界定可接受的資料缺口，並查核 WAL 位置。無法接受這種風險時，不能只靠低延遲指標推定安全。

切換後，應用測試要涵蓋什麼？

至少確認連線池能重新連線到新主庫、測試寫入落在預期節點，並釐清切換期間結果未確認的交易如何處理。還應檢查重試是否會重複提交，以及應用是否可能持續連到舊主庫。若只驗證資料庫埠可連線，仍無法證明業務寫入已恢復。

邏輯複製槽是否一定會跟著主庫切換？

不能假定自動保留或自動可用。使用 CDC 或邏輯訂閱時，應核對 PostgreSQL 18 的槽同步與故障切換條件，並從消費端驗證切換後的續接結果。若沒有使用邏輯複製，將該項標為不適用即可；物理流複製正常不代表邏輯槽也已驗收。

完成 PostgreSQL 18 主備複製驗收後，若現有雲端執行個體面臨共享資源競爭、CPU 超售、磁碟 IOPS 按方案分檔，或資源配置難以按資料庫負載調整，獨享 AMD 實體伺服器可能更適合長期運行；但它不會自動帶來主備拓撲、故障轉移或備份服務，這些仍須由團隊設計與演練。準備自建時，可先在 SFP Cloud 方案頁核對資料庫伺服器的記憶體、直連 NVMe、系統與計費週期，再依服務說明確認相關資訊；主備複製、節點隔離和機外備份仍需自行規劃與驗證。

常見問題

1. Q
   怎樣確認 PostgreSQL 18 的備用節點可以提升？

   先確認備用節點已接收並回放所需 WAL，再按演練程序提升；提升後還要確認節點已離開 recovery 狀態、能接受預期寫入，並記錄角色變更與回退責任。只看到備用節點連線正常，不足以證明它已具備安全接手條件。

2. Q
   主備複製延遲很低，是否就代表可以切換？

   不代表。延遲指標只是觀察時點的訊號，不能單獨證明最新交易已送達並回放，也不能證明應用程式能連上新主庫。非同步複製下，尚未送達備用節點的交易可能在切換時缺失；應同時核對 WAL 位置、交易結果和切換程序。

3. Q
   PostgreSQL 故障切換後，應用團隊要檢查哪些項目？

   檢查連線池是否能依預期重新連線、寫入是否確實到達新主庫，以及中斷前未確認的交易如何處理。還要驗證重試不會造成重複提交，並確認應用不會繼續把舊主庫當成可寫節點。資料庫埠可連線不等於業務已恢復。

4. Q
   切換主庫後，PostgreSQL 18 的邏輯複製槽會自動保留嗎？

   不能假設一定保留。若架構使用 CDC 或邏輯訂閱，需按照 PostgreSQL 18 的邏輯複製故障切換文件檢查槽同步設定、槽狀態及消費端續接條件；沒有使用邏輯複製的環境則應記錄為不適用，避免把物理流複製的狀態當成邏輯槽驗收結果。