專屬伺服器上的 PostgreSQL 串流複寫指南

PostgreSQL 串流複寫會在交易寫入時，把預寫式日誌（WAL）記錄由主資料庫伺服器傳送到一個或多個備用伺服器。這種架構可支援讀取擴展、報表、維護時段及更快復原，而不必改變應用程式的資料模型。

在專屬伺服器上，團隊可以控制 CPU、記憶體、儲存、網絡路徑及作業系統設定，令複寫更容易按實際負載規劃；但這並不代表可以忽略 WAL 保留、複寫延遲、故障切換、備份及復原測試。本指南整理正式部署前的主要規劃重點。

PostgreSQL 串流複寫如何運作

主伺服器會把每項已提交的變更寫入 WAL。備用伺服器透過複寫用戶連線，從 WAL sender 接收記錄，在本機寫入並重播。備用伺服器在追上進度前，可以維持唯讀狀態。

• PostgreSQL 串流複寫屬於資料庫層面的設計，而託管層則會影響節點之間能否穩定通訊。Dataplugs 的即時協作平台託管基礎設施文章亦把狀態一致性、備份設計、複寫及故障切換視為基礎設施問題。
• 主伺服器與備用伺服器角色清晰，並應記錄在操作文件內
• WAL sender、WAL receiver 及重播程序負責傳送及套用變更
• 非同步複寫會在備用伺服器重播前確認主伺服器的寫入
• 同步複寫會等待一個或多個備用伺服器後才確認提交
• 實體複寫複製整個叢集；邏輯複寫則按資料庫物件選擇變更

同步與非同步複寫的選擇

非同步複寫通常可保持較低的寫入延遲，因為主伺服器不必等待備用伺服器。代價是發生故障時，最新交易可能尚未在備用伺服器上可用。同步複寫可減少這種資料差距，但每項提交都會取決於所設定的備用伺服器及網絡路徑。

• 合適模式應按復原點目標（RPO）、復原時間目標（RTO）及伺服器距離決定。Dataplugs 的專屬託管的備份與災難復原貼士亦提醒，複寫、備份及故障切換程序各自處理不同的復原問題。
• 寫入延遲及讀取擴展較重要時，可使用非同步備用伺服器
• 不能接受已確認交易遺失時，才考慮同步複寫
• 多個備用伺服器參與確認時，可按需要使用仲裁設定
• 把同步節點放在不同地點前，先量度來回延遲
• 同時保留獨立的備份及時間點復原路徑

PostgreSQL 複本的專屬伺服器容量規劃

主伺服器及備用伺服器的規模，應按寫入量、資料集、查詢組合、檢查點活動及復原目標計算，而不能只看連線數量。能應付日常讀取的備用伺服器，在寫入高峰時仍可能無法及時重播大量 WAL。

• 儲存延遲往往會先在 WAL 刷新、檢查點及重播過程中反映。Dataplugs 的季節性網站流量高峰的資源分配優化文章說明應以量度所得的 CPU、記憶體、儲存及頻寬需求規劃專屬基礎設施，而不是只按平均值估算。
• 為查詢、WAL 壓縮、vacuum 及重播預留 CPU 量
• 為 shared_buffers、work_mem、連線池及檔案系統快取分配記憶體
• 資料檔案、WAL 及暫存工作使用低延遲 NVMe 儲存
• 頻寬需應付 WAL、讀取流量、備份及重建
• 為故障切換、重建索引、vacuum 及複本追趕保留容量餘裕

Tip: 應使用最大而合理的資料集及 WAL 高峰測試故障切換和複本重建，因為平均使用率可能掩蓋復原瓶頸。

WAL 保留、複寫槽及延遲管理

• WAL 必須保留到每個備用伺服器取得所需記錄為止。wal_keep_size、複寫槽及 WAL 封存處理的是不同層面的保留要求。複寫槽可保護斷線用戶仍需的 WAL，但長期無人使用的槽可能令 pg_wal 持續佔用磁碟。
• 監察複寫延遲時，不只要看數值，也要找出成因。pg_stat_replication 可在主伺服器顯示傳送及接收進度，備用伺服器的檢視則可顯示接收狀態及重播位置。告警應涵蓋延遲時間、延遲量、複寫槽增長及磁碟餘量。
• 按最長預計斷線或維護時段設定 WAL 保留量
• 檢查使用者後才限制或移除沒有用途的複寫槽
• 追蹤 sent、write、flush 及 replay 的 LSN 位置
• 在 WAL 或資料磁碟接近容量上限前發出告警
• 記錄觸發流量切換或故障切換決定的延遲門檻

故障切換、提升及應用程式路由

串流複寫負責傳送資料，但不會自行決定何時把備用伺服器提升為主伺服器。提升需要操作員或協調工具、隔離舊主伺服器的方法，以及把應用程式流量轉移到新主伺服器的受控流程。

• 專屬伺服器架構應測試完整流程：偵測故障、提升正確節點、更新寫入端點、重建連線池，並確認沒有兩個同時寫入的 split-brain 主伺服器。故障回復及複本重建步驟也應寫在同一份操作手冊。
• 清楚定義誰或甚麼工具有權提升備用伺服器
• 允許新寫入者運作前，先隔離或圍堵舊主伺服器
• 使用穩定的應用程式端點、代理或受控 DNS 變更
• 以退避方式重連，避免故障後出現連線風暴
• 記錄故障回復、時間線歷史及事故後驗證步驟

備份及時間點復原

備用伺服器不是備份。誤刪資料、錯誤遷移及已損壞的寫入都可能同步到所有複本。應使用基礎備份配合持續 WAL 封存，讓團隊可以在事故發生前的指定時間點復原。

• 復原副本應存放在主伺服器以外，並在獨立容量上定期測試還原。復原計劃需要寫明保留期、加密、存取控制、還原次序，以及硬件或軟件故障後重建備用伺服器所需時間。
• 定期建立並驗證基礎備份
• 持續封存 WAL，並監察封存失敗
• 以受保護的方式保留伺服器外或跨站副本
• 用時間點復原處理操作員或應用程式錯誤
• 按訂定的 RPO 及 RTO 進行還原及復原演練

總結

在專屬伺服器上使用串流複寫，可以建立清晰的主備架構、可預測的資源分配，以及支援讀取擴展和復原的基礎。要令設計可靠，必須一併定義 RPO/RTO、WAL 保留、故障切換權限、備份、保安及監察。

如工作負載需要 PostgreSQL 及相關服務的可預測單租戶容量，Dataplugs 提供具備可配置 CPU、記憶體、儲存及網絡選項的專屬伺服器方案。

如需了解更多，歡迎瀏覽 Dataplugs 或聯絡 sales@dataplugs.com。