一文弄懂PostgreSQL流複製

• 2019 年 12 月 18 日
• 筆記

Postgresql9開始支援流複製（stream replication），作為pg原生的複製技術，有著很好的性能。本文從幾個方面全面介紹pg的流複製技術。

主從部署

Postgresql主從部署比較簡單，首先你需要安裝好主從兩個實例，然後進行主備庫配置，主要配置可以參考如下步驟：

主庫配置：  ①創建角色用於同步：  create role replica login replication encrypted password 'replica';  ②增加pg_hba配置：  host     all     all     192.168.1.2/32    trust  host   replication  replica    192.168.1.2/32(從庫ip)  md5  ③配置postgresql.conf  listen_addresses='*'  archive_mode = on  archive_command = 'test ! -f /postgresarch/%f && cp %p /postgresarch/%f'  synchronous_standby_names='FIRST 1 (s1,s2,s3)'  max_connections從庫要大於主庫  ④重啟伺服器。    從庫配置：  ①基礎備份：  刪除從庫data目錄  pg_basebackup -h 192.168.1.1 -U replica -D /postgresdata/pginst1/ -X stream -P  ②配置從庫數據目錄recovery.conf  standby_mode = 'on'  primary_conninfo = 'host=192.168.1.1 port=5432 user=replica password=replica application_name=s1'  recovery_target_timeline = 'latest'

同步流程

下面這個圖描述了postgresql主從流複製的流程。

主要分為以下幾個流程：

①主備資料庫啟動，備庫啟動walreceiver進程，wal進程向主庫發送連接請求。

②主庫收到連接請求後啟動walsender進程，並與walreceiver進程建立tcp連接。

③備庫walreceiver進程發送最新的wal lsn給主庫。

④主庫進行lsn對比，定期向備庫發送心跳資訊來確認備庫可用性，並且將沒有傳遞的wal日誌進行發送，同時調用SyncRepWaitForLSN()函數來獲取鎖存器，並且等待備庫響應，鎖存器的釋放時機和主備同步模式的選擇有關，同步模式這塊內容下面再說。

④備庫調用作業系統write()函數將wal寫入快取，然後調用作業系統fsync()函數將wal刷新到磁碟，然後進行wal回放。同時備庫向主庫返回ack資訊，ack資訊中包含write_lsn、flush_lsn、replay_lsn，這些資訊會發送給主庫，用以告知主庫當前wal日誌在備庫的應用位置及狀態，相關位置資訊可以通過pg_stat_replication視圖查看。

⑤如果啟用了hot_standby_feedback參數，備庫會定期向主庫發送xmin資訊，用以保證主庫不會vacuum掉備庫需要的元組資訊。關於該參數的詳細解釋，可以參考我的上一篇文章。

同步模式

Postgresql資料庫提供了五種同步模式，相比商業資料庫還是很強大的。同步模式主要由synchronous_commit參數控制。下面簡單介紹一下五種同步模式的區別。下面這張圖很清晰地描述了流複製的幾種模式：

off：對於本機wal不用寫到磁碟就可以提交，是非同步模式，存在數據丟失風險。

local：不管有沒有備庫只需要保證本機的wal日誌刷到磁碟就行。

remote_write：等待主庫日誌刷新到磁碟，同時日誌傳遞到備庫的作業系統快取中，不需要刷盤就能提交，不能避免作業系統崩潰。

on：如果沒有備庫，表示wal日誌需要刷新到本地的磁碟中才能提交，如果存在同步備庫時（synchronous_standby_name不為空），需要等待遠程備庫也刷新到磁碟主庫才能提交。

remote_apply：pg高版本才出來的功能，備庫刷盤並且回放成功，事務被標記為可見，用於做負載均衡，讀寫分離等。

相關參數

wal_level:

wal日誌級別，這個參數決定了有多少資訊寫入wal日誌，默認是replica，這種模式支援複製和wal歸檔，同時支援備庫只讀查詢。

minimal：除了實例crash恢復需要的記錄，其他不記錄，比如CREATE TABLE AS，CREATE INDEX，CLUSTER，COPY可以跳過，該模式記錄的日誌資訊不足以支援wal歸檔和流複製。

logic：在replica的基礎上增加一些資訊以支援邏輯解碼，該模式會增大wal日誌的數量，尤其是大量的update，delete操作的庫。

在9.6之前還有archive和hot_standby模式，映射到現在的replica模式。

synchronous_commit：

五種同步模式選擇，前面已經說過。關於生產環境配置我也做過測試，如果單並發插入remote_write和on性能差距十倍，但是高並發的情況下，差距不大，所以刷盤其實是比較消耗性能的操作，生產環境中建議選用remote_write。

synchronous_standby_names：

在主庫上配置，備機的複製列表。有下面幾種種方式（s1，s2，s3代表備機的application_name，配置在recovery.conf中）：

synchronous_standby_names='s1' 代表s1備機返回就可以提交。

synchronous_standby_names='FIRST 2 (s1,s2,s3)' 代表s1，s2，s3三個備機中前兩個s1和s2返回主庫就可以提交。

synchronous_standby_names='ANY 2 (s1,s2,s3)' 代表s1，s2，s3三個備機中任意兩個備機返回主庫就可以提交，基於quorum協議。

synchronous_standby_names='*' *代表匹配任意主機，也就是任意主機返回就可以提交。

vacuum_defer_cleanup_age:

指定vacuum延遲清理的事務數，即vacuum和vacuum full操作不會立即清理剛剛被刪除元組。至於為什麼要延遲清理，我的上一篇文章有講到。

max_wal_senders:

指定wal日誌發送進程的最大並發連接數。設為0表示禁用replication，參數必須小於max_connections-superuser_reserved_connections

checkpoint_segments(9.5之前):

自動wal checkpoint間隔時間段內最多產生的wal數量。9.5之前才有這個參數，9.5後廢除了這個參數，新增了max_wal_size，改為通過max_wal_size和checkpoint_completion_target共同控制，計算公式為：checkpoint_segments=max_wal_size/(2+checkpoint_completion_target)，所以checkpoint_segments大概為wal_max_size的1/3到1/2。

wal_keep_segments:

設置「pg_xlog」目錄下保留事務日誌文件的最小數目用於流複製，如果備機停機時間過長導致主庫xlog被刪除，那麼主備關係會失敗，但是如果開啟了歸檔，備機可以從歸檔日誌中繼續恢復。

min_wal_size:

只要wal日誌目錄使用空間小於該值，那麼舊的wal日誌就會循環使用而不是進行刪除。這個參數是為了確保足夠的wal空間預留給突發情況，比如大的跑批操作。

max_standby_archive_delay、max_standby_streaming_delay、hot_standby_feedback：

控制備機查詢衝突的參數，上一篇文章說過，這裡不再贅述。

wal_receiver_status_interval：

備機向主機發送相關複製資訊的最小頻率，包含相關lsn資訊，可以通過pg_stat_replication視圖查看。

wal_recevier_timeout、wal_recevier_retry_interval：

控制連接超時時間，很好理解，不再贅述。

我們可以通過pg_stat_replication，pg_stat_wal_receiver，pg_current_wal_lsn，pg_last_wal_receive_lsn這幾個視圖查看複製的狀態資訊。

總體來說流複製的內容比較簡單，本文只是從基礎知識層面介紹了流複製的原理與簡單配置。好吧，加油吧。