前言

在 PostgreSQL 的生態圈裡，如果要問「生產環境最常見的兩個配套工具是什麼？」
答案大概會是：

1. pgBackRest：處理備份與還原（避免資料遺失）
   • 連結： https://pgbackrest.org/
   • 官網寫「pgBackRest is a reliable backup and restore solution for PostgreSQL that seamlessly scales up to the largest databases and workloads.」
2. pgBouncer：處理連線池化（避免效能崩潰）
   • 連結： https://www.pgbouncer.org/
   • 官網寫的標題是 「Lightweight connection pooler for PostgreSQL」

這兩個專案就像是 左右護法，一個負責「保命」，一個負責「穩定」。
今天我們就來看看它們的歷史、功能，以及社群與商業支援現況。

pgBackRest：從 Bash 到企業級備份工具

歷史

• 最早期的 PostgreSQL 備份，大多依賴 pg_dump 或自寫 Bash script。
• 但隨著資料庫變大（數百 GB ~ TB），這種方式效率低下，還原時間長。
• 2013 年開始，開發者 David Steele 開始設計一套新工具，專注於效能與可靠性。
• 2015 年，pgBackRest 正式開源，並逐漸取代老牌的 pg_basebackup 作為「實務生產級標準備份方案」。
• 採用 Apache License 2.0，是社群獨立維護的專案，不隸屬於某個公司。

  和前一篇介紹的 Crunchy Data 功能是差不多的，不過 Crunchy Data 是一家專注 PostgreSQL 企業級解決方案的公司。
  Crunchy Data 將 pgBackRest 整合到 Postgres Operator (PGO)，所以不用另外裝喔！！

• EDB (EnterpriseDB，可以理解成商業版的 PostgreSQL) 也把 pgBackRest 當成標準備份工具。
• 功能的部分，可以參考前一篇 【Day 25】 叢集裡面裝 PostgreSQL 最佳選擇 - Crunchy Data 就不重複寫了。

pgBouncer：小而美的輕量級連線池

歷史

• PostgreSQL 本身每個連線都會啟動一個 OS process，在高併發下容易拖垮效能。
• 2007 年，開發者 Marko Kreen（同時也是 libevent 貢獻者）寫出了 pgBouncer。
• 設計哲學就是：極輕量、極快、佔資源極少。

功能

1. 連線池化 (Connection Pooling)，支援多種 Pooling 方式：
   • Session pooling / 連線池
     • 與各種場景相容性最高。
     • 當客戶端建立連線時，會分配一個伺服器端的連線，並在整個連線期間持續使用。
     • 當客戶端斷線後，該伺服器連線會被放回連線池中。
     • 此模式支援 PostgreSQL 的所有功能。

     原文： Most polite method. When a client connects, a server connection will be assigned to it for the whole duration it stays connected. When the client disconnects, the server connection will be put back into pool. This mode supports all PostgreSQL features.

   • Transaction Pooling
     • 伺服器端連線只會在一個交易期間分配給客戶端。
     • 當 PgBouncer 偵測到交易結束後，該伺服器連線就會被放回連線池。
     • 此模式會破壞一些基於 session 的 PostgreSQL 功能。
     • 只有在應用程式能配合、不使用這些不相容功能時，才能使用這種模式。
     • 下面的表格會列出的不相容功能。
       
   • Statement pooling
     • 限制最多的 Pooling 方法。
     • 是基於 Transaction pooling 基礎上的變形
     • 不允許多語句交易 (Multi-statement Transactions)。
     • 此模式強制客戶端使用「自動提交 (autocommit)」模式，主要針對 PL/Proxy 使用情境而設計。
2. 減少連線建立開銷（重複利用後端連線）
3. 降低資料庫資源耗用
4. 簡單部署：只要改 connection string，把 DB 指向 pgBouncer 就能生效

開源 / 商業

開源版本

• BSD License，社群維護良好，程式碼量小，穩定成熟。

商業支援

• EDB 提供加強版支援，整合到其 EDB Postgres Advanced Server。
• Crunchy Data 在其 Kubernetes Operator 中，也支援用 pgBouncer 做連線代理。

結論

• 將 PostgreSQL 放到容器叢集中，面臨的幾個問題，例如有狀態的議題 Stateful，衍生出的備份與橫向擴充。
• 連線的機制，在透過 pgBouncer 確實可以將讀取的流量分攤下去了。 但他並不是用來解決「平行寫入」的議題。 而且 PostgreSQL 並不支援 Multiple Writer。
  • PostgreSQL 的 WAL (Write-Ahead Log) 與 一致性模型，是為了單一 Primary 節點設計的。
  • 官方支援的 Streaming Replication = 1 個 Primary (可寫) + 多個 Replicas (唯讀)。