把 Pro*C 移到 EDB 9.5 企業版執行 — ECPGPlus 操作筆記

ECPG 是 Postgres 提供的 C 的開發輔助函式庫，提供所謂 Embedded SQL in C 的功能，類似 Oracle Pro*C 一樣的功能。兩者在使用上提供的 API 差異並不大，比較顯著的差別就在所使用的 SQL 指令，Postgres ECPG 和 Oracle Pro*C 步太能直接通用。

EnterpriseDB 則基於 Postgres ECPG 進一步提供移轉 Oracle Pro*C 到 Postgres 的額外功能，叫做 ECPGPlus。ECPGPlus 針對 EnterpriseDB 提供的企業版資料庫所具備的 Oracle 相容特性，提供相對應的 Embedded SQL in C 轉換，以便以最大幅度直接相容 Oracle Pro*C 的程式碼，達到系統移轉時降低改動幅度的目的。

以下自 EDB 的 PostgreSQL 企業版編譯一個 Oracle 的 Pro*C 程式碼，示範 ECPGPlus 的使用。

Logical Replication Slot on PostgreSQL 9.4 觀察 WAL 交易

這是在 PostgreSQL 9.4 推出的功能，稱作 Logical Decoding。也就是解析交易日誌的功能。發展此功能的目標是為了達成 Log-Based Replication 的功能，以便於日後達成 Master-Master Replication 或是負荷比較小的 Row­level Filtering Replication。直到 2016 年底，該功能還在發展當中（稱作 Bi-Directional replication，BDR）。不過這個功能的推出，也使的些許基於 PostgreSQL 的 Active-Active 實作方案推出，像是 EnterpriseDB 的 EDB Replication Server 的 Multi-Master Replication，或是社群的 pglogical 專案。

Logical Decoding 的使用，也是透過 Replication Slot 來進行，只是這裡的 Replication Slot 不同於在 Streaming Replication 使用的 (Physical) Replication Slot，而是另一類型，叫做 Logical Replication Slot。

以下用 9.4 版的 PostgreSQL作簡易的示範。看看 Logical Decoding 的功能。

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 的筆記）