Tomu's Blog
0%

PostgreSQL Cluster 功能開發 - PostgreSQL Physical Replication

Posted on Edited on In

前陣子我們 Team 上在研究 Application layer 的 Scaled-out solution，我負責研究其中的 Database cluster package，在這邊想分享一下當時研究的技術和開發心得，也作為自己未來可以參考的筆記 XD。

另外這篇文章比較偏向一種 Replication 模型的實務架設，非常推薦閱讀 Designing Data-Intensive Applications 的第五章來更全面的認識 Replication，也希望之後能排出時間整理這本書一些章節的讀書筆記。

以 PostgreSQL 來說，每一個 Server 即為由多個 Database 共同組成的 Cluster，不過我在這篇文章中提到的 Cluster 是指藉由 PostgreSQL physical replication 同步資料的多個 PostgreSQL server。

What is Replication? Why is It Necessary?

Replication 即是將資料同步至其他 Database server 的過程。單一 Server 常受限於效能與可靠性，此時可以付出較高昂的成本 Scaled-up，不過也只能改善效能；而 Scaled-out solution 則有機會同時改善這兩個項目，以下條列包含 Replication 在內的一些相關功能:

  • Performance
    • Load distribution
    • Read/Write splitting
  • High Availability
    • Replication
    • Failover
    • Main server recovery

我們的產品使用 PostgreSQL 作為 Database，因此關於 Replication 主要就是在 Physical 和 Logical 間考量。由於產品目標主要是整個 Database 的 Repliation，不需要為了追求 Logical replication 的高自由度而承擔如這篇提到的限制，因此還是選用了 Physical replication。

至於其他條列的功能，經過一番調查，我們選擇功能較為完整的 PgPool-II 作為研究對象。

TODO: 今天這篇主要會分享 PostgreSQL 的 Physical replication，預期會再有一篇文章介紹 PgPool-II 的部分。

PostgreSQL Physical Replication

在介紹設定方式，先來介紹一下 Physical replication:

  • Single leader (Primary/Main server) and multiple follower (Replica):
    • Main server 負責處理 Write queries，再將改動的資訊同步給所有 Replica。
    • 所有 Node 都能處理 Read queries，不過如果要實現 Read/Write splitting 的話通常會分流給 Replica。
  • Delivery of WAL files: 上述的資訊傳遞是 Primary server/Replica 分別藉由 WAL sender/receiver 來傳送/接收，由於是直接傳送 WAL file，因此會有以下特性:
    • 需要 Binary level 相容性，也是被稱為 Physical 的原因 (相對而言 Logical 則是 Protocol level 相容性)。
    • Primary server/Replica 的 PostgreSQL 版本需要相同。
    • 沒有辦法做到 Parital/Conditional replication，只能以整個 Server 為單位進行 Replicate。
    • 需要確保資訊傳遞時 WAL file 仍存在。
      • Replication slot: 紀錄每個 Replica 目前接收到的最新 LSN，WAL file 需要在確認所有 Replica 都已經同步到其中的紀錄之後才可以清掉。下文的流程介紹會用這種方式。
      • WAL archive: 設定會在 WAL file 滿的時候執行的 archive_command 來產生 WAL file 的備份，要同步給 Replica 時如果發現 WAL 已經清掉了就會透過 restore_command 從 Archive 拿。

Setup Steps and Configuration

以下會大致介紹 Physical replication 的設定流程 (1 Main server and 1 Replica)，其中 Command/Configuration 僅供參考，請依環境/需求調整:

Main Server

  1. Initialize the main server: 
    1
    sudo -u postgres initdb -D /var/lib/pgsql/data
  2. Setup postgresql.conf for main server: 
    1
    2
    3
    4
    # Physical replication can run with default configuration.
    # Therefore, only connection related setting are configured here.
    listen_addresses = '*'
    # Connection permission in pg_hba.conf.
  3. Start the main server: 
    1
    sudo -u postgres pg_ctl -D /var/lib/pgsql/data start
  4. Create role for replication: 
    1
    psql -U postgres -tA -c "CREATE ROLE replication WITH LOGIN REPLICATION;"
  5. Create replication slot: 
    1
    psql -U postgres -tA -c "SELECT pg_create_physical_replication_slot('replica_1');")

Replica

  1. Create a standalone backup from primary server: 
    1
    sudo -u postgres pg_basebackup -h ${PRIMARY_IP} -U replication -D /var/lib/pgsql/data -X stream
  2. Setup postgresql.conf for replica: 
    1
    2
    primary_conninfo = 'host=${PRIMARY_IP} port=5432 user=replication application_name=replica_1'
    primary_slot_name = 'replica_1'
  3. Tell the server to start as standby mode: 
    1
    sudo -u postgres touch /var/lib/pgsql/data/standby.signal
  4. Start the replica: 
    1
    sudo -u postgres pg_ctl -D /var/lib/pgsql/data start

