PostgreSQL 之間可以用 Streaming Replication 進行主從資料庫之間的資料同步。並且能夠使用 pg_ctl 指令手動將備份資料庫切換成主要服務資料庫；或是使用 trigger 設定主機異常時的自動切換。PostgreSQL 的高可用性架構（ High Availability, HA）就是使用這些功能去組成的。
提供企業版 PostgreSQL 服務的公司 EnterpriseDB 提供一個能夠管理 PostgreSQL 資料庫 HA 的工具，EDB Failover Manager（EFM）。該工具能夠監控 PostgreSQL 資料庫間的狀況，並且在主要資料庫主機發生異常時作自動切換，並有通知管理者的功能。
2016年3月15日 星期二
2016年3月14日 星期一
PostgreSQL 的 Physical Replication Slot 功能
在 PostgreSQL 9.4 中，引進了用來防止 streaming replication 中斷後就無法再次建立 streaming replication 問題的功能：Replication Slot。
Replication Slot 有兩種：Physical Replication Slot 與 Logical Replication Slot。在此使用的是 Physical Replication Slot，是不涉及解析 WAL 交易日誌內容的 Replication Slot 功能。
一般使用 streaming replication，必須要設定 wal_keep_segment 選項，才能避免在 standby 不小心備份不及（例如，某時段的 primary 交易量太大，交易日誌產生太快），造成 standby 還沒抓交易日誌，就被 primary 洗掉了。如果交易日誌被洗掉，streaming replication 就會中斷，並且無法再繼續進行，這樣就得重設立 streaming replication 了。
現在使用 replication slot， primary 就會知道目前 standby 同步的狀況，primary 就不會把還沒同步完畢的交易日誌洗掉，等待 standby 抓取完交易日誌才刪去舊的日誌。
Replication Slot 有兩種：Physical Replication Slot 與 Logical Replication Slot。在此使用的是 Physical Replication Slot，是不涉及解析 WAL 交易日誌內容的 Replication Slot 功能。
一般使用 streaming replication，必須要設定 wal_keep_segment 選項，才能避免在 standby 不小心備份不及（例如，某時段的 primary 交易量太大，交易日誌產生太快），造成 standby 還沒抓交易日誌，就被 primary 洗掉了。如果交易日誌被洗掉，streaming replication 就會中斷，並且無法再繼續進行，這樣就得重設立 streaming replication 了。
現在使用 replication slot， primary 就會知道目前 standby 同步的狀況，primary 就不會把還沒同步完畢的交易日誌洗掉，等待 standby 抓取完交易日誌才刪去舊的日誌。
EDB Failover Manager 使用筆記－II：測試 EFM Cluster 高可用性
接續前一篇設置起 EFM Cluster 之後，接著就是要真的看看 EFM CLuster 在發生資料庫異常時表現的行為了。
首先，再確認一下目前 Cluster 的狀態：
最後一行告訴我們，此時的 Cluster 能夠拿來作資料庫切換。
要模擬 primary 主機有異常，最簡單的方式就是強制中止 primary 上的 PostgreSQL 程序，或者也可以直接關掉 primary 主機的 VM。
關掉 primary 主機之後，EFM Cluster 便無法再檢查到 primary 主機上的 EFM agent 與 資料庫，依照在設定檔內所設定的檢查間隔，local.period、 local.timeout、local.timeout.final三個設定，檢查完畢確認 Primary 主機無法服務之後，便會開始切換過程：
到這裡，原先的 Standby 主機已經接替了下線的 primary 主機的工作，並且 EFM Cluster 也寄信告訴你資料庫發生異常了：
當收到信之後，就準備要開始重新啟動整個備份了：
再恢復整個資料庫設置的方式，就是
(1) 以現在的主機作為新的 primary（上面的 192.168.56.103），而已經下線的機器啟動成為新的 standby（上面的 192.168.56.102），建立之間的 streaming replication
(2) 再啟動上的 EFM agent：
這樣，整個 EFM Cluster 便恢復了。
最後，當試用期過了之後，要再啟動 EFM Cluster 就會收到如下訊息：
告訴你這次的遊戲結束了，請再投幣囉
首先，再確認一下目前 Cluster 的狀態：
[root]# /usr/efm-2.0/bin/efm cluster-status efm Cluster Status: efm Agent Type Address Agent DB Info -------------------------------------------------------------- Master 192.168.57.102 UP UP Witness 192.168.57.101 UP N/A Standby 192.168.57.103 UP UP Allowed node host list: 192.168.57.102 192.168.57.103 192.168.57.101 Standby priority host list: 192.168.57.103 Promote Status: DB Type Address XLog Loc Info -------------------------------------------------------------- Master 192.168.57.102 0/F01A4B8 Standby 192.168.57.103 0/F01A4B8 Standby database(s) in sync with master. It is safe to promote.
最後一行告訴我們，此時的 Cluster 能夠拿來作資料庫切換。
要模擬 primary 主機有異常，最簡單的方式就是強制中止 primary 上的 PostgreSQL 程序，或者也可以直接關掉 primary 主機的 VM。
關掉 primary 主機之後，EFM Cluster 便無法再檢查到 primary 主機上的 EFM agent 與 資料庫，依照在設定檔內所設定的檢查間隔，local.period、 local.timeout、local.timeout.final三個設定，檢查完畢確認 Primary 主機無法服務之後，便會開始切換過程：
[root]# /usr/efm-2.0/bin/efm cluster-status efm
Cluster Status: efm
Agent Type Address Agent DB Info
--------------------------------------------------------------
Idle 192.168.56.102 UP UNKNOWN
Promoting 192.168.56.103 UP UP
Witness 192.168.56.101 UP N/A
Allowed node host list:
192.168.56.102 192.168.56.103 192.168.56.101
Standby priority host list:
192.168.56.103
Promote Status:
DB Type Address XLog Loc Info
--------------------------------------------------------------
Master 192.168.56.103 0/D0483C8
No standby databases were found.
Idle Node Status (idle nodes ignored in XLog location comparisons):
Address XLog Loc Info
--------------------------------------------------------------
192.168.56.102 0/D0482C0 DB is not in recovery.
到這裡，原先的 Standby 主機已經接替了下線的 primary 主機的工作，並且 EFM Cluster 也寄信告訴你資料庫發生異常了：
當收到信之後，就準備要開始重新啟動整個備份了：
再恢復整個資料庫設置的方式，就是
(1) 以現在的主機作為新的 primary（上面的 192.168.56.103），而已經下線的機器啟動成為新的 standby（上面的 192.168.56.102），建立之間的 streaming replication
(2) 再啟動上的 EFM agent：
[root@old_primary]# efm resume efm Resume command successful on local agent.
這樣，整個 EFM Cluster 便恢復了。
最後，當試用期過了之後，要再啟動 EFM Cluster 就會收到如下訊息：
告訴你這次的遊戲結束了，請再投幣囉
2016年3月10日 星期四
在同一台主機上開多個 PostgreSQL 程序
PostgreSQL 的使用方式是先初始化一個資料庫並且啟動它，就會啟動程序，並去監聽 port。一個 Postgres 程序，是用他開啟的資料庫 instance 來區分的。
在同一台主機上，也就能夠開很多個 PostgreSQL，而且也不見得一定要由 PostgreSQL 專有帳戶 postgres 來開一個資料庫 instance。
方式只要初始化一個新的資料庫就有了。
接連執行上面兩次指令，就產生出兩個資料夾，這兩個個別就代表一個資料庫了。
接者啟動時，指定不同 port 來開，就會跑兩個出來 Postgres 了
附上一張截圖
要登入的話，記得剛初始化的 instance 裡面預設能連線的只有 postgres database，登入時要記得指定資料庫為 postgres 才行 ～
在同一台主機上，也就能夠開很多個 PostgreSQL，而且也不見得一定要由 PostgreSQL 專有帳戶 postgres 來開一個資料庫 instance。
方式只要初始化一個新的資料庫就有了。
postgres $ initdb -D /var/lib/pgsql/9.5/data/ --locale=zh_TW.UTF-8 -A md5 -W cchsu $ initdb -D /home/cchsu/pgsql/9.5/ --locale=zh_TW.UTF-8 -A md5 -W
接連執行上面兩次指令，就產生出兩個資料夾，這兩個個別就代表一個資料庫了。
接者啟動時，指定不同 port 來開，就會跑兩個出來 Postgres 了
postgres $ pg_ctl -D /var/lib/pgsql/9.5/data/ -o "-p 5432" -l logfile start cchsu $ pg_ctl -D /home/cchsu/pgsql/9.5/ -o "-p 5433" -l logfile start
附上一張截圖
要登入的話，記得剛初始化的 instance 裡面預設能連線的只有 postgres database，登入時要記得指定資料庫為 postgres 才行 ～
Streaming Replication 筆記
串流複寫（ Streaming Replication ）是 PostgreSQL 的資料複寫（ Replication ）的功能。這功能是用來備份資料到別台機器上，並且在主要資料庫所在的主機發生異常時，利用備份機頂替主要資料庫。
由於 PostgreSQL 的交易日誌設計是和所運行的作業系統及硬體架構有關，所以要進行 Streaming Replication 規劃時，必須要兩端的作業系統一致（如：Linux 對 Linux、Windows 對 Windows）；以及硬體架構也要一致才行（例如：32 位元和 64 位元之間就不能用 Streaming Replication） 。
要作實際演練的話，有兩種簡單的環境設置可以選擇：
1. 在同一台機器上開兩個 PostgreSQL instance，兩個 instance 之間進行備份；
2. 或是開兩台虛擬機器（ VM ），兩個 VM 間進行備份。
這兩者的操作流程是一樣的。
[20191205 Update] 已經針對 PostgreSQL 12 重新演練一次了～
由於 PostgreSQL 的交易日誌設計是和所運行的作業系統及硬體架構有關，所以要進行 Streaming Replication 規劃時，必須要兩端的作業系統一致（如：Linux 對 Linux、Windows 對 Windows）；以及硬體架構也要一致才行（例如：32 位元和 64 位元之間就不能用 Streaming Replication） 。
要作實際演練的話，有兩種簡單的環境設置可以選擇：
1. 在同一台機器上開兩個 PostgreSQL instance，兩個 instance 之間進行備份；
2. 或是開兩台虛擬機器（ VM ），兩個 VM 間進行備份。
這兩者的操作流程是一樣的。
[20191205 Update] 已經針對 PostgreSQL 12 重新演練一次了～
訂閱：
文章 (Atom)