EnterpriseDB 的訂閱服務提供的資料庫高可用套件 — EDB Failover Manager（EFM），前一陣子（2016 年九月）釋出更新版，2.1 版。EFM 在先前的筆記已經有紀錄過 2.0 版的操作（之前筆記）。
在這次更新版中，引進一個重要的新功能 — 資料庫 Active/Passive Switchover 功能。這個功能，能夠將 Active 資料庫（Read-Write）/Pssive 資料庫（Read-Only）角色對調。
該功能在維護資料庫上，提供相當方便性：當有主機維護的需要，便可以依照需要，將 Master 資料庫與 Standby 資料庫對調，將 Standby 主機下線，處理完畢再上線便不會影響 Master 運作。
所謂 timeline，可以當成是 PostgreSQL 資料庫管理資料庫 Streaming Replication 同步的一個設計。在這個設計中，一個資料庫的交易活動有他的時間軸標記，這個標記表現在 WAL 交易日誌檔案名稱上，當我們開啟 pg_xlog/ 目錄，就可以看到許多 WAL 檔案。檔案名稱大多形同 00000001000000000000001E 。而紅色部份便是這個資料庫的 timeline。進行 Streaming Replication 的 Standby 資料庫，他會與 Master 資料庫的交易處在同一個時間軸上運作，也就是說，兩者會有一樣的 timeline。
當 Standby 資料庫進行 Promote 之後，它便會和 Primary 資料庫的同步「脫鉤」，成為獨立運作的資料庫。此時 Standby 資料庫的 timeline 會跳躍到下一個時間軸，與原先所跟隨的 Primary 資料庫交易日誌時間軸分支出來。延續上方例子，這時已經脫鉤的 Standby 資料庫，他的 WAL 就會形同 000000020000000000000023，與原先 Primary 資料庫的裡面最新的 WAL， 000000010000000000000022 兩者的 timeline 不再相同。
recovery_target_timeline 這個參數，便能夠把「舊的 Primary 資料庫」（帶有舊的 timeline 00000001），繼續接軌「新的 Primary 資料庫/原先的 Standby 資料庫」（帶有新的 timeline 00000002）進行同步，進而使「舊的 Primary 資料庫」成為一個「新的 Standby 資料庫」。
當然，這個「接軌」是有條件的：「舊的 Primary 資料庫」在 Promote 發生之後，「舊的 Primary 資料庫」便要停止他的活動，這樣一來，兩資料庫之間才不會有分歧問題，此時的 recovery_target_timeline 才能接軌。此外，WAL 裡面會有相關 Checksum 檢查，所以不會有辦法亂拿的資料庫 WAL 檔案就能夠餵進去資料庫～
如果「舊的 Primary 資料庫」有他的活動的話還有可能重新接軌嗎？這時候，我們就需要使用 pg_rewind 工具，將雙方差異重新比對之後，就可以再次接軌（注意，要使用 pg_rewind 工具， postgresql.conf 裡面參數要作相關設定才行！參考之前的筆記）。
以上簡單解釋完畢。接著開始進行操作示範。
因為 EFM 2.0 與 2.1 的設定上差異不大，所以在此延續先前 EFM 2.0 的操作筆記，示範如進行相關設置。此處我只將需要變更的部份示範出來
standby_mode = 'on' primary_conninfo = 'host=127.0.0.1 port=5432 user=strmrepl' recovery_target_timeline = 'latest' trigger_file = '/tmp/pg_failover.trigger'
在此 recovery_target_timeline 設置的值為 'latest'，表示我們後續要「接軌」新的 timeline。
接著，EFM 2.1 版除了多一些管理 HA Cluster 架構的參數之外，其他的設置方式與 2.0 版是一樣的。
DB 上面的 /etc/efm-2.1/efm.properties
db.user=enterprisedb
db.password.encrypted=<encrypted_password>
db.port=5444
db.database=edb
db.service.owner=enterprisedb
db.service.name=ppas-9.5
db.bin=/opt/PostgresPlus/9.5AS/bin
db.recovery.conf.dir=/var/lib/ppas/9.5AS/data
user.email=<email_addr1> <email_addr2> <email_addr3>
bind.address=<ip_addr>:7800
admin.port=7801
is.witness=false
local.period=10
local.timeout=60
local.timeout.final=10
pingServerIp=8.8.8.8
virtualIp=
virtualIp.interface=
virtualIp.netmask=
script.fence=
script.post.promotion=
script.db.failure=
Witness 上面的 /etc/efm-2.1/efm.properties
db.user=enterprisedb
db.password.encrypted=<encrypted_password>
db.port=5444
db.database=edb
db.service.owner=enterprisedb
db.service.name=
db.bin=
db.recovery.conf.dir=
user.email=<email_addr1> <email_addr2> <email_addr3>
bind.address=<ip_addr>:7800
admin.port=7801
is.witness=true
local.period=10
local.timeout=60
local.timeout.final=10
pingServerIp=8.8.8.8
virtualIp=
virtualIp.interface=
virtualIp.netmask=
script.fence=
script.post.promotion=
script.db.failure=
啟動程序：
Primary DB
[root@edb1 ~]# service efm-2.1 start [root@edb1 ~]# /usr/efm-2.1/bin/efm allow-node efm <edb2-ip> [root@edb1 ~]# /usr/efm-2.1/bin/efm allow-node efm <efm_wit-ip>這裡提醒一點，在 EFM 2.0 中，引介新的 Node 執行的叫做 efm add-node，在 EFM 2.1 則更動為 efm allow-node。
Standby DB
[root@edb2 ~]# echo "<edb1-bind-addr>" >> /etc/efm-2.1/efm.nodes [root@edb2 ~]# service efm-2.1 start
HA Witness Node
[root@efm_wit ~]# echo "<edb1-bind-addr>" >> /etc/efm-2.1/efm.nodes [root@efm_wit ~]# echo "<edb2-bind-addr>" >> /etc/efm-2.1/efm.nodes [root@efm_wit ~]# service efm-2.1 start
等到 Streaming Replication 與 EFM 設置完畢之後，就來進行 Switchover 功能的驗證。
Switchover 功能，只要 Primary/Standby 都有在 Cluster 裡面便可以進行。
以下範例中，Primary 資料庫，edb1 的 IP 位址為10.146.0.3；Standby 資料庫，edb4 的 IP 位址為10.146.0.4。
執行 Switchover 之前，我們觀察資料庫叢集狀態：
[root@edb1 ~]# /usr/efm-2.1/bin/efm cluster-status efm
Cluster Status: efm
VIP:
Agent Type Address Agent DB Info
--------------------------------------------------------------
Standby 10.146.0.4 UP UP
Witness 10.146.0.5 UP N/A
Master 10.146.0.3 UP UP
Allowed node host list:
10.146.0.3 10.146.0.4 10.146.0.5
Membership coordinator: 10.146.0.3
Standby priority host list:
10.146.0.4
Promote Status:
DB Type Address XLog Loc Info
--------------------------------------------------------------
Master 10.146.0.3 0/60001A8
Standby 10.146.0.4 0/60001A8
Standby database(s) in sync with master. It is safe to promote.
以上標記 Safe to promote 便能夠進行 Switchover 操作。
我們要執行 Switchover 可以下達下列指令：
[root@edb1 ~]# /usr/efm-2.1/bin/efm promote efm -switchover Promote/switchover command accepted by local agent. Proceeding with promotion and will reconfigure original master. Run the 'cluster-status' command for information about the new cluster state.
接著馬上看資料庫叢集狀態：
[root@edb1 ~]# sudo /usr/efm-2.1/bin/efm cluster-status efm
Cluster Status: efm
VIP:
Agent Type Address Agent DB Info
--------------------------------------------------------------
Witness 10.146.0.5 UP N/A
Standby 10.146.0.3 UP UP
Master 10.146.0.4 UP UP
Allowed node host list:
10.146.0.3 10.146.0.4 10.146.0.5
Membership coordinator: 10.146.0.3
Standby priority host list:
10.146.0.3
Promote Status:
DB Type Address XLog Loc Info
--------------------------------------------------------------
Master 10.146.0.4 0/70001E0
Standby 10.146.0.3 0/70001E0
Standby database(s) in sync with master. It is safe to promote.
我們可以發現 Master/Standby 對調了
[enterprisedb@edb1 ~]# ls $PGDATA base pg_clog pg_hba.conf pg_logical pg_replslot pg_stat pg_tblspc pg_xlog postmaster.opts recovery.conf_2016-11-29-15:33:19 dbms_pipe pg_commit_ts pg_ident.conf pg_multixact pg_serial pg_stat_tmp pg_twophase postgresql.auto.conf postmaster.pid global pg_dynshmem pg_log pg_notify pg_snapshots pg_subtrans PG_VERSION postgresql.conf recovery.conf
當然，「舊的 Standby 資料庫/新的 Primary 資料庫」目錄下，recovery.conf 被重新命名為 recovery.done
[enterprisedb@edb2 ~]# ls $PGDATA
backup_label.old global pg_dynshmem pg_log pg_notify pg_snapshots pg_subtrans PG_VERSION postgresql.conf recovery.done
base pg_clog pg_hba.conf pg_logical pg_replslot pg_stat pg_tblspc pg_xlog postmaster.opts
dbms_pipe pg_commit_ts pg_ident.conf pg_multixact pg_serial pg_stat_tmp pg_twophase postgresql.auto.conf postmaster.pid
最後，我們也可以從交易日誌檔案看一下 timeline 變化
[enterprisedb@edb1 ~]# ls $PGDATA/pg_xlog 000000010000000000000003.00000028.backup 00000002.history 00000003.history 000000040000000000000008 00000004000000000000000A archive_status 000000020000000000000006.partial 000000030000000000000007 000000040000000000000007 000000040000000000000009 00000004.history
[enterprisedb@edb2 ~]# ls $PGDATA/pg_xlog 00000002.history 00000003.history 000000040000000000000008 00000004000000000000000A 00000004.history 000000030000000000000007.partial 000000040000000000000007 000000040000000000000009 00000004000000000000000B archive_status
也可以透過 PostgreSQL 指令觀察目前的 Timeline
edb=# select * from pg_stat_archiver;
archived_count | last_archived_wal | last_archived_time | failed_count | last_failed_wal | last_failed_time | stats_reset
----------------+--------------------------+----------------------------------+--------------+-----------------+------------------+----------------------------------
3 | 000000050000000000000008 | 29-NOV-16 16:32:47.046571 +00:00 | 0 | | | 29-NOV-16 15:56:59.214743 +00:00
(1 row)
以上都可以發現 timeline 有好些變動。（其實我已經切換兩三次了～）
於是，資料庫服務的主從角色已經對調成功。
參考資料
以下參考資料是 Switchover 的手動操作，可以供有興趣的人參考
Switchover/Switchback in PostgreSQL 9.3 | EnterpriseDB
除了先前的 pg_rewind 筆記所列的資料，以下再多補充一點
Back to the Future Part 3: pg_rewind with PostgreSQL 9.6 | 2ndQuadrant Blog
沒有留言:
張貼留言