Monitoring

  1. Show the state of the replication:
    1
    psql -U postgres -x -c "SELECT * FROM pg_stat_replication"
  2. Check the current replication role:
    1
    psql -U postgres -c "SELECT pg_is_in_recovery()"
    • f: Primary
    • t: Replica
  3. Monitor the status of the replication slots:
    1
    psql -U postgres -c "SELECT * FROM pg_replication_slots"

More Issues about PostgreSQL Cluster

至此我們已經初步建起藉由 PostgreSQL physical replication 同步資料的 Primary-Replica servers，此後只要 Primary server 接收到 Write query 就會將改變同步至 Replica，也可以兩台 Server 處理相同的 Read query 應該要能觀察到相同的結果。

在這篇文章的最後，我們回到這篇文章開頭提及的: Scaled-out solution 追求的幾個面向繼續進行討論，也延伸討論一些 Replication 在實務上會遇到的議題。

Request Routing

雖然我們已經建立多個 PostgreSQL server 參與的 Replciation 系統，每個 Server 各自能獨立處理 request，但如何將 Request 導到這些 Server 呢？我們可以讓 Application 自行處理，不過後續無論是新增 Replica，或 Primary server 的改變，都會需要 Application 接 hook 去改動連線對象，且需要自行實作演算法來均分 Request，因此除非受限環境或 Application 的 Request 非常
單純，不然不太推薦這種做法。

比較常見的還是會在中間有一層 Proxy 來作為 Router，例如用途比較廣泛的 HAProxy，以及 For PostgreSQL 的 PgPool-II。如前文提到之後預期會有文章進一步介紹後者，因此這邊就不細談。

Network

想像中多台 Server 各自處理連線應該會對效能有很大的改善，不過在實務上需要考慮 Network 的開銷。由於這點在加入上述的 Proxy 後會更為明顯，因此一樣預期在之後的文章中再討論。

Promote Replica to Main Server

需要對其中一台 Replica 進行 Role swtich 升級為 Main server 的場合主要有兩種:

  • Scheduled switchover: 如原 Main Server 需要週期性的維護，但不想要因此中斷服務。
  • Emergency switchover: Main server failure，即 Failover。

只需在剛剛設定好的 Replica 執行以下指令即可升級:

1
sudo -u postgres pg_ctl -D /var/lib/pgsql/data -w promote

Main Server Recovery

等到原先的 Main server 維護完畢或異常修復後，需要再以 Replica 的身份去 Follow 新的 Main Server。

  • 如果原先的 Main server 是因為 Hardware 或 File system error 壞掉:

    • 只能清掉舊資料，重新以前文設定 Replica 的方式重建。

  • 如果新 Main server 出現後，原本的 Main server 仍有處理 Write query，導致兩個 Server timeline diverge:

    • 一樣可以直接清掉再重建。
    • 有機會藉由 pg_rewind 來重置差異，失敗了才整個清掉重建，參考指令如下: 
      1
      pg_rewind -D /var/lib/pgsql/data --source-server="user=postgres host=${PRIMARY_IP} port=5432 dbname=postgres"

      需注意要使用這個 Tool 的話需要滿足: the target server either has the wal_log_hints option enabled in postgresql.conf or data checksums enabled when the cluster was initialized with initdb. Neither of these are currently on by default. full_page_writes must also be set to on, but is enabled by default.

Automation

PostgreSQL 原生並不支援 Failure detection，因此上面介紹的指令都需要手動執行。不過若是手動的話就無法支援 Emergency switchover 的情境了，也因此通常還需要額外有 Watchdog 來 Monitor 各 Server 的狀態，像是 repmgr 或前文提及多次的 PgPool-II 都可以指定 Failover, recovery 等事件發生時要執行的指令。

Synchronization

PostgreSQL 的參數 synchronous_commit 在 synchronous_standby_names 不為空的時候 有多種不同設定，詳細等級可以參考官網說明。在這邊主要想探討的是除了最高等級的 remote_appy 之外，都有可能遇到的 Replication lag 現象，即同時間發給不同台 Server 的 Read request 可能得到不同的結果。

前文因為想要盡量簡化設定流程，因此這項參數維持預設值。

這可能導致 Application 行為有微妙的異常，例如對話內容時有時無、同時間和其他人看到的資訊不同等等。這些異常是 Distributed storage 常見的限制，有些在非同步的情況難以改善，有些則可能透過 Application 或 Request router 特別處理來克服，例如讓來自同個 User 的 Request 都被導到固定的 Server。

這部分在 DDIA 的第五章中有相關的介紹，像一開始提到的希望之後能排出時間來整理筆記分享。