pgBouncer 簡介

PostgreSQL 對於一個連線的 Session，就是一個 postgres 程序，會開一個 Unix Socket 來進行。所以若是頻繁的斷線/連線，對 PostgreSQL 來說，開銷比較大。

這也使的 PostgreSQL 一直到 9.5 版為止，對於一個處在 Idle 狀態的 Session，沒有自動逾時斷線的機制，除非手動踢掉它。直到 9.6 版，才多設計一個預設不啟用 Transaction Timeout 的參數，idle_in_transaction_session_timeout，才比較「接近」逾時中止交易的機制。這些都算是傾向保留住 Session 的設計。

（註 1：嚴格來說，idle_in_transaction_session_timeout 這個參數不是逾時斷線，而是交易卡住強制中斷）

（註 2：idle_in_transaction_session_timeout 參數可以針對 Database 或 User 進行個別設置。）

因此對於短暫交易的活動型態，在 PostgreSQL 中，便會採用 Connection Pooling 程式，咬住一些 PostgreSQL 的 Session，然後負責應付外部連線，由它進行分配。

目前 Postgres 的 Connection Pooling 中介程式的專案，以 pgBouncer 與 pgPool-2 為主流。前一陣子的維護活動比較歇緩，不過兩者都正常維護中。

上述兩者都能作為中介的連線管理程式，那兩者有哪些不同？

postgresql.conf 的 listen_addresses 到底在幹麻的？

在 PostgreSQL 的設定檔 postgresql.conf 裡面，第一項會遇到的參數就是 listen_address：

listen_addresses = 'localhost'

listen_addresses = '*'

listen_addresses = '0.0.0.0/0'

listen_addresses = 'localhost,127.0.0.1,10.140.0.2'

上面四種設置有何不同？

mongo_fdw 筆記

MongoDB 資料庫是現在知名的 NoSQL 資料庫，他讓程式開發部門「避開」與資料庫管理人員申請資料欄位的往返溝通，直接塞想要的資料存起來。聽說這在作為網頁後端資料庫很方便。

要是想要把這裡面的資料拉出來分析，就稍微不方便一些，因為他的資料都塞在一份份的 JSON 檔案裡面，要單獨取出大量某個「欄位」（JSON Key）的資料作運算，分析，就有點不方便，尤其要進行普通的關聯式資料庫的 JOIN，尤其不容易。

PostgreSQL 提供的 Foreign Data Wrapper 中，有跨接 MongoDB 的套件，叫做 mongo_fdw，是一個由 EnterpriseDB 公司維護的開源專案。這個模組能夠對 MongoDB 的 JSON 資料，取過來 PostgreSQL 裡面，當成一般表格處理，便能夠和現有資料庫的資料，進行進一步的分析。

以下將示範 mongo_fdw 的套件使用流程。

PostgreSQL 的稽核紀錄（Audit Log）功能套件 - pgAudit

稽核日誌（Audit Log）泛指用來紀錄程式活動的紀錄，在企業中很常被應用。在資料庫使用也是重要的功能。

一般要紀錄資料庫活動，可以自己用 Trigger 設計。不過在 EnterpriseDB 提供的企業版 PostgreSQL 裡面也有 edb_audit 的功能，可以不用自己設計 Trigger 就能進行紀錄。

而使用原生的 PostgreSQL，則可以用 PGAudit 這個專案。

這篇便紀錄在 CentOS7 下使用 PGAudit 套件的練習。

以下安裝流程，對於 EnterpriseDB 發行的 PostgreSQL 發行版亦適用：惟需要將相關路徑社製作些許調整。

EFM 2.1 版的 Active/Passive Switchover 切換功能

EnterpriseDB 的訂閱服務提供的資料庫高可用套件 — EDB Failover Manager（EFM），前一陣子（2016 年九月）釋出更新版，2.1 版。EFM 在先前的筆記已經有紀錄過 2.0 版的操作（之前筆記）。

在這次更新版中，引進一個重要的新功能 — 資料庫 Active/Passive Switchover 功能。這個功能，能夠將 Active 資料庫（Read-Write）/Pssive 資料庫（Read-Only）角色對調。

該功能在維護資料庫上，提供相當方便性：當有主機維護的需要，便可以依照需要，將 Master 資料庫與 Standby 資料庫對調，將 Standby 主機下線，處理完畢再上線便不會影響 Master 運作。

該功能支援 PostgreSQL 9.3 版本以上的資料庫：這是由於自此版本開始，在 recovery.conf 設定檔中，引進了 recovery_target_timeline 參數。該參數允許資料庫交易日誌的「timeline 接軌」的功能。（忘了 recovery.conf 是什麼？請參考之前 Point-in-Time Recovery 或 Streaming Replication 的筆記）