Mailing List Archive

ひがしと申します。
お世話になります。


>＜確認１＞
>　Slave(新Master)にてフェイルオーバー後の状態を継続するものと想定して
>　いましたが、OS停止をした場合はこの様な挙動になるのは正しいのでしょうか？

PG-REXでは、Pacemaker起動をMasterになってほしいノードから片方ずつ行い、
そのPacemakerが完全に起動し、PostgreSQLがMasterになったことを確認してから、
もう片方を起動する、というように起動する必要があります。
Pacemakerからすると、2ノード同時に起動された場合、どちらのノードを優先して
Masterにすべきか判断できないためです。

今回の場合、Slave(新Master)のみを先に起動すれば、きちんとMasterになったかと
思います。


>＜確認２＞
>　クラスタの復旧作業として①と②以外に行うことはありますか？
>　(※VIP_01はdebug-atartにて強制起動し、PostgreSQLは手動起動しましたが、
>　未だ〝stopped〟のままです。)
ログを確認しないと断定はできませんが、両系でPGSQL.lockファイルが残存している
可能性があります。

これは、データが古い可能性があることをユーザに気づかせるための印で、
Pacemaker(pgsql RA)が正常停止するときのみ削除されます。つまり、異常停止時
には残存し、異常停止した旨をユーザに気づかせるものです。
通常、postgreユーザのホーム配下のtmp/(/var/lib/pgsql/tmp/)にあります。

データ復旧後、またはデータが古い可能性があること承知の上で、当該ノードの
PostgreSQLを起動する際は、このファイルを手動で削除する必要があります。



なお、手前味噌になりますが、昨年福岡で開催のオープンソースカンファレンスにて
PG-REXの故障時の挙動や運用方法をまとめた講演を行いました。
PostgreSQLプロセス停止後の復旧は、以下P42に掲載しています。

http://linux-ha.osdn.jp/wp/archives/4137
　→PG-REXで学ぶPacemaker運用の実例
　　　P42 vip-master故障時の復旧方法


>＜確認３＞
>　そもそもの話なのですが、クラスタ起動時にVIP付与とPostgreSQL起動が
>　されない状態です。(PostgreSQLは手動起動してます)
>　設定内容を以下に示すので、不足している設定をご教示願います。
構築後、一度きちんと起動しているようなので、設定に問題は無いかと
思います。
＃STONITH, SFEX, VIPcheck等の排他制御は設定されていないようなので、
　スプリットブレイン発生時は両系ノードがMasterになってしまうのが
　問題と言えば問題ですが、今回の事象とは関係ないと思います。
　排他制御については、以下講演が詳しいです。
　　http://linux-ha.osdn.jp/wp/archives/4338
　　　→試して覚えるPacemaker入門 排他制御機能編


一度、以下の順に、起動・停止をやりなおしてみてはいかがでしょうか？
(上記PGSQL.lockや片系ずつ起動、を踏まえた手順案です。)

　1) 一旦、両系のPacemakerをSlave→Masterの順に片系ずつ停止
　2) 一旦、手動起動した両系のPostgreSQLをSlave→Masterの順に片系ずつ停止
　3) 両系の/var/lib/pgsql/tmp/PGSQL.lock　を削除
　4) さきほどMasterだった方のノードのPacemakerを起動
　　 →crm_mon等でPostgreSQLがMasterになることを確認
　5) pg_basebackupを実行し、現Masterの最新データをSlaveにコピー
　6) SlaveのPacemakerを起動


これでも起動しない場合、両系分のPacemakerとPostgreSQLのログを見てみる
必要があります。


以上です。
よろしくお願いいたします。


----- 元のメッセージ -----
From: "Pacemaker初心者" <m.hiraguchi@freebit.net>
宛先: linux-ha-japan@lists.osdn.me
送信済み: 2016年1月8日, 金曜日 午後 6:38:26
件名: [Linux-ha-jp] クラスタの復旧およびPacemakerの挙動について

お世話になります。

先般、PG-REXでのPacemaker構築にて上手くいかなかったので、勉強がてら
pcsコマンドにて再構築を行いました。

[環境]
OS ：CentOS7.1
PostgresSQL ：postgresql-server-9.2.13-1
Pacemaker ：pacemaker-1.1.12-22


構築後に諸々問題点が発生しており、ご助勢頂けると助かります。
以下、状況を順に記します。


(１)構築後の状況
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
# crm_mon -Arf -1
Last updated: Tue Jan 5 21:39:19 2016
Last change: Tue Jan 5 21:38:46 2016 by hacluster via crmd on zabbix01
Stack: corosync
Current DC: zabbix01(1) - partition with quorum
Version: 1.1.12-561c4cf
2 Nodes configured
3 Resources configured

Online: [ zabbix01 zabbix02 ]

Full list of resources:

Master/Slave Set: msPostgresql [pgsql]
Masters: [ zabbix01 ]
Slaves: [ zabbix02 ]
Resource Group: master-group
VIP_01 (ocf::heartbeat:IPaddr2): Started zabbix01

Node Attributes:
* Node zabbix01:
+ #cluster-name : zabbixcluster
+ #site-name : zabbixcluster
+ master-pgsql : 1000
+ pgsql-data-status : LATEST
+ pgsql-master-baseline : 0000000016000080
+ pgsql-status : PRI
* Node zabbix02:
+ #cluster-name : zabbixcluster
+ #site-name : zabbixcluster
+ master-pgsql : 100
+ pgsql-data-status : STREAMING|ASYNC
+ pgsql-status : HS:async

Migration summary:
* Node zabbix02:
* Node zabbix01:
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝


(２)Slaveへの切替
切替テストとして、Zabbix01のPostgresqlを停止しました。
停止後のクラスタの状態(下記)としては問題ないと思ってます。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
# crm_mon -Arf -1
Last updated: Wed Jan 6 00:45:32 2016
Last change: Wed Jan 6 00:30:22 2016 by hacluster via crmd on zabbix01
Stack: corosync
Current DC: zabbix01 (1) - partition with quorum
Version: 1.1.12-561c4cf
2 Nodes configured
3 Resources configured

Online: [ zabbix01 zabbix02 ]

Full list of resources:

Master/Slave Set: msPostgresql [pgsql]
Masters: [ zabbix02 ]
Stopped: [ zabbix01 ]
Resource Group: master-group
VIP_01 (ocf::heartbeat:IPaddr2): Started zabbix02p

Node Attributes:
* Node zabbix01:
+ #cluster-name : zabbixcluster
+ #site-name : zabbixcluster
+ master-pgsql : -INFINITY
+ pgsql-data-status : DISCONNECT
+ pgsql-status : STOP
* Node zabbix02:
+ #cluster-name : zabbixcluster
+ #site-name : zabbixcluster
+ master-pgsql : 1000
+ pgsql-data-status : LATEST
+ pgsql-master-baseline : 0000000017000080
+ pgsql-status : PRI

Migration summary:
* Node zabbix02:
* Node zabbix01:
pgsql: migration-threshold=1 fail-count=1 last-failure='Wed Jan 6
00:30:13 2016'

Failed actions:
pgsql_monitor_3000 on zabbix01 'unknown error' (1): call=126,
status=complete, last-rc-change='Wed Jan 6 00:30:13 2016', queued=0ms,
exec=0ms
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝


(３)
この後、切戻しを行う際に当方の不手際で、Master(Zabbix01)とSlave(Zabbix02)
のOS停止をしてしまいました。
停止後、両機を起動しましたが、「pcs status」および「crm_mon -Arf -1」
でのmaster-group(VIP_01)、msPostgresql(pgsql)のリソースのステータスが、
〝stopped〟となっていました。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
# pcs status
Cluster name: zabbixcluster
Last updated: Thr Jan 7 17:11:58 2016
Last change: Thr Jan 7 15:57:37 2016 by hacluster via crmd on zabbix01
Stack: corosync
Current DC: zabbix02 (1) - partition with quorum
Version: 1.1.12-561c4cf
2 Nodes configured
3 Resources configured


Online: [ zabbix01 zabbix02 ]

Full list of resources:

Master/Slave Set: msPostgresql [pgsql]
Stopped: [ zabbix01 zabbix02 ]
Resource Group: master-group
VIP_01 (ocf::heartbeat:IPaddr2): Stopped

PCSD Status:
zabbix01 (192.168.252.182): Online
zabbix02 (192.168.252.183): Online

Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

＜確認１＞
　Slave(新Master)にてフェイルオーバー後の状態を継続するものと想定して
　いましたが、OS停止をした場合はこの様な挙動になるのは正しいのでしょうか？


(４)復旧
pg_basebackup、pg_ctl promote等を行い、PostgreSQLの戻しを行いました。
(※「psql -h localhost -c "SELECT pg_is_in_recovery();"」にて
両PostgresSQLの起動状態(Zabbix01：f、Zabbix02：t)と、ストリーミング
レプリケーションの動作を確認済)

PostgreSQLの状態復旧を行った後に、
　①pcs resource cleanup msPostgresqlとpcs resource cleanup master-group
　②pcs cluster stop --allとpcs cluster start --all
にて復旧を試みましたが、両リソースの状態は〝stopped〟のままです。

＜確認２＞
　クラスタの復旧作業として①と②以外に行うことはありますか？
　(※VIP_01はdebug-atartにて強制起動し、PostgreSQLは手動起動しましたが、
　未だ〝stopped〟のままです。)


＜確認３＞
　そもそもの話なのですが、クラスタ起動時にVIP付与とPostgreSQL起動が
　されない状態です。(PostgreSQLは手動起動してます)
　設定内容を以下に示すので、不足している設定をご教示願います。

■設定内容
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
pcs -f cluster_cfg property set no-quorum-policy="ignore"
pcs -f cluster_cfg property set stonith-enabled="false"
pcs -f cluster_cfg resource defaults resource-stickiness="INFINITY"
pcs -f cluster_cfg resource defaults migration-threshold="1"

pcs -f cluster_cfg resource create VIP_01 IPaddr2 \
ip="192.168.252.184" \
nic="enp0s3" \
cidr_netmask="24" \
op start timeout="60s" interval="0s" on-fail="restart" \
op monitor timeout="60s" interval="10s" on-fail="restart" \
op stop timeout="60s" interval="0s" on-fail="block"

pcs -f cluster_cfg resource create pgsql pgsql \
pgctl="/usr/bin/pg_ctl" \
psql="/usr/bin/psql" \
pgdata="/var/lib/pgsql/data/" \
rep_mode="async" \
node_list="zabbix01 zabbix02" \
restore_command="cp /var/lib/pgsql/pg_archive/%f %p" \
primary_conninfo_opt="keepalives_idle=60 keepalives_interval=5
keepalives_count=5" \
master_ip="192.168.252.184" \
restart_on_promote='true' \
op start timeout="60s" interval="0s" on-fail="restart" \
op monitor timeout="60s" interval="4s" on-fail="restart" \
op monitor timeout="60s" interval="3s" on-fail="restart"
role="Master" \
op promote timeout="60s" interval="0s" on-fail="restart" \
op demote timeout="60s" interval="0s" on-fail="stop" \
op stop timeout="60s" interval="0s" on-fail="block" \
op notify timeout="60s" interval="0s"

pcs -f cluster_cfg resource master msPostgresql pgsql \
master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true

pcs -f cluster_cfg resource group add master-group VIP_01

pcs -f pgsql_cfg constraint colocation add master-group with Master
msPostgresql INFINITY
pcs -f pgsql_cfg constraint order promote msPostgresql then start
master-group symmetrical=false score=INFINITY
pcs -f pgsql_cfg constraint order demote msPostgresql then stop
master-group symmetrical=false score=0
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

(上記を「pcs cluster cib-push cluster_cfg」にて反映しています)

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan
_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan

ひがし様

ご回答ありがとうございます。

＜確認１のご回答＞
>PG-REXでは、Pacemaker起動をMasterになってほしいノードから片方ずつ行い、
>そのPacemakerが完全に起動し、PostgreSQLがMasterになったことを確認してから、
>もう片方を起動する、というように起動する必要があります。
>Pacemakerからすると、2ノード同時に起動された場合、どちらのノードを優先して
>Masterにすべきか判断できないためです。
>今回の場合、Slave(新Master)のみを先に起動すれば、きちんとMasterになったかと
>思います。

⇒本ケースの再現がありましたので、Slave(新Master)機⇒Master(新Slave)機の順で、
　クラスタ起動を行いました。

＜確認２のご回答＞
>ログを確認しないと断定はできませんが、両系でPGSQL.lockファイルが残存している
>可能性があります。
>これは、データが古い可能性があることをユーザに気づかせるための印で、
>Pacemaker(pgsql RA)が正常停止するときのみ削除されます。つまり、異常停止時
>には残存し、異常停止した旨をユーザに気づかせるものです。
>通常、postgreユーザのホーム配下のtmp/(/var/lib/pgsql/tmp/)にあります。
>データ復旧後、またはデータが古い可能性があること承知の上で、当該ノードの
>PostgreSQLを起動する際は、このファイルを手動で削除する必要があります

⇒ご指摘の事項およびpg_basebackup、promote、recovery.done⇒recovery.confの
リネーム等
　PostgreSQLの(Masterでの)起動条件を整理し復旧しました。

＜確認３のご回答＞
>構築後、一度きちんと起動しているようなので、設定に問題は無いかと
>思います。
>＃STONITH, SFEX, VIPcheck等の排他制御は設定されていないようなので、
>　スプリットブレイン発生時は両系ノードがMasterになってしまうのが
>　問題と言えば問題ですが、今回の事象とは関係ないと思います。
⇒クラスタ起動に連動し、PostgreSQLが起動するようになりました。
　※関係ないかもしれませんが、前回との変更点は、PostgreSQLリソースに
　「start_option="-i -p 5432"」の追加です。


■新たな確認事項
　VIP、PostgreSQLのクラスタリソースおよびグループ以外のリソース(Zabbix)
を追加しました。

　■zabbixリソースの作成内容
# pcs resource create ZabbixSV zabbixserver \
> binary="/usr/sbin/zabbix_server" \
> pid="/var/run/zabbix/zabbix_server.pid" \
> config="/etc/zabbix/zabbix_server.conf" \
> op start timeout="60s" interval="0s" on-fail="restart" \
> op monitor timeout="60s" interval="0s" on-fail="restart" \
> op stop timeout="60s" interval="0s" on-fail="block"

　■zabbixリソースのグループ登録(VIPリソースグループへの追加)
# pcs resource group add GrpVIP ZabbixSV
# pcs resource group list
GrpVIP: VIP_01 ZabbixSV


※フェイルオーバー時の起動順序は、
　　①PostgreSQLのPromote
　　②VIP付与
　　③ZabbixServer起動
　を想定しています。

この内容で、PostgreSQL障害時はSlave(新マスタ)機へ問題なく切り替わりまし
たが、
ZabbixServer障害時はクラスタリソース全てがMaster、Slave共に停止してしま
いました。

PostgreSQLに依存するクラスタリソースの登録について
ご教示願います。

ご助勢の程、宜しくお願い致します。



On 2016/01/14 13:48, kazuh@goo.jp wrote:
> ひがしと申します。
> お世話になります。
>
>
>> ＜確認１＞
>> 　Slave(新Master)にてフェイルオーバー後の状態を継続するものと想定して
>> 　いましたが、OS停止をした場合はこの様な挙動になるのは正しいのでしょうか？
> PG-REXでは、Pacemaker起動をMasterになってほしいノードから片方ずつ行い、
> そのPacemakerが完全に起動し、PostgreSQLがMasterになったことを確認してから、
> もう片方を起動する、というように起動する必要があります。
> Pacemakerからすると、2ノード同時に起動された場合、どちらのノードを優先して
> Masterにすべきか判断できないためです。
>
> 今回の場合、Slave(新Master)のみを先に起動すれば、きちんとMasterになったかと
> 思います。
>
>
>> ＜確認２＞
>> 　クラスタの復旧作業として①と②以外に行うことはありますか？
>> 　(※VIP_01はdebug-atartにて強制起動し、PostgreSQLは手動起動しましたが、
>> 　未だ〝stopped〟のままです。)
> ログを確認しないと断定はできませんが、両系でPGSQL.lockファイルが残存している
> 可能性があります。
>
> これは、データが古い可能性があることをユーザに気づかせるための印で、
> Pacemaker(pgsql RA)が正常停止するときのみ削除されます。つまり、異常停止時
> には残存し、異常停止した旨をユーザに気づかせるものです。
> 通常、postgreユーザのホーム配下のtmp/(/var/lib/pgsql/tmp/)にあります。
>
> データ復旧後、またはデータが古い可能性があること承知の上で、当該ノードの
> PostgreSQLを起動する際は、このファイルを手動で削除する必要があります。
>
>
>
> なお、手前味噌になりますが、昨年福岡で開催のオープンソースカンファレンスにて
> PG-REXの故障時の挙動や運用方法をまとめた講演を行いました。
> PostgreSQLプロセス停止後の復旧は、以下P42に掲載しています。
>
> http://linux-ha.osdn.jp/wp/archives/4137
> 　→PG-REXで学ぶPacemaker運用の実例
> 　　　P42 vip-master故障時の復旧方法
>
>
>> ＜確認３＞
>> 　そもそもの話なのですが、クラスタ起動時にVIP付与とPostgreSQL起動が
>> 　されない状態です。(PostgreSQLは手動起動してます)
>> 　設定内容を以下に示すので、不足している設定をご教示願います。
> 構築後、一度きちんと起動しているようなので、設定に問題は無いかと
> 思います。
> ＃STONITH, SFEX, VIPcheck等の排他制御は設定されていないようなので、
> 　スプリットブレイン発生時は両系ノードがMasterになってしまうのが
> 　問題と言えば問題ですが、今回の事象とは関係ないと思います。
> 　排他制御については、以下講演が詳しいです。
> 　　http://linux-ha.osdn.jp/wp/archives/4338
> 　　　→試して覚えるPacemaker入門 排他制御機能編
>
>
> 一度、以下の順に、起動・停止をやりなおしてみてはいかがでしょうか？
> (上記PGSQL.lockや片系ずつ起動、を踏まえた手順案です。)
>
> 　1) 一旦、両系のPacemakerをSlave→Masterの順に片系ずつ停止
> 　2) 一旦、手動起動した両系のPostgreSQLをSlave→Masterの順に片系ずつ停止
> 　3) 両系の/var/lib/pgsql/tmp/PGSQL.lock　を削除
> 　4) さきほどMasterだった方のノードのPacemakerを起動
> 　　 →crm_mon等でPostgreSQLがMasterになることを確認
> 　5) pg_basebackupを実行し、現Masterの最新データをSlaveにコピー
> 　6) SlaveのPacemakerを起動
>
>
> これでも起動しない場合、両系分のPacemakerとPostgreSQLのログを見てみる
> 必要があります。
>
>
> 以上です。
> よろしくお願いいたします。
>
>
> ----- 元のメッセージ -----
> From: "Pacemaker初心者" <m.hiraguchi@freebit.net>
> 宛先: linux-ha-japan@lists.osdn.me
> 送信済み: 2016年1月8日, 金曜日 午後 6:38:26
> 件名: [Linux-ha-jp] クラスタの復旧およびPacemakerの挙動について
>
> お世話になります。
>
> 先般、PG-REXでのPacemaker構築にて上手くいかなかったので、勉強がてら
> pcsコマンドにて再構築を行いました。
>
> [環境]
> OS ：CentOS7.1
> PostgresSQL ：postgresql-server-9.2.13-1
> Pacemaker ：pacemaker-1.1.12-22
>
>
> 構築後に諸々問題点が発生しており、ご助勢頂けると助かります。
> 以下、状況を順に記します。
>
>
> (１)構築後の状況
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
> # crm_mon -Arf -1
> Last updated: Tue Jan 5 21:39:19 2016
> Last change: Tue Jan 5 21:38:46 2016 by hacluster via crmd on zabbix01
> Stack: corosync
> Current DC: zabbix01(1) - partition with quorum
> Version: 1.1.12-561c4cf
> 2 Nodes configured
> 3 Resources configured
>
> Online: [ zabbix01 zabbix02 ]
>
> Full list of resources:
>
> Master/Slave Set: msPostgresql [pgsql]
> Masters: [ zabbix01 ]
> Slaves: [ zabbix02 ]
> Resource Group: master-group
> VIP_01 (ocf::heartbeat:IPaddr2): Started zabbix01
>
> Node Attributes:
> * Node zabbix01:
> + #cluster-name : zabbixcluster
> + #site-name : zabbixcluster
> + master-pgsql : 1000
> + pgsql-data-status : LATEST
> + pgsql-master-baseline : 0000000016000080
> + pgsql-status : PRI
> * Node zabbix02:
> + #cluster-name : zabbixcluster
> + #site-name : zabbixcluster
> + master-pgsql : 100
> + pgsql-data-status : STREAMING|ASYNC
> + pgsql-status : HS:async
>
> Migration summary:
> * Node zabbix02:
> * Node zabbix01:
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>
>
> (２)Slaveへの切替
> 切替テストとして、Zabbix01のPostgresqlを停止しました。
> 停止後のクラスタの状態(下記)としては問題ないと思ってます。
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
> # crm_mon -Arf -1
> Last updated: Wed Jan 6 00:45:32 2016
> Last change: Wed Jan 6 00:30:22 2016 by hacluster via crmd on zabbix01
> Stack: corosync
> Current DC: zabbix01 (1) - partition with quorum
> Version: 1.1.12-561c4cf
> 2 Nodes configured
> 3 Resources configured
>
> Online: [ zabbix01 zabbix02 ]
>
> Full list of resources:
>
> Master/Slave Set: msPostgresql [pgsql]
> Masters: [ zabbix02 ]
> Stopped: [ zabbix01 ]
> Resource Group: master-group
> VIP_01 (ocf::heartbeat:IPaddr2): Started zabbix02p
>
> Node Attributes:
> * Node zabbix01:
> + #cluster-name : zabbixcluster
> + #site-name : zabbixcluster
> + master-pgsql : -INFINITY
> + pgsql-data-status : DISCONNECT
> + pgsql-status : STOP
> * Node zabbix02:
> + #cluster-name : zabbixcluster
> + #site-name : zabbixcluster
> + master-pgsql : 1000
> + pgsql-data-status : LATEST
> + pgsql-master-baseline : 0000000017000080
> + pgsql-status : PRI
>
> Migration summary:
> * Node zabbix02:
> * Node zabbix01:
> pgsql: migration-threshold=1 fail-count=1 last-failure='Wed Jan 6
> 00:30:13 2016'
>
> Failed actions:
> pgsql_monitor_3000 on zabbix01 'unknown error' (1): call=126,
> status=complete, last-rc-change='Wed Jan 6 00:30:13 2016', queued=0ms,
> exec=0ms
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>
>
> (３)
> この後、切戻しを行う際に当方の不手際で、Master(Zabbix01)とSlave(Zabbix02)
> のOS停止をしてしまいました。
> 停止後、両機を起動しましたが、「pcs status」および「crm_mon -Arf -1」
> でのmaster-group(VIP_01)、msPostgresql(pgsql)のリソースのステータスが、
> 〝stopped〟となっていました。
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
> # pcs status
> Cluster name: zabbixcluster
> Last updated: Thr Jan 7 17:11:58 2016
> Last change: Thr Jan 7 15:57:37 2016 by hacluster via crmd on zabbix01
> Stack: corosync
> Current DC: zabbix02 (1) - partition with quorum
> Version: 1.1.12-561c4cf
> 2 Nodes configured
> 3 Resources configured
>
>
> Online: [ zabbix01 zabbix02 ]
>
> Full list of resources:
>
> Master/Slave Set: msPostgresql [pgsql]
> Stopped: [ zabbix01 zabbix02 ]
> Resource Group: master-group
> VIP_01 (ocf::heartbeat:IPaddr2): Stopped
>
> PCSD Status:
> zabbix01 (192.168.252.182): Online
> zabbix02 (192.168.252.183): Online
>
> Daemon Status:
> corosync: active/enabled
> pacemaker: active/enabled
> pcsd: active/enabled
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>
> ＜確認１＞
> 　Slave(新Master)にてフェイルオーバー後の状態を継続するものと想定して
> 　いましたが、OS停止をした場合はこの様な挙動になるのは正しいのでしょうか？
>
>
> (４)復旧
> pg_basebackup、pg_ctl promote等を行い、PostgreSQLの戻しを行いました。
> (※「psql -h localhost -c "SELECT pg_is_in_recovery();"」にて
> 両PostgresSQLの起動状態(Zabbix01：f、Zabbix02：t)と、ストリーミング
> レプリケーションの動作を確認済)
>
> PostgreSQLの状態復旧を行った後に、
> 　①pcs resource cleanup msPostgresqlとpcs resource cleanup master-group
> 　②pcs cluster stop --allとpcs cluster start --all
> にて復旧を試みましたが、両リソースの状態は〝stopped〟のままです。
>
> ＜確認２＞
> 　クラスタの復旧作業として①と②以外に行うことはありますか？
> 　(※VIP_01はdebug-atartにて強制起動し、PostgreSQLは手動起動しましたが、
> 　未だ〝stopped〟のままです。)
>
>
> ＜確認３＞
> 　そもそもの話なのですが、クラスタ起動時にVIP付与とPostgreSQL起動が
> 　されない状態です。(PostgreSQLは手動起動してます)
> 　設定内容を以下に示すので、不足している設定をご教示願います。
>
> ■設定内容
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
> pcs -f cluster_cfg property set no-quorum-policy="ignore"
> pcs -f cluster_cfg property set stonith-enabled="false"
> pcs -f cluster_cfg resource defaults resource-stickiness="INFINITY"
> pcs -f cluster_cfg resource defaults migration-threshold="1"
>
> pcs -f cluster_cfg resource create VIP_01 IPaddr2 \
> ip="192.168.252.184" \
> nic="enp0s3" \
> cidr_netmask="24" \
> op start timeout="60s" interval="0s" on-fail="restart" \
> op monitor timeout="60s" interval="10s" on-fail="restart" \
> op stop timeout="60s" interval="0s" on-fail="block"
>
> pcs -f cluster_cfg resource create pgsql pgsql \
> pgctl="/usr/bin/pg_ctl" \
> psql="/usr/bin/psql" \
> pgdata="/var/lib/pgsql/data/" \
> rep_mode="async" \
> node_list="zabbix01 zabbix02" \
> restore_command="cp /var/lib/pgsql/pg_archive/%f %p" \
> primary_conninfo_opt="keepalives_idle=60 keepalives_interval=5
> keepalives_count=5" \
> master_ip="192.168.252.184" \
> restart_on_promote='true' \
> op start timeout="60s" interval="0s" on-fail="restart" \
> op monitor timeout="60s" interval="4s" on-fail="restart" \
> op monitor timeout="60s" interval="3s" on-fail="restart"
> role="Master" \
> op promote timeout="60s" interval="0s" on-fail="restart" \
> op demote timeout="60s" interval="0s" on-fail="stop" \
> op stop timeout="60s" interval="0s" on-fail="block" \
> op notify timeout="60s" interval="0s"
>
> pcs -f cluster_cfg resource master msPostgresql pgsql \
> master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true
>
> pcs -f cluster_cfg resource group add master-group VIP_01
>
> pcs -f pgsql_cfg constraint colocation add master-group with Master
> msPostgresql INFINITY
> pcs -f pgsql_cfg constraint order promote msPostgresql then start
> master-group symmetrical=false score=INFINITY
> pcs -f pgsql_cfg constraint order demote msPostgresql then stop
> master-group symmetrical=false score=0
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>
> (上記を「pcs cluster cib-push cluster_cfg」にて反映しています)
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan

ひがしです。お世話になります。

>⇒ご指摘の事項およびpg_basebackup、promote、recovery.done⇒recovery.confの
>リネーム等
>　PostgreSQLの(Masterでの)起動条件を整理し復旧しました。
うまくいったのなら良かったです。
参考まで、recovery.confはPacemaker(pgsql RA)が自動的に作成するので、
手動で作成(リネーム)する必要は無いですよ。


>この内容で、PostgreSQL障害時はSlave(新マスタ)機へ問題なく切り替わりまし
>たが、
>ZabbixServer障害時はクラスタリソース全てがMaster、Slave共に停止してしま
>いました。
思いつく（よくあるケース）で以下２つが考えられます。

(1)リソース停止失敗していないか？
ZabbixServer障害は、具体的にはどんな障害でしょうか？
今回の設定では、前回回答でも少し触れましたが、STONITH(排他制御)が設定
されていないようなので、リソースの停止が失敗するケースの故障時は、
フェイルオーバはできません。

具体的には、各リソース設定の以下op stop～～行の「on-fail="block"」
というのが、「リソースの停止に失敗したら、フェイルオーバを中止(block)する」
ということを示しています。
　op stop timeout="60s" interval="0s" on-fail="block"

STONITHを導入し、かつon-fail="fence"と設定すると、リソースの停止失敗時は
STONITHが発動し、相手ノードの電源を強制的に断した後、フェイルオーバが
継続します。

このあたり、詳細は、前回も紹介の以下資料をご覧ください。
　　http://linux-ha.osdn.jp/wp/archives/4338
　　　→試して覚えるPacemaker入門 排他制御機能編


(2)フェイルカウントや制約等が残っていないか？
フェイルオーバ先に、過去、故障や、手動リソース移動でついた制約が
残ってしまってないでしょうか？

フェイルカウントは、「crm_mon -rfA」の表示の"Failed actions:"という
最下部の欄に何か表示があれば、残った状態です。
残っていると、Pacemakerはこのノードは故障していると判断し、
リソースは起動しません。

前回紹介の以下資料P34の表示例を参考に、残っていればP36のコマンドで
フェイルカウントを削除してください。
> http://linux-ha.osdn.jp/wp/archives/4137
> 　→PG-REXで学ぶPacemaker運用の実例

また、crm_resource -M -r コマンドでリソースを手動で移動した後、
「crm_resource -U -r ＜リソース名＞」を実行していない場合、
移動元のノードにはリソースが起動できない制約が残ります。
(crm_mon -rfAL で確認できます。)
その場合、「crm_resource -U -r ＜リソース名＞」で制約を消してください。



さて、上記はあくまでも推測で、今回の事象がそれに該当するかどうかは、
ログ等を確認しないとわかりません。
ZabbixServer障害発生時の、「crm_mon -Arf -1」やPacemakerのログ(両系分)が
あれば、もう少し今回の事象の原因を解析できると思います。


以上です。よろしくお願いいたします。

----- 元のメッセージ -----
From: "Pacemaker初心者" <m.hiraguchi@freebit.net>
宛先: linux-ha-japan@lists.osdn.me
送信済み: 2016年1月14日, 木曜日 午後 8:53:15
件名: Re: [Linux-ha-jp] クラスタの復旧およびPacemakerの挙動について

ひがし様

ご回答ありがとうございます。

＜確認１のご回答＞
>PG-REXでは、Pacemaker起動をMasterになってほしいノードから片方ずつ行い、
>そのPacemakerが完全に起動し、PostgreSQLがMasterになったことを確認してから、
>もう片方を起動する、というように起動する必要があります。
>Pacemakerからすると、2ノード同時に起動された場合、どちらのノードを優先して
>Masterにすべきか判断できないためです。
>今回の場合、Slave(新Master)のみを先に起動すれば、きちんとMasterになったかと
>思います。

⇒本ケースの再現がありましたので、Slave(新Master)機⇒Master(新Slave)機の順で、
　クラスタ起動を行いました。

＜確認２のご回答＞
>ログを確認しないと断定はできませんが、両系でPGSQL.lockファイルが残存している
>可能性があります。
>これは、データが古い可能性があることをユーザに気づかせるための印で、
>Pacemaker(pgsql RA)が正常停止するときのみ削除されます。つまり、異常停止時
>には残存し、異常停止した旨をユーザに気づかせるものです。
>通常、postgreユーザのホーム配下のtmp/(/var/lib/pgsql/tmp/)にあります。
>データ復旧後、またはデータが古い可能性があること承知の上で、当該ノードの
>PostgreSQLを起動する際は、このファイルを手動で削除する必要があります

⇒ご指摘の事項およびpg_basebackup、promote、recovery.done⇒recovery.confの
リネーム等
　PostgreSQLの(Masterでの)起動条件を整理し復旧しました。

＜確認３のご回答＞
>構築後、一度きちんと起動しているようなので、設定に問題は無いかと
>思います。
>＃STONITH, SFEX, VIPcheck等の排他制御は設定されていないようなので、
>　スプリットブレイン発生時は両系ノードがMasterになってしまうのが
>　問題と言えば問題ですが、今回の事象とは関係ないと思います。
⇒クラスタ起動に連動し、PostgreSQLが起動するようになりました。
　※関係ないかもしれませんが、前回との変更点は、PostgreSQLリソースに
　「start_option="-i -p 5432"」の追加です。


■新たな確認事項
　VIP、PostgreSQLのクラスタリソースおよびグループ以外のリソース(Zabbix)
を追加しました。

　■zabbixリソースの作成内容
# pcs resource create ZabbixSV zabbixserver \
> binary="/usr/sbin/zabbix_server" \
> pid="/var/run/zabbix/zabbix_server.pid" \
> config="/etc/zabbix/zabbix_server.conf" \
> op start timeout="60s" interval="0s" on-fail="restart" \
> op monitor timeout="60s" interval="0s" on-fail="restart" \
> op stop timeout="60s" interval="0s" on-fail="block"

　■zabbixリソースのグループ登録(VIPリソースグループへの追加)
# pcs resource group add GrpVIP ZabbixSV
# pcs resource group list
GrpVIP: VIP_01 ZabbixSV


※フェイルオーバー時の起動順序は、
　　①PostgreSQLのPromote
　　②VIP付与
　　③ZabbixServer起動
　を想定しています。

この内容で、PostgreSQL障害時はSlave(新マスタ)機へ問題なく切り替わりまし
たが、
ZabbixServer障害時はクラスタリソース全てがMaster、Slave共に停止してしま
いました。

PostgreSQLに依存するクラスタリソースの登録について
ご教示願います。

ご助勢の程、宜しくお願い致します。



On 2016/01/14 13:48, kazuh@goo.jp wrote:
> ひがしと申します。
> お世話になります。
>
>
>> ＜確認１＞
>> 　Slave(新Master)にてフェイルオーバー後の状態を継続するものと想定して
>> 　いましたが、OS停止をした場合はこの様な挙動になるのは正しいのでしょうか？
> PG-REXでは、Pacemaker起動をMasterになってほしいノードから片方ずつ行い、
> そのPacemakerが完全に起動し、PostgreSQLがMasterになったことを確認してから、
> もう片方を起動する、というように起動する必要があります。
> Pacemakerからすると、2ノード同時に起動された場合、どちらのノードを優先して
> Masterにすべきか判断できないためです。
>
> 今回の場合、Slave(新Master)のみを先に起動すれば、きちんとMasterになったかと
> 思います。
>
>
>> ＜確認２＞
>> 　クラスタの復旧作業として①と②以外に行うことはありますか？
>> 　(※VIP_01はdebug-atartにて強制起動し、PostgreSQLは手動起動しましたが、
>> 　未だ〝stopped〟のままです。)
> ログを確認しないと断定はできませんが、両系でPGSQL.lockファイルが残存している
> 可能性があります。
>
> これは、データが古い可能性があることをユーザに気づかせるための印で、
> Pacemaker(pgsql RA)が正常停止するときのみ削除されます。つまり、異常停止時
> には残存し、異常停止した旨をユーザに気づかせるものです。
> 通常、postgreユーザのホーム配下のtmp/(/var/lib/pgsql/tmp/)にあります。
>
> データ復旧後、またはデータが古い可能性があること承知の上で、当該ノードの
> PostgreSQLを起動する際は、このファイルを手動で削除する必要があります。
>
>
>
> なお、手前味噌になりますが、昨年福岡で開催のオープンソースカンファレンスにて
> PG-REXの故障時の挙動や運用方法をまとめた講演を行いました。
> PostgreSQLプロセス停止後の復旧は、以下P42に掲載しています。
>
> http://linux-ha.osdn.jp/wp/archives/4137
> 　→PG-REXで学ぶPacemaker運用の実例
> 　　　P42 vip-master故障時の復旧方法
>
>
>> ＜確認３＞
>> 　そもそもの話なのですが、クラスタ起動時にVIP付与とPostgreSQL起動が
>> 　されない状態です。(PostgreSQLは手動起動してます)
>> 　設定内容を以下に示すので、不足している設定をご教示願います。
> 構築後、一度きちんと起動しているようなので、設定に問題は無いかと
> 思います。
> ＃STONITH, SFEX, VIPcheck等の排他制御は設定されていないようなので、
> 　スプリットブレイン発生時は両系ノードがMasterになってしまうのが
> 　問題と言えば問題ですが、今回の事象とは関係ないと思います。
> 　排他制御については、以下講演が詳しいです。
> 　　http://linux-ha.osdn.jp/wp/archives/4338
> 　　　→試して覚えるPacemaker入門 排他制御機能編
>
>
> 一度、以下の順に、起動・停止をやりなおしてみてはいかがでしょうか？
> (上記PGSQL.lockや片系ずつ起動、を踏まえた手順案です。)
>
> 　1) 一旦、両系のPacemakerをSlave→Masterの順に片系ずつ停止
> 　2) 一旦、手動起動した両系のPostgreSQLをSlave→Masterの順に片系ずつ停止
> 　3) 両系の/var/lib/pgsql/tmp/PGSQL.lock　を削除
> 　4) さきほどMasterだった方のノードのPacemakerを起動
> 　　 →crm_mon等でPostgreSQLがMasterになることを確認
> 　5) pg_basebackupを実行し、現Masterの最新データをSlaveにコピー
> 　6) SlaveのPacemakerを起動
>
>
> これでも起動しない場合、両系分のPacemakerとPostgreSQLのログを見てみる
> 必要があります。
>
>
> 以上です。
> よろしくお願いいたします。
>
>
> ----- 元のメッセージ -----
> From: "Pacemaker初心者" <m.hiraguchi@freebit.net>
> 宛先: linux-ha-japan@lists.osdn.me
> 送信済み: 2016年1月8日, 金曜日 午後 6:38:26
> 件名: [Linux-ha-jp] クラスタの復旧およびPacemakerの挙動について
>
> お世話になります。
>
> 先般、PG-REXでのPacemaker構築にて上手くいかなかったので、勉強がてら
> pcsコマンドにて再構築を行いました。
>
> [環境]
> OS ：CentOS7.1
> PostgresSQL ：postgresql-server-9.2.13-1
> Pacemaker ：pacemaker-1.1.12-22
>
>
> 構築後に諸々問題点が発生しており、ご助勢頂けると助かります。
> 以下、状況を順に記します。
>
>
> (１)構築後の状況
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
> # crm_mon -Arf -1
> Last updated: Tue Jan 5 21:39:19 2016
> Last change: Tue Jan 5 21:38:46 2016 by hacluster via crmd on zabbix01
> Stack: corosync
> Current DC: zabbix01(1) - partition with quorum
> Version: 1.1.12-561c4cf
> 2 Nodes configured
> 3 Resources configured
>
> Online: [ zabbix01 zabbix02 ]
>
> Full list of resources:
>
> Master/Slave Set: msPostgresql [pgsql]
> Masters: [ zabbix01 ]
> Slaves: [ zabbix02 ]
> Resource Group: master-group
> VIP_01 (ocf::heartbeat:IPaddr2): Started zabbix01
>
> Node Attributes:
> * Node zabbix01:
> + #cluster-name : zabbixcluster
> + #site-name : zabbixcluster
> + master-pgsql : 1000
> + pgsql-data-status : LATEST
> + pgsql-master-baseline : 0000000016000080
> + pgsql-status : PRI
> * Node zabbix02:
> + #cluster-name : zabbixcluster
> + #site-name : zabbixcluster
> + master-pgsql : 100
> + pgsql-data-status : STREAMING|ASYNC
> + pgsql-status : HS:async
>
> Migration summary:
> * Node zabbix02:
> * Node zabbix01:
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>
>
> (２)Slaveへの切替
> 切替テストとして、Zabbix01のPostgresqlを停止しました。
> 停止後のクラスタの状態(下記)としては問題ないと思ってます。
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
> # crm_mon -Arf -1
> Last updated: Wed Jan 6 00:45:32 2016
> Last change: Wed Jan 6 00:30:22 2016 by hacluster via crmd on zabbix01
> Stack: corosync
> Current DC: zabbix01 (1) - partition with quorum
> Version: 1.1.12-561c4cf
> 2 Nodes configured
> 3 Resources configured
>
> Online: [ zabbix01 zabbix02 ]
>
> Full list of resources:
>
> Master/Slave Set: msPostgresql [pgsql]
> Masters: [ zabbix02 ]
> Stopped: [ zabbix01 ]
> Resource Group: master-group
> VIP_01 (ocf::heartbeat:IPaddr2): Started zabbix02p
>
> Node Attributes:
> * Node zabbix01:
> + #cluster-name : zabbixcluster
> + #site-name : zabbixcluster
> + master-pgsql : -INFINITY
> + pgsql-data-status : DISCONNECT
> + pgsql-status : STOP
> * Node zabbix02:
> + #cluster-name : zabbixcluster
> + #site-name : zabbixcluster
> + master-pgsql : 1000
> + pgsql-data-status : LATEST
> + pgsql-master-baseline : 0000000017000080
> + pgsql-status : PRI
>
> Migration summary:
> * Node zabbix02:
> * Node zabbix01:
> pgsql: migration-threshold=1 fail-count=1 last-failure='Wed Jan 6
> 00:30:13 2016'
>
> Failed actions:
> pgsql_monitor_3000 on zabbix01 'unknown error' (1): call=126,
> status=complete, last-rc-change='Wed Jan 6 00:30:13 2016', queued=0ms,
> exec=0ms
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>
>
> (３)
> この後、切戻しを行う際に当方の不手際で、Master(Zabbix01)とSlave(Zabbix02)
> のOS停止をしてしまいました。
> 停止後、両機を起動しましたが、「pcs status」および「crm_mon -Arf -1」
> でのmaster-group(VIP_01)、msPostgresql(pgsql)のリソースのステータスが、
> 〝stopped〟となっていました。
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
> # pcs status
> Cluster name: zabbixcluster
> Last updated: Thr Jan 7 17:11:58 2016
> Last change: Thr Jan 7 15:57:37 2016 by hacluster via crmd on zabbix01
> Stack: corosync
> Current DC: zabbix02 (1) - partition with quorum
> Version: 1.1.12-561c4cf
> 2 Nodes configured
> 3 Resources configured
>
>
> Online: [ zabbix01 zabbix02 ]
>
> Full list of resources:
>
> Master/Slave Set: msPostgresql [pgsql]
> Stopped: [ zabbix01 zabbix02 ]
> Resource Group: master-group
> VIP_01 (ocf::heartbeat:IPaddr2): Stopped
>
> PCSD Status:
> zabbix01 (192.168.252.182): Online
> zabbix02 (192.168.252.183): Online
>
> Daemon Status:
> corosync: active/enabled
> pacemaker: active/enabled
> pcsd: active/enabled
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>
> ＜確認１＞
> 　Slave(新Master)にてフェイルオーバー後の状態を継続するものと想定して
> 　いましたが、OS停止をした場合はこの様な挙動になるのは正しいのでしょうか？
>
>
> (４)復旧
> pg_basebackup、pg_ctl promote等を行い、PostgreSQLの戻しを行いました。
> (※「psql -h localhost -c "SELECT pg_is_in_recovery();"」にて
> 両PostgresSQLの起動状態(Zabbix01：f、Zabbix02：t)と、ストリーミング
> レプリケーションの動作を確認済)
>
> PostgreSQLの状態復旧を行った後に、
> 　①pcs resource cleanup msPostgresqlとpcs resource cleanup master-group
> 　②pcs cluster stop --allとpcs cluster start --all
> にて復旧を試みましたが、両リソースの状態は〝stopped〟のままです。
>
> ＜確認２＞
> 　クラスタの復旧作業として①と②以外に行うことはありますか？
> 　(※VIP_01はdebug-atartにて強制起動し、PostgreSQLは手動起動しましたが、
> 　未だ〝stopped〟のままです。)
>
>
> ＜確認３＞
> 　そもそもの話なのですが、クラスタ起動時にVIP付与とPostgreSQL起動が
> 　されない状態です。(PostgreSQLは手動起動してます)
> 　設定内容を以下に示すので、不足している設定をご教示願います。
>
> ■設定内容
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
> pcs -f cluster_cfg property set no-quorum-policy="ignore"
> pcs -f cluster_cfg property set stonith-enabled="false"
> pcs -f cluster_cfg resource defaults resource-stickiness="INFINITY"
> pcs -f cluster_cfg resource defaults migration-threshold="1"
>
> pcs -f cluster_cfg resource create VIP_01 IPaddr2 \
> ip="192.168.252.184" \
> nic="enp0s3" \
> cidr_netmask="24" \
> op start timeout="60s" interval="0s" on-fail="restart" \
> op monitor timeout="60s" interval="10s" on-fail="restart" \
> op stop timeout="60s" interval="0s" on-fail="block"
>
> pcs -f cluster_cfg resource create pgsql pgsql \
> pgctl="/usr/bin/pg_ctl" \
> psql="/usr/bin/psql" \
> pgdata="/var/lib/pgsql/data/" \
> rep_mode="async" \
> node_list="zabbix01 zabbix02" \
> restore_command="cp /var/lib/pgsql/pg_archive/%f %p" \
> primary_conninfo_opt="keepalives_idle=60 keepalives_interval=5
> keepalives_count=5" \
> master_ip="192.168.252.184" \
> restart_on_promote='true' \
> op start timeout="60s" interval="0s" on-fail="restart" \
> op monitor timeout="60s" interval="4s" on-fail="restart" \
> op monitor timeout="60s" interval="3s" on-fail="restart"
> role="Master" \
> op promote timeout="60s" interval="0s" on-fail="restart" \
> op demote timeout="60s" interval="0s" on-fail="stop" \
> op stop timeout="60s" interval="0s" on-fail="block" \
> op notify timeout="60s" interval="0s"
>
> pcs -f cluster_cfg resource master msPostgresql pgsql \
> master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true
>
> pcs -f cluster_cfg resource group add master-group VIP_01
>
> pcs -f pgsql_cfg constraint colocation add master-group with Master
> msPostgresql INFINITY
> pcs -f pgsql_cfg constraint order promote msPostgresql then start
> master-group symmetrical=false score=INFINITY
> pcs -f pgsql_cfg constraint order demote msPostgresql then stop
> master-group symmetrical=false score=0
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>
> (上記を「pcs cluster cib-push cluster_cfg」にて反映しています)
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan
_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan

ひがし様

毎回ご回答頂きありがとうございます。

■クラスタ切戻し時のPostgresqlの復旧作業
>参考まで、recovery.confはPacemaker(pgsql RA)が自動的に作成するので、
>手動で作成(リネーム)する必要は無いですよ。

⇒そうなんですね。。。了解しました。

■ZabbixServerリソース障害時のクラスタ移動失敗

>思いつく（よくあるケース）で以下２つが考えられます。
>(1)リソース停止失敗していないか？
>ZabbixServer障害は、具体的にはどんな障害でしょうか？

⇒プロセス停止を想定し、「killall |grep zabbix_server」を実施しました。
　※クラスタリソース作成後は、〝systemctl stop zabbix-server〟が
　　効かないので、上記killallにて停止しました。


>今回の設定では、前回回答でも少し触れましたが、STONITH(排他制御)が設定
>されていないようなので、リソースの停止が失敗するケースの故障時は、
>フェイルオーバはできません。
>具体的には、各リソース設定の以下op stop～～行の「on-fail="block"」
>というのが、「リソースの停止に失敗したら、フェイルオーバを中止(block)する」
>ということを示しています。
>　op stop timeout="60s" interval="0s" on-fail="block"
>STONITHを導入し、かつon-fail="fence"と設定すると、リソースの停止失敗時は
>STONITHが発動し、相手ノードの電源を強制的に断した後、フェイルオーバが
>継続します。

⇒上記プロセス停止のケースであれば、zabbixserverリソースのmonitorの内容に
　従うという想定をしております。
　(op monitor timeout="60s" interval="0s" on-fail="restart" \)

　ちなみに、停止時のエラー発生した場合の挙動はSTONITHを使用しないため、、
　op stop timeout="60s" interval="0s" on-fail="block"
　としております。
　※本初期構築時点ではSTONITHは考えておらず、将来的にIPMI関連の整備が完了した
　　時点でSTONITHの導入を考えております。


> (2)フェイルカウントや制約等が残っていないか？
>フェイルオーバ先に、過去、故障や、手動リソース移動でついた制約が
>残ってしまってないでしょうか？
>フェイルカウントは、「crm_mon -rfA」の表示の"Failed actions:"という
>最下部の欄に何か表示があれば、残った状態です。
>残っていると、Pacemakerはこのノードは故障していると判断し、
>リソースは起動しません。

⇒Zabbixプロセス停止実施前のcrm_mon -Arf -1の表示内容からは、
　「Failed actions:」および異常を示す表示はされていません。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
# crm_mon -Arf -1
Last updated: Thu Jan 14 16:47:49 2016 Last change: Thu Jan 14 16:45:38 2016 by root via crm_attribute on com-zabbix01p-pnd-ppp
Stack: corosync
Current DC: com-zabbix01p-pnd-ppp (version 1.1.13-10.el7-44eb2dd) - partition with quorum
2 nodes and 4 resources configured

Online: [ com-zabbix01p-pnd-ppp com-zabbix02p-pnd-ppp ]

Full list of resources:

Master/Slave Set: msGrpPostgresql [PGSQL_01]
Masters: [ com-zabbix01p-pnd-ppp ]
Slaves: [ com-zabbix02p-pnd-ppp ]
Resource Group: GrpVIP
VIP_01 (ocf::heartbeat:IPaddr2): Started com-zabbix01p-pnd-ppp
ZabbixSV (ocf::heartbeat:zabbixserver): Started com-zabbix01p-pnd-ppp

Node Attributes:
* Node com-zabbix01p-pnd-ppp:
+ PGSQL_01-data-status : LATEST
+ PGSQL_01-master-baseline : 00000000140000B8
+ PGSQL_01-status : PRI
+ master-PGSQL_01 : 1000
* Node com-zabbix02p-pnd-ppp:
+ PGSQL_01-data-status : STREAMING|ASYNC
+ PGSQL_01-status : HS:async
+ master-PGSQL_01 : 100

Migration Summary:
* Node com-zabbix02p-pnd-ppp:
* Node com-zabbix01p-pnd-ppp:
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

現クラスタ定義を整理すると、

　①Zabbixserverリソースのオペレーション定義では、
　　moniter　interval=0s　timeout=60s　on-fail=restart
　　(startでもon-fail=restartであり、stopはon-fail=blockである)

　②リソースグループ定義では、
　　・Postgresqlグループでは、Postgresqlリソースのみ含む
　　　(Master/Slaveグループとして作成し、master-max=1、master-node-max=1
　　　、clone-max=2、clone-node-max=1、notify=trueとしている)
　　・VIPグループでは、VIPリソースとZabbixServerリソースの２つのリソースを含む
　　　(priority設定をしていないため、VIPグループ内の起動順序は、
　　　 VIPリソース⇒ZabbixServerリソースという起動になることを想定)

　③同居定義では、
　　Master状態のPostgresqlグループとVIPグループが、INFINITY。

　④起動順序定義では、
　　・Postgresqlグループをpromote⇒VIPグループをstartする。(INFINITY)
　　・Postgresqlグループをdemote⇒VIPグループをstopする。(0(強制せず))

となっています。
Postgresql障害(プロセスダウン)では、Postgresqlリソースが他のリソース起動前提
となっているため、Postgresqlリソースがクラスタ移動すると他のリソースが連動する
こととなり、正常に切り替わると考えてます。

今回のZabbixserver障害(プロセスダウン)を検知し、全リソースを移動(Postgresqlの
切替(移動＆promote)⇒VIPリソース移動⇒Zabbix起動)させる必要があるのですが、
下記定義内容にて不足している定義はありますか？

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
■クラスタ定義
pcs property set no-quorum-policy="ignore"
pcs property set stonith-enabled="false"
pcs resource defaults resource-stickness="INFINITY"
pcs resource defaults migration-threshold="1"

■VIPリソース定義
pcs resource create VIP_01 IPaddr2 \
> ip="192.168.13.125" \
> nic="enp0s3" \
> cidr_netmask="24" \
> op start timeout="60s" interval="0s" on-fail="resstart" \
> op monitor timeout="60s" interval="10s" on-fail="restart" \
> op stop timeout="60s" interval="0s" on-fail="block" \

■PostgreSQLリソース定義
pcs -f /tmp/cluster_cfg resource create PGSQL_01 pgsql \
> pgctl="/usr/bin/pg_ctl" \
> psql="/usr/bin/psql" \
> pgdata="/var/lib/pgsql/data/" \
> rep_mode="async" \
> node_list="zabbix01 zabbix02" \
> restore_command="cp /var/lib/pgsql/pg_arch/arc1/%f %p" \
> primary_conninfo_opt="keepalives_idle=60 keepalives_interval=5 keepalives_count=5" \
> master_ip="192.168.13.125" \
> restart_on_promote='true' \
> repuser="rep_user" \
> start_opt="-i -p 5432" \
> op start timeout="60s" interval="0s" on-fail="restart" \
> op monitor timeout="60s" interval="4s" on-fail="restart" \
> op monitor timeout="60s" interval="3s" on-fail="restart" role="Master" \
> op promote timeout="60s" interval="0s" on-fail="restart" \
> op demote timeout="60s" interval="0s" on-fail="stop" \
> op stop timeout="60s" interval="0s" on-fail="block" \
> op notify timeout="60s" interval="0s"

■同居・起動順序定義
pcs resource master msGrpPostgresql PGSQL_01 \
> master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true
pcs resource group add GrpVIP VIP_01
pcs constraint colocation add GrpVIP with Master msGrpPostgresql
pcs constraint order promote msGrpPostgresql then start GrpVIP symmetrical=false score=INFINITY
pcs constraint order demote msGrpPostgresql then stop GrpVIP symmetrical=false score=0
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

何卒、ご助勢願います。


On 2016/01/15 13:45, kazuh@goo.jp wrote:
> ひがしです。お世話になります。
>
>> ⇒ご指摘の事項およびpg_basebackup、promote、recovery.done⇒recovery.confの
>> リネーム等
>> 　PostgreSQLの(Masterでの)起動条件を整理し復旧しました。
> うまくいったのなら良かったです。
> 参考まで、recovery.confはPacemaker(pgsql RA)が自動的に作成するので、
> 手動で作成(リネーム)する必要は無いですよ。
>
>
>> この内容で、PostgreSQL障害時はSlave(新マスタ)機へ問題なく切り替わりまし
>> たが、
>> ZabbixServer障害時はクラスタリソース全てがMaster、Slave共に停止してしま
>> いました。
> 思いつく（よくあるケース）で以下２つが考えられます。
>
> (1)リソース停止失敗していないか？
> ZabbixServer障害は、具体的にはどんな障害でしょうか？
> 今回の設定では、前回回答でも少し触れましたが、STONITH(排他制御)が設定
> されていないようなので、リソースの停止が失敗するケースの故障時は、
> フェイルオーバはできません。
>
> 具体的には、各リソース設定の以下op stop～～行の「on-fail="block"」
> というのが、「リソースの停止に失敗したら、フェイルオーバを中止(block)する」
> ということを示しています。
> 　op stop timeout="60s" interval="0s" on-fail="block"
>
> STONITHを導入し、かつon-fail="fence"と設定すると、リソースの停止失敗時は
> STONITHが発動し、相手ノードの電源を強制的に断した後、フェイルオーバが
> 継続します。
>
> このあたり、詳細は、前回も紹介の以下資料をご覧ください。
> 　　http://linux-ha.osdn.jp/wp/archives/4338
> 　　　→試して覚えるPacemaker入門 排他制御機能編
>
>
> (2)フェイルカウントや制約等が残っていないか？
> フェイルオーバ先に、過去、故障や、手動リソース移動でついた制約が
> 残ってしまってないでしょうか？
>
> フェイルカウントは、「crm_mon -rfA」の表示の"Failed actions:"という
> 最下部の欄に何か表示があれば、残った状態です。
> 残っていると、Pacemakerはこのノードは故障していると判断し、
> リソースは起動しません。
>
> 前回紹介の以下資料P34の表示例を参考に、残っていればP36のコマンドで
> フェイルカウントを削除してください。
>> http://linux-ha.osdn.jp/wp/archives/4137
>> 　→PG-REXで学ぶPacemaker運用の実例
> また、crm_resource -M -r コマンドでリソースを手動で移動した後、
> 「crm_resource -U -r ＜リソース名＞」を実行していない場合、
> 移動元のノードにはリソースが起動できない制約が残ります。
> (crm_mon -rfAL で確認できます。)
> その場合、「crm_resource -U -r ＜リソース名＞」で制約を消してください。
>
>
>
> さて、上記はあくまでも推測で、今回の事象がそれに該当するかどうかは、
> ログ等を確認しないとわかりません。
> ZabbixServer障害発生時の、「crm_mon -Arf -1」やPacemakerのログ(両系分)が
> あれば、もう少し今回の事象の原因を解析できると思います。
>
>
> 以上です。よろしくお願いいたします。
>
> ----- 元のメッセージ -----
> From: "Pacemaker初心者" <m.hiraguchi@freebit.net>
> 宛先: linux-ha-japan@lists.osdn.me
> 送信済み: 2016年1月14日, 木曜日 午後 8:53:15
> 件名: Re: [Linux-ha-jp] クラスタの復旧およびPacemakerの挙動について
>
> ひがし様
>
> ご回答ありがとうございます。
>
> ＜確認１のご回答＞
>> PG-REXでは、Pacemaker起動をMasterになってほしいノードから片方ずつ行い、
>> そのPacemakerが完全に起動し、PostgreSQLがMasterになったことを確認してから、
>> もう片方を起動する、というように起動する必要があります。
>> Pacemakerからすると、2ノード同時に起動された場合、どちらのノードを優先して
>> Masterにすべきか判断できないためです。
>> 今回の場合、Slave(新Master)のみを先に起動すれば、きちんとMasterになったかと
>> 思います。
> ⇒本ケースの再現がありましたので、Slave(新Master)機⇒Master(新Slave)機の順で、
> 　クラスタ起動を行いました。
>
> ＜確認２のご回答＞
>> ログを確認しないと断定はできませんが、両系でPGSQL.lockファイルが残存している
>> 可能性があります。
>> これは、データが古い可能性があることをユーザに気づかせるための印で、
>> Pacemaker(pgsql RA)が正常停止するときのみ削除されます。つまり、異常停止時
>> には残存し、異常停止した旨をユーザに気づかせるものです。
>> 通常、postgreユーザのホーム配下のtmp/(/var/lib/pgsql/tmp/)にあります。
>> データ復旧後、またはデータが古い可能性があること承知の上で、当該ノードの
>> PostgreSQLを起動する際は、このファイルを手動で削除する必要があります
> ⇒ご指摘の事項およびpg_basebackup、promote、recovery.done⇒recovery.confの
> リネーム等
> 　PostgreSQLの(Masterでの)起動条件を整理し復旧しました。
>
> ＜確認３のご回答＞
>> 構築後、一度きちんと起動しているようなので、設定に問題は無いかと
>> 思います。
>> ＃STONITH, SFEX, VIPcheck等の排他制御は設定されていないようなので、
>> 　スプリットブレイン発生時は両系ノードがMasterになってしまうのが
>> 　問題と言えば問題ですが、今回の事象とは関係ないと思います。
> ⇒クラスタ起動に連動し、PostgreSQLが起動するようになりました。
> 　※関係ないかもしれませんが、前回との変更点は、PostgreSQLリソースに
> 　「start_option="-i -p 5432"」の追加です。
>
>
> ■新たな確認事項
> 　VIP、PostgreSQLのクラスタリソースおよびグループ以外のリソース(Zabbix)
> を追加しました。
>
> 　■zabbixリソースの作成内容
> # pcs resource create ZabbixSV zabbixserver \
> > binary="/usr/sbin/zabbix_server" \
> > pid="/var/run/zabbix/zabbix_server.pid" \
> > config="/etc/zabbix/zabbix_server.conf" \
> > op start timeout="60s" interval="0s" on-fail="restart" \
> > op monitor timeout="60s" interval="0s" on-fail="restart" \
> > op stop timeout="60s" interval="0s" on-fail="block"
>
> 　■zabbixリソースのグループ登録(VIPリソースグループへの追加)
> # pcs resource group add GrpVIP ZabbixSV
> # pcs resource group list
> GrpVIP: VIP_01 ZabbixSV
>
>
> ※フェイルオーバー時の起動順序は、
> 　　①PostgreSQLのPromote
> 　　②VIP付与
> 　　③ZabbixServer起動
> 　を想定しています。
>
> この内容で、PostgreSQL障害時はSlave(新マスタ)機へ問題なく切り替わりまし
> たが、
> ZabbixServer障害時はクラスタリソース全てがMaster、Slave共に停止してしま
> いました。
>
> PostgreSQLに依存するクラスタリソースの登録について
> ご教示願います。
>
> ご助勢の程、宜しくお願い致します。
>
>
>
> On 2016/01/14 13:48, kazuh@goo.jp wrote:
>> ひがしと申します。
>> お世話になります。
>>
>>
>>> ＜確認１＞
>>> 　Slave(新Master)にてフェイルオーバー後の状態を継続するものと想定して
>>> 　いましたが、OS停止をした場合はこの様な挙動になるのは正しいのでしょうか？
>> PG-REXでは、Pacemaker起動をMasterになってほしいノードから片方ずつ行い、
>> そのPacemakerが完全に起動し、PostgreSQLがMasterになったことを確認してから、
>> もう片方を起動する、というように起動する必要があります。
>> Pacemakerからすると、2ノード同時に起動された場合、どちらのノードを優先して
>> Masterにすべきか判断できないためです。
>>
>> 今回の場合、Slave(新Master)のみを先に起動すれば、きちんとMasterになったかと
>> 思います。
>>
>>
>>> ＜確認２＞
>>> 　クラスタの復旧作業として①と②以外に行うことはありますか？
>>> 　(※VIP_01はdebug-atartにて強制起動し、PostgreSQLは手動起動しましたが、
>>> 　未だ〝stopped〟のままです。)
>> ログを確認しないと断定はできませんが、両系でPGSQL.lockファイルが残存している
>> 可能性があります。
>>
>> これは、データが古い可能性があることをユーザに気づかせるための印で、
>> Pacemaker(pgsql RA)が正常停止するときのみ削除されます。つまり、異常停止時
>> には残存し、異常停止した旨をユーザに気づかせるものです。
>> 通常、postgreユーザのホーム配下のtmp/(/var/lib/pgsql/tmp/)にあります。
>>
>> データ復旧後、またはデータが古い可能性があること承知の上で、当該ノードの
>> PostgreSQLを起動する際は、このファイルを手動で削除する必要があります。
>>
>>
>>
>> なお、手前味噌になりますが、昨年福岡で開催のオープンソースカンファレンスにて
>> PG-REXの故障時の挙動や運用方法をまとめた講演を行いました。
>> PostgreSQLプロセス停止後の復旧は、以下P42に掲載しています。
>>
>> http://linux-ha.osdn.jp/wp/archives/4137
>> 　→PG-REXで学ぶPacemaker運用の実例
>> 　　　P42 vip-master故障時の復旧方法
>>
>>
>>> ＜確認３＞
>>> 　そもそもの話なのですが、クラスタ起動時にVIP付与とPostgreSQL起動が
>>> 　されない状態です。(PostgreSQLは手動起動してます)
>>> 　設定内容を以下に示すので、不足している設定をご教示願います。
>> 構築後、一度きちんと起動しているようなので、設定に問題は無いかと
>> 思います。
>> ＃STONITH, SFEX, VIPcheck等の排他制御は設定されていないようなので、
>> 　スプリットブレイン発生時は両系ノードがMasterになってしまうのが
>> 　問題と言えば問題ですが、今回の事象とは関係ないと思います。
>> 　排他制御については、以下講演が詳しいです。
>> 　　http://linux-ha.osdn.jp/wp/archives/4338
>> 　　　→試して覚えるPacemaker入門 排他制御機能編
>>
>>
>> 一度、以下の順に、起動・停止をやりなおしてみてはいかがでしょうか？
>> (上記PGSQL.lockや片系ずつ起動、を踏まえた手順案です。)
>>
>> 　1) 一旦、両系のPacemakerをSlave→Masterの順に片系ずつ停止
>> 　2) 一旦、手動起動した両系のPostgreSQLをSlave→Masterの順に片系ずつ停止
>> 　3) 両系の/var/lib/pgsql/tmp/PGSQL.lock　を削除
>> 　4) さきほどMasterだった方のノードのPacemakerを起動
>> 　　 →crm_mon等でPostgreSQLがMasterになることを確認
>> 　5) pg_basebackupを実行し、現Masterの最新データをSlaveにコピー
>> 　6) SlaveのPacemakerを起動
>>
>>
>> これでも起動しない場合、両系分のPacemakerとPostgreSQLのログを見てみる
>> 必要があります。
>>
>>
>> 以上です。
>> よろしくお願いいたします。
>>
>>
>> ----- 元のメッセージ -----
>> From: "Pacemaker初心者" <m.hiraguchi@freebit.net>
>> 宛先: linux-ha-japan@lists.osdn.me
>> 送信済み: 2016年1月8日, 金曜日 午後 6:38:26
>> 件名: [Linux-ha-jp] クラスタの復旧およびPacemakerの挙動について
>>
>> お世話になります。
>>
>> 先般、PG-REXでのPacemaker構築にて上手くいかなかったので、勉強がてら
>> pcsコマンドにて再構築を行いました。
>>
>> [環境]
>> OS ：CentOS7.1
>> PostgresSQL ：postgresql-server-9.2.13-1
>> Pacemaker ：pacemaker-1.1.12-22
>>
>>
>> 構築後に諸々問題点が発生しており、ご助勢頂けると助かります。
>> 以下、状況を順に記します。
>>
>>
>> (１)構築後の状況
>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>> # crm_mon -Arf -1
>> Last updated: Tue Jan 5 21:39:19 2016
>> Last change: Tue Jan 5 21:38:46 2016 by hacluster via crmd on zabbix01
>> Stack: corosync
>> Current DC: zabbix01(1) - partition with quorum
>> Version: 1.1.12-561c4cf
>> 2 Nodes configured
>> 3 Resources configured
>>
>> Online: [ zabbix01 zabbix02 ]
>>
>> Full list of resources:
>>
>> Master/Slave Set: msPostgresql [pgsql]
>> Masters: [ zabbix01 ]
>> Slaves: [ zabbix02 ]
>> Resource Group: master-group
>> VIP_01 (ocf::heartbeat:IPaddr2): Started zabbix01
>>
>> Node Attributes:
>> * Node zabbix01:
>> + #cluster-name : zabbixcluster
>> + #site-name : zabbixcluster
>> + master-pgsql : 1000
>> + pgsql-data-status : LATEST
>> + pgsql-master-baseline : 0000000016000080
>> + pgsql-status : PRI
>> * Node zabbix02:
>> + #cluster-name : zabbixcluster
>> + #site-name : zabbixcluster
>> + master-pgsql : 100
>> + pgsql-data-status : STREAMING|ASYNC
>> + pgsql-status : HS:async
>>
>> Migration summary:
>> * Node zabbix02:
>> * Node zabbix01:
>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>
>>
>> (２)Slaveへの切替
>> 切替テストとして、Zabbix01のPostgresqlを停止しました。
>> 停止後のクラスタの状態(下記)としては問題ないと思ってます。
>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>> # crm_mon -Arf -1
>> Last updated: Wed Jan 6 00:45:32 2016
>> Last change: Wed Jan 6 00:30:22 2016 by hacluster via crmd on zabbix01
>> Stack: corosync
>> Current DC: zabbix01 (1) - partition with quorum
>> Version: 1.1.12-561c4cf
>> 2 Nodes configured
>> 3 Resources configured
>>
>> Online: [ zabbix01 zabbix02 ]
>>
>> Full list of resources:
>>
>> Master/Slave Set: msPostgresql [pgsql]
>> Masters: [ zabbix02 ]
>> Stopped: [ zabbix01 ]
>> Resource Group: master-group
>> VIP_01 (ocf::heartbeat:IPaddr2): Started zabbix02p
>>
>> Node Attributes:
>> * Node zabbix01:
>> + #cluster-name : zabbixcluster
>> + #site-name : zabbixcluster
>> + master-pgsql : -INFINITY
>> + pgsql-data-status : DISCONNECT
>> + pgsql-status : STOP
>> * Node zabbix02:
>> + #cluster-name : zabbixcluster
>> + #site-name : zabbixcluster
>> + master-pgsql : 1000
>> + pgsql-data-status : LATEST
>> + pgsql-master-baseline : 0000000017000080
>> + pgsql-status : PRI
>>
>> Migration summary:
>> * Node zabbix02:
>> * Node zabbix01:
>> pgsql: migration-threshold=1 fail-count=1 last-failure='Wed Jan 6
>> 00:30:13 2016'
>>
>> Failed actions:
>> pgsql_monitor_3000 on zabbix01 'unknown error' (1): call=126,
>> status=complete, last-rc-change='Wed Jan 6 00:30:13 2016', queued=0ms,
>> exec=0ms
>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>
>>
>> (３)
>> この後、切戻しを行う際に当方の不手際で、Master(Zabbix01)とSlave(Zabbix02)
>> のOS停止をしてしまいました。
>> 停止後、両機を起動しましたが、「pcs status」および「crm_mon -Arf -1」
>> でのmaster-group(VIP_01)、msPostgresql(pgsql)のリソースのステータスが、
>> 〝stopped〟となっていました。
>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>> # pcs status
>> Cluster name: zabbixcluster
>> Last updated: Thr Jan 7 17:11:58 2016
>> Last change: Thr Jan 7 15:57:37 2016 by hacluster via crmd on zabbix01
>> Stack: corosync
>> Current DC: zabbix02 (1) - partition with quorum
>> Version: 1.1.12-561c4cf
>> 2 Nodes configured
>> 3 Resources configured
>>
>>
>> Online: [ zabbix01 zabbix02 ]
>>
>> Full list of resources:
>>
>> Master/Slave Set: msPostgresql [pgsql]
>> Stopped: [ zabbix01 zabbix02 ]
>> Resource Group: master-group
>> VIP_01 (ocf::heartbeat:IPaddr2): Stopped
>>
>> PCSD Status:
>> zabbix01 (192.168.252.182): Online
>> zabbix02 (192.168.252.183): Online
>>
>> Daemon Status:
>> corosync: active/enabled
>> pacemaker: active/enabled
>> pcsd: active/enabled
>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>
>> ＜確認１＞
>> 　Slave(新Master)にてフェイルオーバー後の状態を継続するものと想定して
>> 　いましたが、OS停止をした場合はこの様な挙動になるのは正しいのでしょうか？
>>
>>
>> (４)復旧
>> pg_basebackup、pg_ctl promote等を行い、PostgreSQLの戻しを行いました。
>> (※「psql -h localhost -c "SELECT pg_is_in_recovery();"」にて
>> 両PostgresSQLの起動状態(Zabbix01：f、Zabbix02：t)と、ストリーミング
>> レプリケーションの動作を確認済)
>>
>> PostgreSQLの状態復旧を行った後に、
>> 　①pcs resource cleanup msPostgresqlとpcs resource cleanup master-group
>> 　②pcs cluster stop --allとpcs cluster start --all
>> にて復旧を試みましたが、両リソースの状態は〝stopped〟のままです。
>>
>> ＜確認２＞
>> 　クラスタの復旧作業として①と②以外に行うことはありますか？
>> 　(※VIP_01はdebug-atartにて強制起動し、PostgreSQLは手動起動しましたが、
>> 　未だ〝stopped〟のままです。)
>>
>>
>> ＜確認３＞
>> 　そもそもの話なのですが、クラスタ起動時にVIP付与とPostgreSQL起動が
>> 　されない状態です。(PostgreSQLは手動起動してます)
>> 　設定内容を以下に示すので、不足している設定をご教示願います。
>>
>> ■設定内容
>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>> pcs -f cluster_cfg property set no-quorum-policy="ignore"
>> pcs -f cluster_cfg property set stonith-enabled="false"
>> pcs -f cluster_cfg resource defaults resource-stickiness="INFINITY"
>> pcs -f cluster_cfg resource defaults migration-threshold="1"
>>
>> pcs -f cluster_cfg resource create VIP_01 IPaddr2 \
>> ip="192.168.252.184" \
>> nic="enp0s3" \
>> cidr_netmask="24" \
>> op start timeout="60s" interval="0s" on-fail="restart" \
>> op monitor timeout="60s" interval="10s" on-fail="restart" \
>> op stop timeout="60s" interval="0s" on-fail="block"
>>
>> pcs -f cluster_cfg resource create pgsql pgsql \
>> pgctl="/usr/bin/pg_ctl" \
>> psql="/usr/bin/psql" \
>> pgdata="/var/lib/pgsql/data/" \
>> rep_mode="async" \
>> node_list="zabbix01 zabbix02" \
>> restore_command="cp /var/lib/pgsql/pg_archive/%f %p" \
>> primary_conninfo_opt="keepalives_idle=60 keepalives_interval=5
>> keepalives_count=5" \
>> master_ip="192.168.252.184" \
>> restart_on_promote='true' \
>> op start timeout="60s" interval="0s" on-fail="restart" \
>> op monitor timeout="60s" interval="4s" on-fail="restart" \
>> op monitor timeout="60s" interval="3s" on-fail="restart"
>> role="Master" \
>> op promote timeout="60s" interval="0s" on-fail="restart" \
>> op demote timeout="60s" interval="0s" on-fail="stop" \
>> op stop timeout="60s" interval="0s" on-fail="block" \
>> op notify timeout="60s" interval="0s"
>>
>> pcs -f cluster_cfg resource master msPostgresql pgsql \
>> master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true
>>
>> pcs -f cluster_cfg resource group add master-group VIP_01
>>
>> pcs -f pgsql_cfg constraint colocation add master-group with Master
>> msPostgresql INFINITY
>> pcs -f pgsql_cfg constraint order promote msPostgresql then start
>> master-group symmetrical=false score=INFINITY
>> pcs -f pgsql_cfg constraint order demote msPostgresql then stop
>> master-group symmetrical=false score=0
>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>
>> (上記を「pcs cluster cib-push cluster_cfg」にて反映しています)
>>
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan

ひがしです。お世話になります。

それでは、故障時に何が起きていたのかを見たいので、以下情報を
いただけますか？

・Zabbixプロセス停止実施"後"のcrm_mon -Arf -1の表示内容
　(両系分)

・Zabbixプロセス停止前後の時間帯を含んだPacemakerのログ
　(両系分)
　・・・設定次第でファイル名は異なりますが通常、
　　　　/var/log/messagesや/var/log/ha-log。

・Zabbix故障後、Pacemakerが稼働しているノードで以下コマンドを実行し、
　生成された/tmp/cib.xml。
　(Pacemakerに設定のリソース設定や属性値の内容等が含まれます。)
　# cibadmin -Q > /tmp/cib.xml


以上です。
よろしくお願い致します。

----- 元のメッセージ -----
From: "Pacemaker初心者" <m.hiraguchi@freebit.net>
宛先: linux-ha-japan@lists.osdn.me
送信済み: 2016年1月15日, 金曜日 午後 6:16:58
件名: Re: [Linux-ha-jp] クラスタの復旧およびPacemakerの挙動について

ひがし様

毎回ご回答頂きありがとうございます。

■クラスタ切戻し時のPostgresqlの復旧作業
>参考まで、recovery.confはPacemaker(pgsql RA)が自動的に作成するので、
>手動で作成(リネーム)する必要は無いですよ。

⇒そうなんですね。。。了解しました。

■ZabbixServerリソース障害時のクラスタ移動失敗

>思いつく（よくあるケース）で以下２つが考えられます。
>(1)リソース停止失敗していないか？
>ZabbixServer障害は、具体的にはどんな障害でしょうか？

⇒プロセス停止を想定し、「killall |grep zabbix_server」を実施しました。
　※クラスタリソース作成後は、〝systemctl stop zabbix-server〟が
　　効かないので、上記killallにて停止しました。


>今回の設定では、前回回答でも少し触れましたが、STONITH(排他制御)が設定
>されていないようなので、リソースの停止が失敗するケースの故障時は、
>フェイルオーバはできません。
>具体的には、各リソース設定の以下op stop～～行の「on-fail="block"」
>というのが、「リソースの停止に失敗したら、フェイルオーバを中止(block)する」
>ということを示しています。
>　op stop timeout="60s" interval="0s" on-fail="block"
>STONITHを導入し、かつon-fail="fence"と設定すると、リソースの停止失敗時は
>STONITHが発動し、相手ノードの電源を強制的に断した後、フェイルオーバが
>継続します。

⇒上記プロセス停止のケースであれば、zabbixserverリソースのmonitorの内容に
　従うという想定をしております。
　(op monitor timeout="60s" interval="0s" on-fail="restart" \)

　ちなみに、停止時のエラー発生した場合の挙動はSTONITHを使用しないため、、
　op stop timeout="60s" interval="0s" on-fail="block"
　としております。
　※本初期構築時点ではSTONITHは考えておらず、将来的にIPMI関連の整備が完了した
　　時点でSTONITHの導入を考えております。


> (2)フェイルカウントや制約等が残っていないか？
>フェイルオーバ先に、過去、故障や、手動リソース移動でついた制約が
>残ってしまってないでしょうか？
>フェイルカウントは、「crm_mon -rfA」の表示の"Failed actions:"という
>最下部の欄に何か表示があれば、残った状態です。
>残っていると、Pacemakerはこのノードは故障していると判断し、
>リソースは起動しません。

⇒Zabbixプロセス停止実施前のcrm_mon -Arf -1の表示内容からは、
　「Failed actions:」および異常を示す表示はされていません。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
# crm_mon -Arf -1
Last updated: Thu Jan 14 16:47:49 2016 Last change: Thu Jan 14 16:45:38 2016 by root via crm_attribute on com-zabbix01p-pnd-ppp
Stack: corosync
Current DC: com-zabbix01p-pnd-ppp (version 1.1.13-10.el7-44eb2dd) - partition with quorum
2 nodes and 4 resources configured

Online: [ com-zabbix01p-pnd-ppp com-zabbix02p-pnd-ppp ]

Full list of resources:

Master/Slave Set: msGrpPostgresql [PGSQL_01]
Masters: [ com-zabbix01p-pnd-ppp ]
Slaves: [ com-zabbix02p-pnd-ppp ]
Resource Group: GrpVIP
VIP_01 (ocf::heartbeat:IPaddr2): Started com-zabbix01p-pnd-ppp
ZabbixSV (ocf::heartbeat:zabbixserver): Started com-zabbix01p-pnd-ppp

Node Attributes:
* Node com-zabbix01p-pnd-ppp:
+ PGSQL_01-data-status : LATEST
+ PGSQL_01-master-baseline : 00000000140000B8
+ PGSQL_01-status : PRI
+ master-PGSQL_01 : 1000
* Node com-zabbix02p-pnd-ppp:
+ PGSQL_01-data-status : STREAMING|ASYNC
+ PGSQL_01-status : HS:async
+ master-PGSQL_01 : 100

Migration Summary:
* Node com-zabbix02p-pnd-ppp:
* Node com-zabbix01p-pnd-ppp:
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

現クラスタ定義を整理すると、

　①Zabbixserverリソースのオペレーション定義では、
　　moniter　interval=0s　timeout=60s　on-fail=restart
　　(startでもon-fail=restartであり、stopはon-fail=blockである)

　②リソースグループ定義では、
　　・Postgresqlグループでは、Postgresqlリソースのみ含む
　　　(Master/Slaveグループとして作成し、master-max=1、master-node-max=1
　　　、clone-max=2、clone-node-max=1、notify=trueとしている)
　　・VIPグループでは、VIPリソースとZabbixServerリソースの２つのリソースを含む
　　　(priority設定をしていないため、VIPグループ内の起動順序は、
　　　 VIPリソース⇒ZabbixServerリソースという起動になることを想定)

　③同居定義では、
　　Master状態のPostgresqlグループとVIPグループが、INFINITY。

　④起動順序定義では、
　　・Postgresqlグループをpromote⇒VIPグループをstartする。(INFINITY)
　　・Postgresqlグループをdemote⇒VIPグループをstopする。(0(強制せず))

となっています。
Postgresql障害(プロセスダウン)では、Postgresqlリソースが他のリソース起動前提
となっているため、Postgresqlリソースがクラスタ移動すると他のリソースが連動する
こととなり、正常に切り替わると考えてます。

今回のZabbixserver障害(プロセスダウン)を検知し、全リソースを移動(Postgresqlの
切替(移動＆promote)⇒VIPリソース移動⇒Zabbix起動)させる必要があるのですが、
下記定義内容にて不足している定義はありますか？

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
■クラスタ定義
pcs property set no-quorum-policy="ignore"
pcs property set stonith-enabled="false"
pcs resource defaults resource-stickness="INFINITY"
pcs resource defaults migration-threshold="1"

■VIPリソース定義
pcs resource create VIP_01 IPaddr2 \
> ip="192.168.13.125" \
> nic="enp0s3" \
> cidr_netmask="24" \
> op start timeout="60s" interval="0s" on-fail="resstart" \
> op monitor timeout="60s" interval="10s" on-fail="restart" \
> op stop timeout="60s" interval="0s" on-fail="block" \

■PostgreSQLリソース定義
pcs -f /tmp/cluster_cfg resource create PGSQL_01 pgsql \
> pgctl="/usr/bin/pg_ctl" \
> psql="/usr/bin/psql" \
> pgdata="/var/lib/pgsql/data/" \
> rep_mode="async" \
> node_list="zabbix01 zabbix02" \
> restore_command="cp /var/lib/pgsql/pg_arch/arc1/%f %p" \
> primary_conninfo_opt="keepalives_idle=60 keepalives_interval=5 keepalives_count=5" \
> master_ip="192.168.13.125" \
> restart_on_promote='true' \
> repuser="rep_user" \
> start_opt="-i -p 5432" \
> op start timeout="60s" interval="0s" on-fail="restart" \
> op monitor timeout="60s" interval="4s" on-fail="restart" \
> op monitor timeout="60s" interval="3s" on-fail="restart" role="Master" \
> op promote timeout="60s" interval="0s" on-fail="restart" \
> op demote timeout="60s" interval="0s" on-fail="stop" \
> op stop timeout="60s" interval="0s" on-fail="block" \
> op notify timeout="60s" interval="0s"

■同居・起動順序定義
pcs resource master msGrpPostgresql PGSQL_01 \
> master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true
pcs resource group add GrpVIP VIP_01
pcs constraint colocation add GrpVIP with Master msGrpPostgresql
pcs constraint order promote msGrpPostgresql then start GrpVIP symmetrical=false score=INFINITY
pcs constraint order demote msGrpPostgresql then stop GrpVIP symmetrical=false score=0
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

何卒、ご助勢願います。


On 2016/01/15 13:45, kazuh@goo.jp wrote:
> ひがしです。お世話になります。
>
>> ⇒ご指摘の事項およびpg_basebackup、promote、recovery.done⇒recovery.confの
>> リネーム等
>> 　PostgreSQLの(Masterでの)起動条件を整理し復旧しました。
> うまくいったのなら良かったです。
> 参考まで、recovery.confはPacemaker(pgsql RA)が自動的に作成するので、
> 手動で作成(リネーム)する必要は無いですよ。
>
>
>> この内容で、PostgreSQL障害時はSlave(新マスタ)機へ問題なく切り替わりまし
>> たが、
>> ZabbixServer障害時はクラスタリソース全てがMaster、Slave共に停止してしま
>> いました。
> 思いつく（よくあるケース）で以下２つが考えられます。
>
> (1)リソース停止失敗していないか？
> ZabbixServer障害は、具体的にはどんな障害でしょうか？
> 今回の設定では、前回回答でも少し触れましたが、STONITH(排他制御)が設定
> されていないようなので、リソースの停止が失敗するケースの故障時は、
> フェイルオーバはできません。
>
> 具体的には、各リソース設定の以下op stop～～行の「on-fail="block"」
> というのが、「リソースの停止に失敗したら、フェイルオーバを中止(block)する」
> ということを示しています。
> 　op stop timeout="60s" interval="0s" on-fail="block"
>
> STONITHを導入し、かつon-fail="fence"と設定すると、リソースの停止失敗時は
> STONITHが発動し、相手ノードの電源を強制的に断した後、フェイルオーバが
> 継続します。
>
> このあたり、詳細は、前回も紹介の以下資料をご覧ください。
> 　　http://linux-ha.osdn.jp/wp/archives/4338
> 　　　→試して覚えるPacemaker入門 排他制御機能編
>
>
> (2)フェイルカウントや制約等が残っていないか？
> フェイルオーバ先に、過去、故障や、手動リソース移動でついた制約が
> 残ってしまってないでしょうか？
>
> フェイルカウントは、「crm_mon -rfA」の表示の"Failed actions:"という
> 最下部の欄に何か表示があれば、残った状態です。
> 残っていると、Pacemakerはこのノードは故障していると判断し、
> リソースは起動しません。
>
> 前回紹介の以下資料P34の表示例を参考に、残っていればP36のコマンドで
> フェイルカウントを削除してください。
>> http://linux-ha.osdn.jp/wp/archives/4137
>> 　→PG-REXで学ぶPacemaker運用の実例
> また、crm_resource -M -r コマンドでリソースを手動で移動した後、
> 「crm_resource -U -r ＜リソース名＞」を実行していない場合、
> 移動元のノードにはリソースが起動できない制約が残ります。
> (crm_mon -rfAL で確認できます。)
> その場合、「crm_resource -U -r ＜リソース名＞」で制約を消してください。
>
>
>
> さて、上記はあくまでも推測で、今回の事象がそれに該当するかどうかは、
> ログ等を確認しないとわかりません。
> ZabbixServer障害発生時の、「crm_mon -Arf -1」やPacemakerのログ(両系分)が
> あれば、もう少し今回の事象の原因を解析できると思います。
>
>
> 以上です。よろしくお願いいたします。
>
> ----- 元のメッセージ -----
> From: "Pacemaker初心者" <m.hiraguchi@freebit.net>
> 宛先: linux-ha-japan@lists.osdn.me
> 送信済み: 2016年1月14日, 木曜日 午後 8:53:15
> 件名: Re: [Linux-ha-jp] クラスタの復旧およびPacemakerの挙動について
>
> ひがし様
>
> ご回答ありがとうございます。
>
> ＜確認１のご回答＞
>> PG-REXでは、Pacemaker起動をMasterになってほしいノードから片方ずつ行い、
>> そのPacemakerが完全に起動し、PostgreSQLがMasterになったことを確認してから、
>> もう片方を起動する、というように起動する必要があります。
>> Pacemakerからすると、2ノード同時に起動された場合、どちらのノードを優先して
>> Masterにすべきか判断できないためです。
>> 今回の場合、Slave(新Master)のみを先に起動すれば、きちんとMasterになったかと
>> 思います。
> ⇒本ケースの再現がありましたので、Slave(新Master)機⇒Master(新Slave)機の順で、
> 　クラスタ起動を行いました。
>
> ＜確認２のご回答＞
>> ログを確認しないと断定はできませんが、両系でPGSQL.lockファイルが残存している
>> 可能性があります。
>> これは、データが古い可能性があることをユーザに気づかせるための印で、
>> Pacemaker(pgsql RA)が正常停止するときのみ削除されます。つまり、異常停止時
>> には残存し、異常停止した旨をユーザに気づかせるものです。
>> 通常、postgreユーザのホーム配下のtmp/(/var/lib/pgsql/tmp/)にあります。
>> データ復旧後、またはデータが古い可能性があること承知の上で、当該ノードの
>> PostgreSQLを起動する際は、このファイルを手動で削除する必要があります
> ⇒ご指摘の事項およびpg_basebackup、promote、recovery.done⇒recovery.confの
> リネーム等
> 　PostgreSQLの(Masterでの)起動条件を整理し復旧しました。
>
> ＜確認３のご回答＞
>> 構築後、一度きちんと起動しているようなので、設定に問題は無いかと
>> 思います。
>> ＃STONITH, SFEX, VIPcheck等の排他制御は設定されていないようなので、
>> 　スプリットブレイン発生時は両系ノードがMasterになってしまうのが
>> 　問題と言えば問題ですが、今回の事象とは関係ないと思います。
> ⇒クラスタ起動に連動し、PostgreSQLが起動するようになりました。
> 　※関係ないかもしれませんが、前回との変更点は、PostgreSQLリソースに
> 　「start_option="-i -p 5432"」の追加です。
>
>
> ■新たな確認事項
> 　VIP、PostgreSQLのクラスタリソースおよびグループ以外のリソース(Zabbix)
> を追加しました。
>
> 　■zabbixリソースの作成内容
> # pcs resource create ZabbixSV zabbixserver \
> > binary="/usr/sbin/zabbix_server" \
> > pid="/var/run/zabbix/zabbix_server.pid" \
> > config="/etc/zabbix/zabbix_server.conf" \
> > op start timeout="60s" interval="0s" on-fail="restart" \
> > op monitor timeout="60s" interval="0s" on-fail="restart" \
> > op stop timeout="60s" interval="0s" on-fail="block"
>
> 　■zabbixリソースのグループ登録(VIPリソースグループへの追加)
> # pcs resource group add GrpVIP ZabbixSV
> # pcs resource group list
> GrpVIP: VIP_01 ZabbixSV
>
>
> ※フェイルオーバー時の起動順序は、
> 　　①PostgreSQLのPromote
> 　　②VIP付与
> 　　③ZabbixServer起動
> 　を想定しています。
>
> この内容で、PostgreSQL障害時はSlave(新マスタ)機へ問題なく切り替わりまし
> たが、
> ZabbixServer障害時はクラスタリソース全てがMaster、Slave共に停止してしま
> いました。
>
> PostgreSQLに依存するクラスタリソースの登録について
> ご教示願います。
>
> ご助勢の程、宜しくお願い致します。
>
>
>
> On 2016/01/14 13:48, kazuh@goo.jp wrote:
>> ひがしと申します。
>> お世話になります。
>>
>>
>>> ＜確認１＞
>>> 　Slave(新Master)にてフェイルオーバー後の状態を継続するものと想定して
>>> 　いましたが、OS停止をした場合はこの様な挙動になるのは正しいのでしょうか？
>> PG-REXでは、Pacemaker起動をMasterになってほしいノードから片方ずつ行い、
>> そのPacemakerが完全に起動し、PostgreSQLがMasterになったことを確認してから、
>> もう片方を起動する、というように起動する必要があります。
>> Pacemakerからすると、2ノード同時に起動された場合、どちらのノードを優先して
>> Masterにすべきか判断できないためです。
>>
>> 今回の場合、Slave(新Master)のみを先に起動すれば、きちんとMasterになったかと
>> 思います。
>>
>>
>>> ＜確認２＞
>>> 　クラスタの復旧作業として①と②以外に行うことはありますか？
>>> 　(※VIP_01はdebug-atartにて強制起動し、PostgreSQLは手動起動しましたが、
>>> 　未だ〝stopped〟のままです。)
>> ログを確認しないと断定はできませんが、両系でPGSQL.lockファイルが残存している
>> 可能性があります。
>>
>> これは、データが古い可能性があることをユーザに気づかせるための印で、
>> Pacemaker(pgsql RA)が正常停止するときのみ削除されます。つまり、異常停止時
>> には残存し、異常停止した旨をユーザに気づかせるものです。
>> 通常、postgreユーザのホーム配下のtmp/(/var/lib/pgsql/tmp/)にあります。
>>
>> データ復旧後、またはデータが古い可能性があること承知の上で、当該ノードの
>> PostgreSQLを起動する際は、このファイルを手動で削除する必要があります。
>>
>>
>>
>> なお、手前味噌になりますが、昨年福岡で開催のオープンソースカンファレンスにて
>> PG-REXの故障時の挙動や運用方法をまとめた講演を行いました。
>> PostgreSQLプロセス停止後の復旧は、以下P42に掲載しています。
>>
>> http://linux-ha.osdn.jp/wp/archives/4137
>> 　→PG-REXで学ぶPacemaker運用の実例
>> 　　　P42 vip-master故障時の復旧方法
>>
>>
>>> ＜確認３＞
>>> 　そもそもの話なのですが、クラスタ起動時にVIP付与とPostgreSQL起動が
>>> 　されない状態です。(PostgreSQLは手動起動してます)
>>> 　設定内容を以下に示すので、不足している設定をご教示願います。
>> 構築後、一度きちんと起動しているようなので、設定に問題は無いかと
>> 思います。
>> ＃STONITH, SFEX, VIPcheck等の排他制御は設定されていないようなので、
>> 　スプリットブレイン発生時は両系ノードがMasterになってしまうのが
>> 　問題と言えば問題ですが、今回の事象とは関係ないと思います。
>> 　排他制御については、以下講演が詳しいです。
>> 　　http://linux-ha.osdn.jp/wp/archives/4338
>> 　　　→試して覚えるPacemaker入門 排他制御機能編
>>
>>
>> 一度、以下の順に、起動・停止をやりなおしてみてはいかがでしょうか？
>> (上記PGSQL.lockや片系ずつ起動、を踏まえた手順案です。)
>>
>> 　1) 一旦、両系のPacemakerをSlave→Masterの順に片系ずつ停止
>> 　2) 一旦、手動起動した両系のPostgreSQLをSlave→Masterの順に片系ずつ停止
>> 　3) 両系の/var/lib/pgsql/tmp/PGSQL.lock　を削除
>> 　4) さきほどMasterだった方のノードのPacemakerを起動
>> 　　 →crm_mon等でPostgreSQLがMasterになることを確認
>> 　5) pg_basebackupを実行し、現Masterの最新データをSlaveにコピー
>> 　6) SlaveのPacemakerを起動
>>
>>
>> これでも起動しない場合、両系分のPacemakerとPostgreSQLのログを見てみる
>> 必要があります。
>>
>>
>> 以上です。
>> よろしくお願いいたします。
>>
>>
>> ----- 元のメッセージ -----
>> From: "Pacemaker初心者" <m.hiraguchi@freebit.net>
>> 宛先: linux-ha-japan@lists.osdn.me
>> 送信済み: 2016年1月8日, 金曜日 午後 6:38:26
>> 件名: [Linux-ha-jp] クラスタの復旧およびPacemakerの挙動について
>>
>> お世話になります。
>>
>> 先般、PG-REXでのPacemaker構築にて上手くいかなかったので、勉強がてら
>> pcsコマンドにて再構築を行いました。
>>
>> [環境]
>> OS ：CentOS7.1
>> PostgresSQL ：postgresql-server-9.2.13-1
>> Pacemaker ：pacemaker-1.1.12-22
>>
>>
>> 構築後に諸々問題点が発生しており、ご助勢頂けると助かります。
>> 以下、状況を順に記します。
>>
>>
>> (１)構築後の状況
>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>> # crm_mon -Arf -1
>> Last updated: Tue Jan 5 21:39:19 2016
>> Last change: Tue Jan 5 21:38:46 2016 by hacluster via crmd on zabbix01
>> Stack: corosync
>> Current DC: zabbix01(1) - partition with quorum
>> Version: 1.1.12-561c4cf
>> 2 Nodes configured
>> 3 Resources configured
>>
>> Online: [ zabbix01 zabbix02 ]
>>
>> Full list of resources:
>>
>> Master/Slave Set: msPostgresql [pgsql]
>> Masters: [ zabbix01 ]
>> Slaves: [ zabbix02 ]
>> Resource Group: master-group
>> VIP_01 (ocf::heartbeat:IPaddr2): Started zabbix01
>>
>> Node Attributes:
>> * Node zabbix01:
>> + #cluster-name : zabbixcluster
>> + #site-name : zabbixcluster
>> + master-pgsql : 1000
>> + pgsql-data-status : LATEST
>> + pgsql-master-baseline : 0000000016000080
>> + pgsql-status : PRI
>> * Node zabbix02:
>> + #cluster-name : zabbixcluster
>> + #site-name : zabbixcluster
>> + master-pgsql : 100
>> + pgsql-data-status : STREAMING|ASYNC
>> + pgsql-status : HS:async
>>
>> Migration summary:
>> * Node zabbix02:
>> * Node zabbix01:
>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>
>>
>> (２)Slaveへの切替
>> 切替テストとして、Zabbix01のPostgresqlを停止しました。
>> 停止後のクラスタの状態(下記)としては問題ないと思ってます。
>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>> # crm_mon -Arf -1
>> Last updated: Wed Jan 6 00:45:32 2016
>> Last change: Wed Jan 6 00:30:22 2016 by hacluster via crmd on zabbix01
>> Stack: corosync
>> Current DC: zabbix01 (1) - partition with quorum
>> Version: 1.1.12-561c4cf
>> 2 Nodes configured
>> 3 Resources configured
>>
>> Online: [ zabbix01 zabbix02 ]
>>
>> Full list of resources:
>>
>> Master/Slave Set: msPostgresql [pgsql]
>> Masters: [ zabbix02 ]
>> Stopped: [ zabbix01 ]
>> Resource Group: master-group
>> VIP_01 (ocf::heartbeat:IPaddr2): Started zabbix02p
>>
>> Node Attributes:
>> * Node zabbix01:
>> + #cluster-name : zabbixcluster
>> + #site-name : zabbixcluster
>> + master-pgsql : -INFINITY
>> + pgsql-data-status : DISCONNECT
>> + pgsql-status : STOP
>> * Node zabbix02:
>> + #cluster-name : zabbixcluster
>> + #site-name : zabbixcluster
>> + master-pgsql : 1000
>> + pgsql-data-status : LATEST
>> + pgsql-master-baseline : 0000000017000080
>> + pgsql-status : PRI
>>
>> Migration summary:
>> * Node zabbix02:
>> * Node zabbix01:
>> pgsql: migration-threshold=1 fail-count=1 last-failure='Wed Jan 6
>> 00:30:13 2016'
>>
>> Failed actions:
>> pgsql_monitor_3000 on zabbix01 'unknown error' (1): call=126,
>> status=complete, last-rc-change='Wed Jan 6 00:30:13 2016', queued=0ms,
>> exec=0ms
>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>
>>
>> (３)
>> この後、切戻しを行う際に当方の不手際で、Master(Zabbix01)とSlave(Zabbix02)
>> のOS停止をしてしまいました。
>> 停止後、両機を起動しましたが、「pcs status」および「crm_mon -Arf -1」
>> でのmaster-group(VIP_01)、msPostgresql(pgsql)のリソースのステータスが、
>> 〝stopped〟となっていました。
>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>> # pcs status
>> Cluster name: zabbixcluster
>> Last updated: Thr Jan 7 17:11:58 2016
>> Last change: Thr Jan 7 15:57:37 2016 by hacluster via crmd on zabbix01
>> Stack: corosync
>> Current DC: zabbix02 (1) - partition with quorum
>> Version: 1.1.12-561c4cf
>> 2 Nodes configured
>> 3 Resources configured
>>
>>
>> Online: [ zabbix01 zabbix02 ]
>>
>> Full list of resources:
>>
>> Master/Slave Set: msPostgresql [pgsql]
>> Stopped: [ zabbix01 zabbix02 ]
>> Resource Group: master-group
>> VIP_01 (ocf::heartbeat:IPaddr2): Stopped
>>
>> PCSD Status:
>> zabbix01 (192.168.252.182): Online
>> zabbix02 (192.168.252.183): Online
>>
>> Daemon Status:
>> corosync: active/enabled
>> pacemaker: active/enabled
>> pcsd: active/enabled
>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>
>> ＜確認１＞
>> 　Slave(新Master)にてフェイルオーバー後の状態を継続するものと想定して
>> 　いましたが、OS停止をした場合はこの様な挙動になるのは正しいのでしょうか？
>>
>>
>> (４)復旧
>> pg_basebackup、pg_ctl promote等を行い、PostgreSQLの戻しを行いました。
>> (※「psql -h localhost -c "SELECT pg_is_in_recovery();"」にて
>> 両PostgresSQLの起動状態(Zabbix01：f、Zabbix02：t)と、ストリーミング
>> レプリケーションの動作を確認済)
>>
>> PostgreSQLの状態復旧を行った後に、
>> 　①pcs resource cleanup msPostgresqlとpcs resource cleanup master-group
>> 　②pcs cluster stop --allとpcs cluster start --all
>> にて復旧を試みましたが、両リソースの状態は〝stopped〟のままです。
>>
>> ＜確認２＞
>> 　クラスタの復旧作業として①と②以外に行うことはありますか？
>> 　(※VIP_01はdebug-atartにて強制起動し、PostgreSQLは手動起動しましたが、
>> 　未だ〝stopped〟のままです。)
>>
>>
>> ＜確認３＞
>> 　そもそもの話なのですが、クラスタ起動時にVIP付与とPostgreSQL起動が
>> 　されない状態です。(PostgreSQLは手動起動してます)
>> 　設定内容を以下に示すので、不足している設定をご教示願います。
>>
>> ■設定内容
>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>> pcs -f cluster_cfg property set no-quorum-policy="ignore"
>> pcs -f cluster_cfg property set stonith-enabled="false"
>> pcs -f cluster_cfg resource defaults resource-stickiness="INFINITY"
>> pcs -f cluster_cfg resource defaults migration-threshold="1"
>>
>> pcs -f cluster_cfg resource create VIP_01 IPaddr2 \
>> ip="192.168.252.184" \
>> nic="enp0s3" \
>> cidr_netmask="24" \
>> op start timeout="60s" interval="0s" on-fail="restart" \
>> op monitor timeout="60s" interval="10s" on-fail="restart" \
>> op stop timeout="60s" interval="0s" on-fail="block"
>>
>> pcs -f cluster_cfg resource create pgsql pgsql \
>> pgctl="/usr/bin/pg_ctl" \
>> psql="/usr/bin/psql" \
>> pgdata="/var/lib/pgsql/data/" \
>> rep_mode="async" \
>> node_list="zabbix01 zabbix02" \
>> restore_command="cp /var/lib/pgsql/pg_archive/%f %p" \
>> primary_conninfo_opt="keepalives_idle=60 keepalives_interval=5
>> keepalives_count=5" \
>> master_ip="192.168.252.184" \
>> restart_on_promote='true' \
>> op start timeout="60s" interval="0s" on-fail="restart" \
>> op monitor timeout="60s" interval="4s" on-fail="restart" \
>> op monitor timeout="60s" interval="3s" on-fail="restart"
>> role="Master" \
>> op promote timeout="60s" interval="0s" on-fail="restart" \
>> op demote timeout="60s" interval="0s" on-fail="stop" \
>> op stop timeout="60s" interval="0s" on-fail="block" \
>> op notify timeout="60s" interval="0s"
>>
>> pcs -f cluster_cfg resource master msPostgresql pgsql \
>> master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true
>>
>> pcs -f cluster_cfg resource group add master-group VIP_01
>>
>> pcs -f pgsql_cfg constraint colocation add master-group with Master
>> msPostgresql INFINITY
>> pcs -f pgsql_cfg constraint order promote msPostgresql then start
>> master-group symmetrical=false score=INFINITY
>> pcs -f pgsql_cfg constraint order demote msPostgresql then stop
>> master-group symmetrical=false score=0
>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>
>> (上記を「pcs cluster cib-push cluster_cfg」にて反映しています)
>>
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan
_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan

ひがし様

いつもお世話をお掛けします。


>それでは、故障時に何が起きていたのかを見たいので、以下情報を
>いただけますか？

>・Zabbixプロセス停止実施"後"のcrm_mon -Arf -1の表示内容 　(両系分)

⇒Zabbixプロセス停止実施後(直後)の出力が残っておりません。
　申し訳ありません。
　目視の結果をお伝えするしかないのですが、これまでの内容通り、
　　・クラスタ(pacemaker、corosyncは、Zabbix01(Master)/Zabbix02(Slave)共
に Running
　　・PostgreSQLリソースは、Zabbix01/Zabbix02共にStopped
　　・VIPリソースは、Zabbix01/Zabbix02共にStopped
　　・Zabbixserverリソースは、Zabbix01/Zabbix02共にStopped
　となります。

>・Zabbixプロセス停止前後の時間帯を含んだPacemakerのログ
　(両系分)

⇒Zabbix01、Zabbix02両機の/var/log/messages(該当時間帯を抽出したもの)を
　貼付します。


>・Zabbix故障後、Pacemakerが稼働しているノードで以下コマンドを実行し、
生成された/tmp/cib.xml。 　
>(Pacemakerに設定のリソース設定や属性値の内容等が含まれます。) 　
># cibadmin -Q > /tmp/cib.xml

⇒本日AMに出力した内容を貼付します。



お忙しい中、大変申し訳ありません。


On 2016/01/16 20:43, kazuh@goo.jp wrote:
> ひがしです。お世話になります。
>
> それでは、故障時に何が起きていたのかを見たいので、以下情報を
> いただけますか？
>
> ・Zabbixプロセス停止実施"後"のcrm_mon -Arf -1の表示内容
> 　(両系分)
>
> ・Zabbixプロセス停止前後の時間帯を含んだPacemakerのログ
> 　(両系分)
> 　・・・設定次第でファイル名は異なりますが通常、
> 　　　　/var/log/messagesや/var/log/ha-log。
>
> ・Zabbix故障後、Pacemakerが稼働しているノードで以下コマンドを実行し、
> 　生成された/tmp/cib.xml。
> 　(Pacemakerに設定のリソース設定や属性値の内容等が含まれます。)
> 　# cibadmin -Q > /tmp/cib.xml
>
>
> 以上です。
> よろしくお願い致します。
>
> ----- 元のメッセージ -----
> From: "Pacemaker初心者" <m.hiraguchi@freebit.net>
> 宛先: linux-ha-japan@lists.osdn.me
> 送信済み: 2016年1月15日, 金曜日 午後 6:16:58
> 件名: Re: [Linux-ha-jp] クラスタの復旧およびPacemakerの挙動について
>
> ひがし様
>
> 毎回ご回答頂きありがとうございます。
>
> ■クラスタ切戻し時のPostgresqlの復旧作業
>> 参考まで、recovery.confはPacemaker(pgsql RA)が自動的に作成するので、
>> 手動で作成(リネーム)する必要は無いですよ。
> ⇒そうなんですね。。。了解しました。
>
> ■ZabbixServerリソース障害時のクラスタ移動失敗
>
>> 思いつく（よくあるケース）で以下２つが考えられます。
>> (1)リソース停止失敗していないか？
>> ZabbixServer障害は、具体的にはどんな障害でしょうか？
> ⇒プロセス停止を想定し、「killall |grep zabbix_server」を実施しました。
> 　※クラスタリソース作成後は、〝systemctl stop zabbix-server〟が
> 　　効かないので、上記killallにて停止しました。
>
>
>> 今回の設定では、前回回答でも少し触れましたが、STONITH(排他制御)が設定
>> されていないようなので、リソースの停止が失敗するケースの故障時は、
>> フェイルオーバはできません。
>> 具体的には、各リソース設定の以下op stop～～行の「on-fail="block"」
>> というのが、「リソースの停止に失敗したら、フェイルオーバを中止(block)する」
>> ということを示しています。
>> 　op stop timeout="60s" interval="0s" on-fail="block"
>> STONITHを導入し、かつon-fail="fence"と設定すると、リソースの停止失敗時は
>> STONITHが発動し、相手ノードの電源を強制的に断した後、フェイルオーバが
>> 継続します。
> ⇒上記プロセス停止のケースであれば、zabbixserverリソースのmonitorの内容に
> 　従うという想定をしております。
> 　(op monitor timeout="60s" interval="0s" on-fail="restart" \)
>
> 　ちなみに、停止時のエラー発生した場合の挙動はSTONITHを使用しないため、、
> 　op stop timeout="60s" interval="0s" on-fail="block"
> 　としております。
> 　※本初期構築時点ではSTONITHは考えておらず、将来的にIPMI関連の整備が完了した
> 　　時点でSTONITHの導入を考えております。
>
>
>> (2)フェイルカウントや制約等が残っていないか？
>> フェイルオーバ先に、過去、故障や、手動リソース移動でついた制約が
>> 残ってしまってないでしょうか？
>> フェイルカウントは、「crm_mon -rfA」の表示の"Failed actions:"という
>> 最下部の欄に何か表示があれば、残った状態です。
>> 残っていると、Pacemakerはこのノードは故障していると判断し、
>> リソースは起動しません。
> ⇒Zabbixプロセス停止実施前のcrm_mon -Arf -1の表示内容からは、
> 　「Failed actions:」および異常を示す表示はされていません。
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
> # crm_mon -Arf -1
> Last updated: Thu Jan 14 16:47:49 2016 Last change: Thu Jan 14 16:45:38 2016 by root via crm_attribute on com-zabbix01p-pnd-ppp
> Stack: corosync
> Current DC: com-zabbix01p-pnd-ppp (version 1.1.13-10.el7-44eb2dd) - partition with quorum
> 2 nodes and 4 resources configured
>
> Online: [ com-zabbix01p-pnd-ppp com-zabbix02p-pnd-ppp ]
>
> Full list of resources:
>
> Master/Slave Set: msGrpPostgresql [PGSQL_01]
> Masters: [ com-zabbix01p-pnd-ppp ]
> Slaves: [ com-zabbix02p-pnd-ppp ]
> Resource Group: GrpVIP
> VIP_01 (ocf::heartbeat:IPaddr2): Started com-zabbix01p-pnd-ppp
> ZabbixSV (ocf::heartbeat:zabbixserver): Started com-zabbix01p-pnd-ppp
>
> Node Attributes:
> * Node com-zabbix01p-pnd-ppp:
> + PGSQL_01-data-status : LATEST
> + PGSQL_01-master-baseline : 00000000140000B8
> + PGSQL_01-status : PRI
> + master-PGSQL_01 : 1000
> * Node com-zabbix02p-pnd-ppp:
> + PGSQL_01-data-status : STREAMING|ASYNC
> + PGSQL_01-status : HS:async
> + master-PGSQL_01 : 100
>
> Migration Summary:
> * Node com-zabbix02p-pnd-ppp:
> * Node com-zabbix01p-pnd-ppp:
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>
> 現クラスタ定義を整理すると、
>
> 　①Zabbixserverリソースのオペレーション定義では、
> 　　moniter　interval=0s　timeout=60s　on-fail=restart
> 　　(startでもon-fail=restartであり、stopはon-fail=blockである)
>
> 　②リソースグループ定義では、
> 　　・Postgresqlグループでは、Postgresqlリソースのみ含む
> 　　　(Master/Slaveグループとして作成し、master-max=1、master-node-max=1
> 　　　、clone-max=2、clone-node-max=1、notify=trueとしている)
> 　　・VIPグループでは、VIPリソースとZabbixServerリソースの２つのリソースを含む
> 　　　(priority設定をしていないため、VIPグループ内の起動順序は、
> 　　　 VIPリソース⇒ZabbixServerリソースという起動になることを想定)
>
> 　③同居定義では、
> 　　Master状態のPostgresqlグループとVIPグループが、INFINITY。
>
> 　④起動順序定義では、
> 　　・Postgresqlグループをpromote⇒VIPグループをstartする。(INFINITY)
> 　　・Postgresqlグループをdemote⇒VIPグループをstopする。(0(強制せず))
>
> となっています。
> Postgresql障害(プロセスダウン)では、Postgresqlリソースが他のリソース起動前提
> となっているため、Postgresqlリソースがクラスタ移動すると他のリソースが連動する
> こととなり、正常に切り替わると考えてます。
>
> 今回のZabbixserver障害(プロセスダウン)を検知し、全リソースを移動(Postgresqlの
> 切替(移動＆promote)⇒VIPリソース移動⇒Zabbix起動)させる必要があるのですが、
> 下記定義内容にて不足している定義はありますか？
>
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
> ■クラスタ定義
> pcs property set no-quorum-policy="ignore"
> pcs property set stonith-enabled="false"
> pcs resource defaults resource-stickness="INFINITY"
> pcs resource defaults migration-threshold="1"
>
> ■VIPリソース定義
> pcs resource create VIP_01 IPaddr2 \
>> ip="192.168.13.125" \
>> nic="enp0s3" \
>> cidr_netmask="24" \
>> op start timeout="60s" interval="0s" on-fail="resstart" \
>> op monitor timeout="60s" interval="10s" on-fail="restart" \
>> op stop timeout="60s" interval="0s" on-fail="block" \
> ■PostgreSQLリソース定義
> pcs -f /tmp/cluster_cfg resource create PGSQL_01 pgsql \
>> pgctl="/usr/bin/pg_ctl" \
>> psql="/usr/bin/psql" \
>> pgdata="/var/lib/pgsql/data/" \
>> rep_mode="async" \
>> node_list="zabbix01 zabbix02" \
>> restore_command="cp /var/lib/pgsql/pg_arch/arc1/%f %p" \
>> primary_conninfo_opt="keepalives_idle=60 keepalives_interval=5 keepalives_count=5" \
>> master_ip="192.168.13.125" \
>> restart_on_promote='true' \
>> repuser="rep_user" \
>> start_opt="-i -p 5432" \
>> op start timeout="60s" interval="0s" on-fail="restart" \
>> op monitor timeout="60s" interval="4s" on-fail="restart" \
>> op monitor timeout="60s" interval="3s" on-fail="restart" role="Master" \
>> op promote timeout="60s" interval="0s" on-fail="restart" \
>> op demote timeout="60s" interval="0s" on-fail="stop" \
>> op stop timeout="60s" interval="0s" on-fail="block" \
>> op notify timeout="60s" interval="0s"
> ■同居・起動順序定義
> pcs resource master msGrpPostgresql PGSQL_01 \
>> master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true
> pcs resource group add GrpVIP VIP_01
> pcs constraint colocation add GrpVIP with Master msGrpPostgresql
> pcs constraint order promote msGrpPostgresql then start GrpVIP symmetrical=false score=INFINITY
> pcs constraint order demote msGrpPostgresql then stop GrpVIP symmetrical=false score=0
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>
> 何卒、ご助勢願います。
>
>
> On 2016/01/15 13:45, kazuh@goo.jp wrote:
>> ひがしです。お世話になります。
>>
>>> ⇒ご指摘の事項およびpg_basebackup、promote、recovery.done⇒recovery.confの
>>> リネーム等
>>> 　PostgreSQLの(Masterでの)起動条件を整理し復旧しました。
>> うまくいったのなら良かったです。
>> 参考まで、recovery.confはPacemaker(pgsql RA)が自動的に作成するので、
>> 手動で作成(リネーム)する必要は無いですよ。
>>
>>
>>> この内容で、PostgreSQL障害時はSlave(新マスタ)機へ問題なく切り替わりまし
>>> たが、
>>> ZabbixServer障害時はクラスタリソース全てがMaster、Slave共に停止してしま
>>> いました。
>> 思いつく（よくあるケース）で以下２つが考えられます。
>>
>> (1)リソース停止失敗していないか？
>> ZabbixServer障害は、具体的にはどんな障害でしょうか？
>> 今回の設定では、前回回答でも少し触れましたが、STONITH(排他制御)が設定
>> されていないようなので、リソースの停止が失敗するケースの故障時は、
>> フェイルオーバはできません。
>>
>> 具体的には、各リソース設定の以下op stop～～行の「on-fail="block"」
>> というのが、「リソースの停止に失敗したら、フェイルオーバを中止(block)する」
>> ということを示しています。
>> 　op stop timeout="60s" interval="0s" on-fail="block"
>>
>> STONITHを導入し、かつon-fail="fence"と設定すると、リソースの停止失敗時は
>> STONITHが発動し、相手ノードの電源を強制的に断した後、フェイルオーバが
>> 継続します。
>>
>> このあたり、詳細は、前回も紹介の以下資料をご覧ください。
>> 　　http://linux-ha.osdn.jp/wp/archives/4338
>> 　　　→試して覚えるPacemaker入門 排他制御機能編
>>
>>
>> (2)フェイルカウントや制約等が残っていないか？
>> フェイルオーバ先に、過去、故障や、手動リソース移動でついた制約が
>> 残ってしまってないでしょうか？
>>
>> フェイルカウントは、「crm_mon -rfA」の表示の"Failed actions:"という
>> 最下部の欄に何か表示があれば、残った状態です。
>> 残っていると、Pacemakerはこのノードは故障していると判断し、
>> リソースは起動しません。
>>
>> 前回紹介の以下資料P34の表示例を参考に、残っていればP36のコマンドで
>> フェイルカウントを削除してください。
>>> http://linux-ha.osdn.jp/wp/archives/4137
>>> 　→PG-REXで学ぶPacemaker運用の実例
>> また、crm_resource -M -r コマンドでリソースを手動で移動した後、
>> 「crm_resource -U -r ＜リソース名＞」を実行していない場合、
>> 移動元のノードにはリソースが起動できない制約が残ります。
>> (crm_mon -rfAL で確認できます。)
>> その場合、「crm_resource -U -r ＜リソース名＞」で制約を消してください。
>>
>>
>>
>> さて、上記はあくまでも推測で、今回の事象がそれに該当するかどうかは、
>> ログ等を確認しないとわかりません。
>> ZabbixServer障害発生時の、「crm_mon -Arf -1」やPacemakerのログ(両系分)が
>> あれば、もう少し今回の事象の原因を解析できると思います。
>>
>>
>> 以上です。よろしくお願いいたします。
>>
>> ----- 元のメッセージ -----
>> From: "Pacemaker初心者" <m.hiraguchi@freebit.net>
>> 宛先: linux-ha-japan@lists.osdn.me
>> 送信済み: 2016年1月14日, 木曜日 午後 8:53:15
>> 件名: Re: [Linux-ha-jp] クラスタの復旧およびPacemakerの挙動について
>>
>> ひがし様
>>
>> ご回答ありがとうございます。
>>
>> ＜確認１のご回答＞
>>> PG-REXでは、Pacemaker起動をMasterになってほしいノードから片方ずつ行い、
>>> そのPacemakerが完全に起動し、PostgreSQLがMasterになったことを確認してから、
>>> もう片方を起動する、というように起動する必要があります。
>>> Pacemakerからすると、2ノード同時に起動された場合、どちらのノードを優先して
>>> Masterにすべきか判断できないためです。
>>> 今回の場合、Slave(新Master)のみを先に起動すれば、きちんとMasterになったかと
>>> 思います。
>> ⇒本ケースの再現がありましたので、Slave(新Master)機⇒Master(新Slave)機の順で、
>> 　クラスタ起動を行いました。
>>
>> ＜確認２のご回答＞
>>> ログを確認しないと断定はできませんが、両系でPGSQL.lockファイルが残存している
>>> 可能性があります。
>>> これは、データが古い可能性があることをユーザに気づかせるための印で、
>>> Pacemaker(pgsql RA)が正常停止するときのみ削除されます。つまり、異常停止時
>>> には残存し、異常停止した旨をユーザに気づかせるものです。
>>> 通常、postgreユーザのホーム配下のtmp/(/var/lib/pgsql/tmp/)にあります。
>>> データ復旧後、またはデータが古い可能性があること承知の上で、当該ノードの
>>> PostgreSQLを起動する際は、このファイルを手動で削除する必要があります
>> ⇒ご指摘の事項およびpg_basebackup、promote、recovery.done⇒recovery.confの
>> リネーム等
>> 　PostgreSQLの(Masterでの)起動条件を整理し復旧しました。
>>
>> ＜確認３のご回答＞
>>> 構築後、一度きちんと起動しているようなので、設定に問題は無いかと
>>> 思います。
>>> ＃STONITH, SFEX, VIPcheck等の排他制御は設定されていないようなので、
>>> 　スプリットブレイン発生時は両系ノードがMasterになってしまうのが
>>> 　問題と言えば問題ですが、今回の事象とは関係ないと思います。
>> ⇒クラスタ起動に連動し、PostgreSQLが起動するようになりました。
>> 　※関係ないかもしれませんが、前回との変更点は、PostgreSQLリソースに
>> 　「start_option="-i -p 5432"」の追加です。
>>
>>
>> ■新たな確認事項
>> 　VIP、PostgreSQLのクラスタリソースおよびグループ以外のリソース(Zabbix)
>> を追加しました。
>>
>> 　■zabbixリソースの作成内容
>> # pcs resource create ZabbixSV zabbixserver \
>> > binary="/usr/sbin/zabbix_server" \
>> > pid="/var/run/zabbix/zabbix_server.pid" \
>> > config="/etc/zabbix/zabbix_server.conf" \
>> > op start timeout="60s" interval="0s" on-fail="restart" \
>> > op monitor timeout="60s" interval="0s" on-fail="restart" \
>> > op stop timeout="60s" interval="0s" on-fail="block"
>>
>> 　■zabbixリソースのグループ登録(VIPリソースグループへの追加)
>> # pcs resource group add GrpVIP ZabbixSV
>> # pcs resource group list
>> GrpVIP: VIP_01 ZabbixSV
>>
>>
>> ※フェイルオーバー時の起動順序は、
>> 　　①PostgreSQLのPromote
>> 　　②VIP付与
>> 　　③ZabbixServer起動
>> 　を想定しています。
>>
>> この内容で、PostgreSQL障害時はSlave(新マスタ)機へ問題なく切り替わりまし
>> たが、
>> ZabbixServer障害時はクラスタリソース全てがMaster、Slave共に停止してしま
>> いました。
>>
>> PostgreSQLに依存するクラスタリソースの登録について
>> ご教示願います。
>>
>> ご助勢の程、宜しくお願い致します。
>>
>>
>>
>> On 2016/01/14 13:48, kazuh@goo.jp wrote:
>>> ひがしと申します。
>>> お世話になります。
>>>
>>>
>>>> ＜確認１＞
>>>> 　Slave(新Master)にてフェイルオーバー後の状態を継続するものと想定して
>>>> 　いましたが、OS停止をした場合はこの様な挙動になるのは正しいのでしょうか？
>>> PG-REXでは、Pacemaker起動をMasterになってほしいノードから片方ずつ行い、
>>> そのPacemakerが完全に起動し、PostgreSQLがMasterになったことを確認してから、
>>> もう片方を起動する、というように起動する必要があります。
>>> Pacemakerからすると、2ノード同時に起動された場合、どちらのノードを優先して
>>> Masterにすべきか判断できないためです。
>>>
>>> 今回の場合、Slave(新Master)のみを先に起動すれば、きちんとMasterになったかと
>>> 思います。
>>>
>>>
>>>> ＜確認２＞
>>>> 　クラスタの復旧作業として①と②以外に行うことはありますか？
>>>> 　(※VIP_01はdebug-atartにて強制起動し、PostgreSQLは手動起動しましたが、
>>>> 　未だ〝stopped〟のままです。)
>>> ログを確認しないと断定はできませんが、両系でPGSQL.lockファイルが残存している
>>> 可能性があります。
>>>
>>> これは、データが古い可能性があることをユーザに気づかせるための印で、
>>> Pacemaker(pgsql RA)が正常停止するときのみ削除されます。つまり、異常停止時
>>> には残存し、異常停止した旨をユーザに気づかせるものです。
>>> 通常、postgreユーザのホーム配下のtmp/(/var/lib/pgsql/tmp/)にあります。
>>>
>>> データ復旧後、またはデータが古い可能性があること承知の上で、当該ノードの
>>> PostgreSQLを起動する際は、このファイルを手動で削除する必要があります。
>>>
>>>
>>>
>>> なお、手前味噌になりますが、昨年福岡で開催のオープンソースカンファレンスにて
>>> PG-REXの故障時の挙動や運用方法をまとめた講演を行いました。
>>> PostgreSQLプロセス停止後の復旧は、以下P42に掲載しています。
>>>
>>> http://linux-ha.osdn.jp/wp/archives/4137
>>> 　→PG-REXで学ぶPacemaker運用の実例
>>> 　　　P42 vip-master故障時の復旧方法
>>>
>>>
>>>> ＜確認３＞
>>>> 　そもそもの話なのですが、クラスタ起動時にVIP付与とPostgreSQL起動が
>>>> 　されない状態です。(PostgreSQLは手動起動してます)
>>>> 　設定内容を以下に示すので、不足している設定をご教示願います。
>>> 構築後、一度きちんと起動しているようなので、設定に問題は無いかと
>>> 思います。
>>> ＃STONITH, SFEX, VIPcheck等の排他制御は設定されていないようなので、
>>> 　スプリットブレイン発生時は両系ノードがMasterになってしまうのが
>>> 　問題と言えば問題ですが、今回の事象とは関係ないと思います。
>>> 　排他制御については、以下講演が詳しいです。
>>> 　　http://linux-ha.osdn.jp/wp/archives/4338
>>> 　　　→試して覚えるPacemaker入門 排他制御機能編
>>>
>>>
>>> 一度、以下の順に、起動・停止をやりなおしてみてはいかがでしょうか？
>>> (上記PGSQL.lockや片系ずつ起動、を踏まえた手順案です。)
>>>
>>> 　1) 一旦、両系のPacemakerをSlave→Masterの順に片系ずつ停止
>>> 　2) 一旦、手動起動した両系のPostgreSQLをSlave→Masterの順に片系ずつ停止
>>> 　3) 両系の/var/lib/pgsql/tmp/PGSQL.lock　を削除
>>> 　4) さきほどMasterだった方のノードのPacemakerを起動
>>> 　　 →crm_mon等でPostgreSQLがMasterになることを確認
>>> 　5) pg_basebackupを実行し、現Masterの最新データをSlaveにコピー
>>> 　6) SlaveのPacemakerを起動
>>>
>>>
>>> これでも起動しない場合、両系分のPacemakerとPostgreSQLのログを見てみる
>>> 必要があります。
>>>
>>>
>>> 以上です。
>>> よろしくお願いいたします。
>>>
>>>
>>> ----- 元のメッセージ -----
>>> From: "Pacemaker初心者" <m.hiraguchi@freebit.net>
>>> 宛先: linux-ha-japan@lists.osdn.me
>>> 送信済み: 2016年1月8日, 金曜日 午後 6:38:26
>>> 件名: [Linux-ha-jp] クラスタの復旧およびPacemakerの挙動について
>>>
>>> お世話になります。
>>>
>>> 先般、PG-REXでのPacemaker構築にて上手くいかなかったので、勉強がてら
>>> pcsコマンドにて再構築を行いました。
>>>
>>> [環境]
>>> OS ：CentOS7.1
>>> PostgresSQL ：postgresql-server-9.2.13-1
>>> Pacemaker ：pacemaker-1.1.12-22
>>>
>>>
>>> 構築後に諸々問題点が発生しており、ご助勢頂けると助かります。
>>> 以下、状況を順に記します。
>>>
>>>
>>> (１)構築後の状況
>>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>> # crm_mon -Arf -1
>>> Last updated: Tue Jan 5 21:39:19 2016
>>> Last change: Tue Jan 5 21:38:46 2016 by hacluster via crmd on zabbix01
>>> Stack: corosync
>>> Current DC: zabbix01(1) - partition with quorum
>>> Version: 1.1.12-561c4cf
>>> 2 Nodes configured
>>> 3 Resources configured
>>>
>>> Online: [ zabbix01 zabbix02 ]
>>>
>>> Full list of resources:
>>>
>>> Master/Slave Set: msPostgresql [pgsql]
>>> Masters: [ zabbix01 ]
>>> Slaves: [ zabbix02 ]
>>> Resource Group: master-group
>>> VIP_01 (ocf::heartbeat:IPaddr2): Started zabbix01
>>>
>>> Node Attributes:
>>> * Node zabbix01:
>>> + #cluster-name : zabbixcluster
>>> + #site-name : zabbixcluster
>>> + master-pgsql : 1000
>>> + pgsql-data-status : LATEST
>>> + pgsql-master-baseline : 0000000016000080
>>> + pgsql-status : PRI
>>> * Node zabbix02:
>>> + #cluster-name : zabbixcluster
>>> + #site-name : zabbixcluster
>>> + master-pgsql : 100
>>> + pgsql-data-status : STREAMING|ASYNC
>>> + pgsql-status : HS:async
>>>
>>> Migration summary:
>>> * Node zabbix02:
>>> * Node zabbix01:
>>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>>
>>>
>>> (２)Slaveへの切替
>>> 切替テストとして、Zabbix01のPostgresqlを停止しました。
>>> 停止後のクラスタの状態(下記)としては問題ないと思ってます。
>>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>> # crm_mon -Arf -1
>>> Last updated: Wed Jan 6 00:45:32 2016
>>> Last change: Wed Jan 6 00:30:22 2016 by hacluster via crmd on zabbix01
>>> Stack: corosync
>>> Current DC: zabbix01 (1) - partition with quorum
>>> Version: 1.1.12-561c4cf
>>> 2 Nodes configured
>>> 3 Resources configured
>>>
>>> Online: [ zabbix01 zabbix02 ]
>>>
>>> Full list of resources:
>>>
>>> Master/Slave Set: msPostgresql [pgsql]
>>> Masters: [ zabbix02 ]
>>> Stopped: [ zabbix01 ]
>>> Resource Group: master-group
>>> VIP_01 (ocf::heartbeat:IPaddr2): Started zabbix02p
>>>
>>> Node Attributes:
>>> * Node zabbix01:
>>> + #cluster-name : zabbixcluster
>>> + #site-name : zabbixcluster
>>> + master-pgsql : -INFINITY
>>> + pgsql-data-status : DISCONNECT
>>> + pgsql-status : STOP
>>> * Node zabbix02:
>>> + #cluster-name : zabbixcluster
>>> + #site-name : zabbixcluster
>>> + master-pgsql : 1000
>>> + pgsql-data-status : LATEST
>>> + pgsql-master-baseline : 0000000017000080
>>> + pgsql-status : PRI
>>>
>>> Migration summary:
>>> * Node zabbix02:
>>> * Node zabbix01:
>>> pgsql: migration-threshold=1 fail-count=1 last-failure='Wed Jan 6
>>> 00:30:13 2016'
>>>
>>> Failed actions:
>>> pgsql_monitor_3000 on zabbix01 'unknown error' (1): call=126,
>>> status=complete, last-rc-change='Wed Jan 6 00:30:13 2016', queued=0ms,
>>> exec=0ms
>>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>>
>>>
>>> (３)
>>> この後、切戻しを行う際に当方の不手際で、Master(Zabbix01)とSlave(Zabbix02)
>>> のOS停止をしてしまいました。
>>> 停止後、両機を起動しましたが、「pcs status」および「crm_mon -Arf -1」
>>> でのmaster-group(VIP_01)、msPostgresql(pgsql)のリソースのステータスが、
>>> 〝stopped〟となっていました。
>>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>> # pcs status
>>> Cluster name: zabbixcluster
>>> Last updated: Thr Jan 7 17:11:58 2016
>>> Last change: Thr Jan 7 15:57:37 2016 by hacluster via crmd on zabbix01
>>> Stack: corosync
>>> Current DC: zabbix02 (1) - partition with quorum
>>> Version: 1.1.12-561c4cf
>>> 2 Nodes configured
>>> 3 Resources configured
>>>
>>>
>>> Online: [ zabbix01 zabbix02 ]
>>>
>>> Full list of resources:
>>>
>>> Master/Slave Set: msPostgresql [pgsql]
>>> Stopped: [ zabbix01 zabbix02 ]
>>> Resource Group: master-group
>>> VIP_01 (ocf::heartbeat:IPaddr2): Stopped
>>>
>>> PCSD Status:
>>> zabbix01 (192.168.252.182): Online
>>> zabbix02 (192.168.252.183): Online
>>>
>>> Daemon Status:
>>> corosync: active/enabled
>>> pacemaker: active/enabled
>>> pcsd: active/enabled
>>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>>
>>> ＜確認１＞
>>> 　Slave(新Master)にてフェイルオーバー後の状態を継続するものと想定して
>>> 　いましたが、OS停止をした場合はこの様な挙動になるのは正しいのでしょうか？
>>>
>>>
>>> (４)復旧
>>> pg_basebackup、pg_ctl promote等を行い、PostgreSQLの戻しを行いました。
>>> (※「psql -h localhost -c "SELECT pg_is_in_recovery();"」にて
>>> 両PostgresSQLの起動状態(Zabbix01：f、Zabbix02：t)と、ストリーミング
>>> レプリケーションの動作を確認済)
>>>
>>> PostgreSQLの状態復旧を行った後に、
>>> 　①pcs resource cleanup msPostgresqlとpcs resource cleanup master-group
>>> 　②pcs cluster stop --allとpcs cluster start --all
>>> にて復旧を試みましたが、両リソースの状態は〝stopped〟のままです。
>>>
>>> ＜確認２＞
>>> 　クラスタの復旧作業として①と②以外に行うことはありますか？
>>> 　(※VIP_01はdebug-atartにて強制起動し、PostgreSQLは手動起動しましたが、
>>> 　未だ〝stopped〟のままです。)
>>>
>>>
>>> ＜確認３＞
>>> 　そもそもの話なのですが、クラスタ起動時にVIP付与とPostgreSQL起動が
>>> 　されない状態です。(PostgreSQLは手動起動してます)
>>> 　設定内容を以下に示すので、不足している設定をご教示願います。
>>>
>>> ■設定内容
>>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>> pcs -f cluster_cfg property set no-quorum-policy="ignore"
>>> pcs -f cluster_cfg property set stonith-enabled="false"
>>> pcs -f cluster_cfg resource defaults resource-stickiness="INFINITY"
>>> pcs -f cluster_cfg resource defaults migration-threshold="1"
>>>
>>> pcs -f cluster_cfg resource create VIP_01 IPaddr2 \
>>> ip="192.168.252.184" \
>>> nic="enp0s3" \
>>> cidr_netmask="24" \
>>> op start timeout="60s" interval="0s" on-fail="restart" \
>>> op monitor timeout="60s" interval="10s" on-fail="restart" \
>>> op stop timeout="60s" interval="0s" on-fail="block"
>>>
>>> pcs -f cluster_cfg resource create pgsql pgsql \
>>> pgctl="/usr/bin/pg_ctl" \
>>> psql="/usr/bin/psql" \
>>> pgdata="/var/lib/pgsql/data/" \
>>> rep_mode="async" \
>>> node_list="zabbix01 zabbix02" \
>>> restore_command="cp /var/lib/pgsql/pg_archive/%f %p" \
>>> primary_conninfo_opt="keepalives_idle=60 keepalives_interval=5
>>> keepalives_count=5" \
>>> master_ip="192.168.252.184" \
>>> restart_on_promote='true' \
>>> op start timeout="60s" interval="0s" on-fail="restart" \
>>> op monitor timeout="60s" interval="4s" on-fail="restart" \
>>> op monitor timeout="60s" interval="3s" on-fail="restart"
>>> role="Master" \
>>> op promote timeout="60s" interval="0s" on-fail="restart" \
>>> op demote timeout="60s" interval="0s" on-fail="stop" \
>>> op stop timeout="60s" interval="0s" on-fail="block" \
>>> op notify timeout="60s" interval="0s"
>>>
>>> pcs -f cluster_cfg resource master msPostgresql pgsql \
>>> master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true
>>>
>>> pcs -f cluster_cfg resource group add master-group VIP_01
>>>
>>> pcs -f pgsql_cfg constraint colocation add master-group with Master
>>> msPostgresql INFINITY
>>> pcs -f pgsql_cfg constraint order promote msPostgresql then start
>>> master-group symmetrical=false score=INFINITY
>>> pcs -f pgsql_cfg constraint order demote msPostgresql then stop
>>> master-group symmetrical=false score=0
>>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>>
>>> (上記を「pcs cluster cib-push cluster_cfg」にて反映しています)
>>>
>>> _______________________________________________
>>> Linux-ha-japan mailing list
>>> Linux-ha-japan@lists.osdn.me
>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>> _______________________________________________
>>> Linux-ha-japan mailing list
>>> Linux-ha-japan@lists.osdn.me
>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan

ひがしです。お世話になります。

> ⇒Zabbix01、Zabbix02両機の/var/log/messages(該当時間帯を抽出したもの)を
> 　貼付します。

17:52:58に、両系のHeartbeat通信が一瞬途切れ、その後17:53:02ごろにまたつながる、
という事象があったように読み取れます。
これにより、いわゆるスプリットブレイン状態になり、一時、両系がMasterになってい
ます。(17:53:06に2系のPostgreSQLがpromote(Masterに昇格)している。)

その後、Pacemakerは両系がMasterになったことを検知し、安全のため、両系のPostgreSQL
をSlave状態にすべく、demote(降格処理)を実行したようです。そのため、両系でリソース
が停止しました。

今回の構成は、STONITHやVIPcheck等の排他制御が導入されていないため、上記のような
スプリットブレインを防ぐことができません。

17:52:58ごろ、両系のネットワーク通信路が切れる、または、ノードが高負荷で一時的に
通信ができなかった、等、両系のHeartbeat通信が一瞬途切れた原因に心当たりはないで
しょうか？
(高負荷の原因でよくあるのは、ノードのメモリ不足でスワップが発生した、や、ウィルス
ソフト等によるスキャンが始まった等があります。ノードが仮想マシンの場合、ホスト側
の高負荷や、仮想マシンに割り当てるメモリ量の不足(=スワップ発生)も疑う必要があり
ます。)


いずれにせよ、今回の事象は単なるZabbix故障とは違って、Heartbeat通信が途切れる
という事象が重なったものと思われます。


以下、Pacemakerのログ抜粋です。

　【1系ログ】
　　Jan 14 17:52:58 com-zabbix01p-pnd-ppp pacemakerd[30726]: notice: crm_reap_unseen_nodes: Node com-zabbix02p-pnd-ppp[2] - state is now lost (was member)
　　Jan 14 17:52:58 com-zabbix01p-pnd-ppp crmd[30732]: notice: crm_reap_unseen_nodes: Node com-zabbix02p-pnd-ppp[2] - state is now lost (was member)
　　→2系を見失う

　　Jan 14 17:53:02 com-zabbix01p-pnd-ppp corosync[30711]: [TOTEM ] A new membership (192.168.13.52:1652) was formed. Members joined: 2
　　Jan 14 17:53:02 com-zabbix01p-pnd-ppp crmd[30732]: warning: Another DC detected: com-zabbix02p-pnd-ppp (op=noop)
　　→再び2系が接続。DCノードがバッティングしている旨Warning出力。

　　Jan 14 17:53:08 com-zabbix01p-pnd-ppp pengine[30731]: notice: Demote PGSQL_01:0 (Master -> Stopped com-zabbix02p-pnd-ppp)
　　Jan 14 17:53:08 com-zabbix01p-pnd-ppp pengine[30731]: notice: Demote PGSQL_01:1 (Master -> Slave com-zabbix01p-pnd-ppp)
　　Jan 14 17:53:08 com-zabbix01p-pnd-ppp pengine[30731]: notice: Stop VIP_01(com-zabbix01p-pnd-ppp)
　　Jan 14 17:53:08 com-zabbix01p-pnd-ppp pengine[30731]: notice: Stop ZabbixSV(com-zabbix01p-pnd-ppp)
　　→両系がMasterであることを検知し、両系Demote(Master->Slaveへ降格)することを
　　　判断。

　　Jan 14 17:53:08 com-zabbix01p-pnd-ppp crmd[30732]: notice: Initiating action 8:demote PGSQL_01_demote_0 on com-zabbix02p-pnd-ppp
　　Jan 14 17:53:08 com-zabbix01p-pnd-ppp crmd[30732]: notice: Initiating action 10: demote PGSQL_01_demote_0 on com-zabbix01p-pnd-ppp (local)
　　→両系でPostgreSQLのdemote(降格)を開始。

　　Jan 14 17:53:10 com-zabbix01p-pnd-ppp crmd[30732]: notice: Operation PGSQL_01_demote_0: ok (node=com-zabbix01p-pnd-ppp, call=35, rc=0, cib-update=169, confirmed=true)
　　→1系のPostgreSQLのdemote(降格)完了。

　　Jan 14 17:53:10 com-zabbix01p-pnd-ppp crmd[30732]: notice: Initiating action 35: stop ZabbixSV_stop_0 on com-zabbix01p-pnd-ppp (local)
　　Jan 14 17:53:10 com-zabbix01p-pnd-ppp zabbixserver(ZabbixSV)[2654]: ERROR: /usr/lib/ocf/lib/heartbeat/ocf-shellfuncs: line 433: kill: (32684) - No such process
　　Jan 14 17:53:10 com-zabbix01p-pnd-ppp zabbixserver(ZabbixSV)[2654]: INFO: Resource is not running
　　Jan 14 17:53:10 com-zabbix01p-pnd-ppp zabbixserver(ZabbixSV)[2654]: INFO: Resource is already stopped
　　Jan 14 17:53:10 com-zabbix01p-pnd-ppp crmd[30732]: notice: Operation ZabbixSV_stop_0: ok (node=com-zabbix01p-pnd-ppp, call=37, rc=0, cib-update=171, confirmed=true)
　　→Zabbixリソースの停止を行うが、既に停止済み(正常終了)
　　　(おそらく、Zabbixプロセスをkillしたため。)


　【2系ログ】
　　Jan 14 17:52:59 com-zabbix02p-pnd-ppp pacemakerd[23075]: notice: crm_reap_unseen_nodes: Node com-zabbix01p-pnd-ppp[1] - state is now lost (was member)
　　Jan 14 17:52:59 com-zabbix02p-pnd-ppp crmd[23081]: notice: crm_reap_unseen_nodes: Node com-zabbix01p-pnd-ppp[1] - state is now lost (was member)
　　→1系を見失う

　　Jan 14 17:53:01 com-zabbix02p-pnd-ppp corosync[23060]: [TOTEM ] A new membership (192.168.13.52:1648) was formed. Members
　　Jan 14 17:53:02 com-zabbix02p-pnd-ppp crmd[23081]: warning: Another DC detected: com-zabbix01p-pnd-ppp (op=noop)
　　→再び1系が接続。DCノードがバッティングしている旨Warning出力。

　　Jan 14 17:53:06 com-zabbix02p-pnd-ppp crmd[23081]: notice: Operation PGSQL_01_promote_0: ok (node=com-zabbix02p-pnd-ppp, call=20, rc=0, cib-update=51, confirmed=true)
　　→2系のPostgreSQLがpromote(Masterに昇格)

　　Jan 14 17:53:10 com-zabbix02p-pnd-ppp crmd[23081]: notice: Operation PGSQL_01_demote_0: ok (node=com-zabbix02p-pnd-ppp, call=24, rc=0, cib-update=53, confirmed=true)
　　→2系のPostgreSQLのdemote(降格)完了。


以上です。
よろしくお願い致します。


----- 元のメッセージ -----
From: "Pacemaker初心者" <m.hiraguchi@freebit.net>
宛先: linux-ha-japan@lists.osdn.me
送信済み: 2016年1月18日, 月曜日 午後 3:32:50
件名: Re: [Linux-ha-jp] クラスタの復旧およびPacemakerの挙動について

ひがし様

いつもお世話をお掛けします。


>それでは、故障時に何が起きていたのかを見たいので、以下情報を
>いただけますか？

>・Zabbixプロセス停止実施"後"のcrm_mon -Arf -1の表示内容 　(両系分)

⇒Zabbixプロセス停止実施後(直後)の出力が残っておりません。
　申し訳ありません。
　目視の結果をお伝えするしかないのですが、これまでの内容通り、
　　・クラスタ(pacemaker、corosyncは、Zabbix01(Master)/Zabbix02(Slave)共
に Running
　　・PostgreSQLリソースは、Zabbix01/Zabbix02共にStopped
　　・VIPリソースは、Zabbix01/Zabbix02共にStopped
　　・Zabbixserverリソースは、Zabbix01/Zabbix02共にStopped
　となります。

>・Zabbixプロセス停止前後の時間帯を含んだPacemakerのログ
　(両系分)

⇒Zabbix01、Zabbix02両機の/var/log/messages(該当時間帯を抽出したもの)を
　貼付します。


>・Zabbix故障後、Pacemakerが稼働しているノードで以下コマンドを実行し、
生成された/tmp/cib.xml。 　
>(Pacemakerに設定のリソース設定や属性値の内容等が含まれます。) 　
># cibadmin -Q > /tmp/cib.xml

⇒本日AMに出力した内容を貼付します。



お忙しい中、大変申し訳ありません。


On 2016/01/16 20:43, kazuh@goo.jp wrote:
> ひがしです。お世話になります。
>
> それでは、故障時に何が起きていたのかを見たいので、以下情報を
> いただけますか？
>
> ・Zabbixプロセス停止実施"後"のcrm_mon -Arf -1の表示内容
> 　(両系分)
>
> ・Zabbixプロセス停止前後の時間帯を含んだPacemakerのログ
> 　(両系分)
> 　・・・設定次第でファイル名は異なりますが通常、
> 　　　　/var/log/messagesや/var/log/ha-log。
>
> ・Zabbix故障後、Pacemakerが稼働しているノードで以下コマンドを実行し、
> 　生成された/tmp/cib.xml。
> 　(Pacemakerに設定のリソース設定や属性値の内容等が含まれます。)
> 　# cibadmin -Q > /tmp/cib.xml
>
>
> 以上です。
> よろしくお願い致します。
>
> ----- 元のメッセージ -----
> From: "Pacemaker初心者" <m.hiraguchi@freebit.net>
> 宛先: linux-ha-japan@lists.osdn.me
> 送信済み: 2016年1月15日, 金曜日 午後 6:16:58
> 件名: Re: [Linux-ha-jp] クラスタの復旧およびPacemakerの挙動について
>
> ひがし様
>
> 毎回ご回答頂きありがとうございます。
>
> ■クラスタ切戻し時のPostgresqlの復旧作業
>> 参考まで、recovery.confはPacemaker(pgsql RA)が自動的に作成するので、
>> 手動で作成(リネーム)する必要は無いですよ。
> ⇒そうなんですね。。。了解しました。
>
> ■ZabbixServerリソース障害時のクラスタ移動失敗
>
>> 思いつく（よくあるケース）で以下２つが考えられます。
>> (1)リソース停止失敗していないか？
>> ZabbixServer障害は、具体的にはどんな障害でしょうか？
> ⇒プロセス停止を想定し、「killall |grep zabbix_server」を実施しました。
> 　※クラスタリソース作成後は、〝systemctl stop zabbix-server〟が
> 　　効かないので、上記killallにて停止しました。
>
>
>> 今回の設定では、前回回答でも少し触れましたが、STONITH(排他制御)が設定
>> されていないようなので、リソースの停止が失敗するケースの故障時は、
>> フェイルオーバはできません。
>> 具体的には、各リソース設定の以下op stop～～行の「on-fail="block"」
>> というのが、「リソースの停止に失敗したら、フェイルオーバを中止(block)する」
>> ということを示しています。
>> 　op stop timeout="60s" interval="0s" on-fail="block"
>> STONITHを導入し、かつon-fail="fence"と設定すると、リソースの停止失敗時は
>> STONITHが発動し、相手ノードの電源を強制的に断した後、フェイルオーバが
>> 継続します。
> ⇒上記プロセス停止のケースであれば、zabbixserverリソースのmonitorの内容に
> 　従うという想定をしております。
> 　(op monitor timeout="60s" interval="0s" on-fail="restart" \)
>
> 　ちなみに、停止時のエラー発生した場合の挙動はSTONITHを使用しないため、、
> 　op stop timeout="60s" interval="0s" on-fail="block"
> 　としております。
> 　※本初期構築時点ではSTONITHは考えておらず、将来的にIPMI関連の整備が完了した
> 　　時点でSTONITHの導入を考えております。
>
>
>> (2)フェイルカウントや制約等が残っていないか？
>> フェイルオーバ先に、過去、故障や、手動リソース移動でついた制約が
>> 残ってしまってないでしょうか？
>> フェイルカウントは、「crm_mon -rfA」の表示の"Failed actions:"という
>> 最下部の欄に何か表示があれば、残った状態です。
>> 残っていると、Pacemakerはこのノードは故障していると判断し、
>> リソースは起動しません。
> ⇒Zabbixプロセス停止実施前のcrm_mon -Arf -1の表示内容からは、
> 　「Failed actions:」および異常を示す表示はされていません。
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
> # crm_mon -Arf -1
> Last updated: Thu Jan 14 16:47:49 2016 Last change: Thu Jan 14 16:45:38 2016 by root via crm_attribute on com-zabbix01p-pnd-ppp
> Stack: corosync
> Current DC: com-zabbix01p-pnd-ppp (version 1.1.13-10.el7-44eb2dd) - partition with quorum
> 2 nodes and 4 resources configured
>
> Online: [ com-zabbix01p-pnd-ppp com-zabbix02p-pnd-ppp ]
>
> Full list of resources:
>
> Master/Slave Set: msGrpPostgresql [PGSQL_01]
> Masters: [ com-zabbix01p-pnd-ppp ]
> Slaves: [ com-zabbix02p-pnd-ppp ]
> Resource Group: GrpVIP
> VIP_01 (ocf::heartbeat:IPaddr2): Started com-zabbix01p-pnd-ppp
> ZabbixSV (ocf::heartbeat:zabbixserver): Started com-zabbix01p-pnd-ppp
>
> Node Attributes:
> * Node com-zabbix01p-pnd-ppp:
> + PGSQL_01-data-status : LATEST
> + PGSQL_01-master-baseline : 00000000140000B8
> + PGSQL_01-status : PRI
> + master-PGSQL_01 : 1000
> * Node com-zabbix02p-pnd-ppp:
> + PGSQL_01-data-status : STREAMING|ASYNC
> + PGSQL_01-status : HS:async
> + master-PGSQL_01 : 100
>
> Migration Summary:
> * Node com-zabbix02p-pnd-ppp:
> * Node com-zabbix01p-pnd-ppp:
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>
> 現クラスタ定義を整理すると、
>
> 　①Zabbixserverリソースのオペレーション定義では、
> 　　moniter　interval=0s　timeout=60s　on-fail=restart
> 　　(startでもon-fail=restartであり、stopはon-fail=blockである)
>
> 　②リソースグループ定義では、
> 　　・Postgresqlグループでは、Postgresqlリソースのみ含む
> 　　　(Master/Slaveグループとして作成し、master-max=1、master-node-max=1
> 　　　、clone-max=2、clone-node-max=1、notify=trueとしている)
> 　　・VIPグループでは、VIPリソースとZabbixServerリソースの２つのリソースを含む
> 　　　(priority設定をしていないため、VIPグループ内の起動順序は、
> 　　　 VIPリソース⇒ZabbixServerリソースという起動になることを想定)
>
> 　③同居定義では、
> 　　Master状態のPostgresqlグループとVIPグループが、INFINITY。
>
> 　④起動順序定義では、
> 　　・Postgresqlグループをpromote⇒VIPグループをstartする。(INFINITY)
> 　　・Postgresqlグループをdemote⇒VIPグループをstopする。(0(強制せず))
>
> となっています。
> Postgresql障害(プロセスダウン)では、Postgresqlリソースが他のリソース起動前提
> となっているため、Postgresqlリソースがクラスタ移動すると他のリソースが連動する
> こととなり、正常に切り替わると考えてます。
>
> 今回のZabbixserver障害(プロセスダウン)を検知し、全リソースを移動(Postgresqlの
> 切替(移動＆promote)⇒VIPリソース移動⇒Zabbix起動)させる必要があるのですが、
> 下記定義内容にて不足している定義はありますか？
>
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
> ■クラスタ定義
> pcs property set no-quorum-policy="ignore"
> pcs property set stonith-enabled="false"
> pcs resource defaults resource-stickness="INFINITY"
> pcs resource defaults migration-threshold="1"
>
> ■VIPリソース定義
> pcs resource create VIP_01 IPaddr2 \
>> ip="192.168.13.125" \
>> nic="enp0s3" \
>> cidr_netmask="24" \
>> op start timeout="60s" interval="0s" on-fail="resstart" \
>> op monitor timeout="60s" interval="10s" on-fail="restart" \
>> op stop timeout="60s" interval="0s" on-fail="block" \
> ■PostgreSQLリソース定義
> pcs -f /tmp/cluster_cfg resource create PGSQL_01 pgsql \
>> pgctl="/usr/bin/pg_ctl" \
>> psql="/usr/bin/psql" \
>> pgdata="/var/lib/pgsql/data/" \
>> rep_mode="async" \
>> node_list="zabbix01 zabbix02" \
>> restore_command="cp /var/lib/pgsql/pg_arch/arc1/%f %p" \
>> primary_conninfo_opt="keepalives_idle=60 keepalives_interval=5 keepalives_count=5" \
>> master_ip="192.168.13.125" \
>> restart_on_promote='true' \
>> repuser="rep_user" \
>> start_opt="-i -p 5432" \
>> op start timeout="60s" interval="0s" on-fail="restart" \
>> op monitor timeout="60s" interval="4s" on-fail="restart" \
>> op monitor timeout="60s" interval="3s" on-fail="restart" role="Master" \
>> op promote timeout="60s" interval="0s" on-fail="restart" \
>> op demote timeout="60s" interval="0s" on-fail="stop" \
>> op stop timeout="60s" interval="0s" on-fail="block" \
>> op notify timeout="60s" interval="0s"
> ■同居・起動順序定義
> pcs resource master msGrpPostgresql PGSQL_01 \
>> master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true
> pcs resource group add GrpVIP VIP_01
> pcs constraint colocation add GrpVIP with Master msGrpPostgresql
> pcs constraint order promote msGrpPostgresql then start GrpVIP symmetrical=false score=INFINITY
> pcs constraint order demote msGrpPostgresql then stop GrpVIP symmetrical=false score=0
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>
> 何卒、ご助勢願います。
>
>
> On 2016/01/15 13:45, kazuh@goo.jp wrote:
>> ひがしです。お世話になります。
>>
>>> ⇒ご指摘の事項およびpg_basebackup、promote、recovery.done⇒recovery.confの
>>> リネーム等
>>> 　PostgreSQLの(Masterでの)起動条件を整理し復旧しました。
>> うまくいったのなら良かったです。
>> 参考まで、recovery.confはPacemaker(pgsql RA)が自動的に作成するので、
>> 手動で作成(リネーム)する必要は無いですよ。
>>
>>
>>> この内容で、PostgreSQL障害時はSlave(新マスタ)機へ問題なく切り替わりまし
>>> たが、
>>> ZabbixServer障害時はクラスタリソース全てがMaster、Slave共に停止してしま
>>> いました。
>> 思いつく（よくあるケース）で以下２つが考えられます。
>>
>> (1)リソース停止失敗していないか？
>> ZabbixServer障害は、具体的にはどんな障害でしょうか？
>> 今回の設定では、前回回答でも少し触れましたが、STONITH(排他制御)が設定
>> されていないようなので、リソースの停止が失敗するケースの故障時は、
>> フェイルオーバはできません。
>>
>> 具体的には、各リソース設定の以下op stop～～行の「on-fail="block"」
>> というのが、「リソースの停止に失敗したら、フェイルオーバを中止(block)する」
>> ということを示しています。
>> 　op stop timeout="60s" interval="0s" on-fail="block"
>>
>> STONITHを導入し、かつon-fail="fence"と設定すると、リソースの停止失敗時は
>> STONITHが発動し、相手ノードの電源を強制的に断した後、フェイルオーバが
>> 継続します。
>>
>> このあたり、詳細は、前回も紹介の以下資料をご覧ください。
>> 　　http://linux-ha.osdn.jp/wp/archives/4338
>> 　　　→試して覚えるPacemaker入門 排他制御機能編
>>
>>
>> (2)フェイルカウントや制約等が残っていないか？
>> フェイルオーバ先に、過去、故障や、手動リソース移動でついた制約が
>> 残ってしまってないでしょうか？
>>
>> フェイルカウントは、「crm_mon -rfA」の表示の"Failed actions:"という
>> 最下部の欄に何か表示があれば、残った状態です。
>> 残っていると、Pacemakerはこのノードは故障していると判断し、
>> リソースは起動しません。
>>
>> 前回紹介の以下資料P34の表示例を参考に、残っていればP36のコマンドで
>> フェイルカウントを削除してください。
>>> http://linux-ha.osdn.jp/wp/archives/4137
>>> 　→PG-REXで学ぶPacemaker運用の実例
>> また、crm_resource -M -r コマンドでリソースを手動で移動した後、
>> 「crm_resource -U -r ＜リソース名＞」を実行していない場合、
>> 移動元のノードにはリソースが起動できない制約が残ります。
>> (crm_mon -rfAL で確認できます。)
>> その場合、「crm_resource -U -r ＜リソース名＞」で制約を消してください。
>>
>>
>>
>> さて、上記はあくまでも推測で、今回の事象がそれに該当するかどうかは、
>> ログ等を確認しないとわかりません。
>> ZabbixServer障害発生時の、「crm_mon -Arf -1」やPacemakerのログ(両系分)が
>> あれば、もう少し今回の事象の原因を解析できると思います。
>>
>>
>> 以上です。よろしくお願いいたします。
>>
>> ----- 元のメッセージ -----
>> From: "Pacemaker初心者" <m.hiraguchi@freebit.net>
>> 宛先: linux-ha-japan@lists.osdn.me
>> 送信済み: 2016年1月14日, 木曜日 午後 8:53:15
>> 件名: Re: [Linux-ha-jp] クラスタの復旧およびPacemakerの挙動について
>>
>> ひがし様
>>
>> ご回答ありがとうございます。
>>
>> ＜確認１のご回答＞
>>> PG-REXでは、Pacemaker起動をMasterになってほしいノードから片方ずつ行い、
>>> そのPacemakerが完全に起動し、PostgreSQLがMasterになったことを確認してから、
>>> もう片方を起動する、というように起動する必要があります。
>>> Pacemakerからすると、2ノード同時に起動された場合、どちらのノードを優先して
>>> Masterにすべきか判断できないためです。
>>> 今回の場合、Slave(新Master)のみを先に起動すれば、きちんとMasterになったかと
>>> 思います。
>> ⇒本ケースの再現がありましたので、Slave(新Master)機⇒Master(新Slave)機の順で、
>> 　クラスタ起動を行いました。
>>
>> ＜確認２のご回答＞
>>> ログを確認しないと断定はできませんが、両系でPGSQL.lockファイルが残存している
>>> 可能性があります。
>>> これは、データが古い可能性があることをユーザに気づかせるための印で、
>>> Pacemaker(pgsql RA)が正常停止するときのみ削除されます。つまり、異常停止時
>>> には残存し、異常停止した旨をユーザに気づかせるものです。
>>> 通常、postgreユーザのホーム配下のtmp/(/var/lib/pgsql/tmp/)にあります。
>>> データ復旧後、またはデータが古い可能性があること承知の上で、当該ノードの
>>> PostgreSQLを起動する際は、このファイルを手動で削除する必要があります
>> ⇒ご指摘の事項およびpg_basebackup、promote、recovery.done⇒recovery.confの
>> リネーム等
>> 　PostgreSQLの(Masterでの)起動条件を整理し復旧しました。
>>
>> ＜確認３のご回答＞
>>> 構築後、一度きちんと起動しているようなので、設定に問題は無いかと
>>> 思います。
>>> ＃STONITH, SFEX, VIPcheck等の排他制御は設定されていないようなので、
>>> 　スプリットブレイン発生時は両系ノードがMasterになってしまうのが
>>> 　問題と言えば問題ですが、今回の事象とは関係ないと思います。
>> ⇒クラスタ起動に連動し、PostgreSQLが起動するようになりました。
>> 　※関係ないかもしれませんが、前回との変更点は、PostgreSQLリソースに
>> 　「start_option="-i -p 5432"」の追加です。
>>
>>
>> ■新たな確認事項
>> 　VIP、PostgreSQLのクラスタリソースおよびグループ以外のリソース(Zabbix)
>> を追加しました。
>>
>> 　■zabbixリソースの作成内容
>> # pcs resource create ZabbixSV zabbixserver \
>> > binary="/usr/sbin/zabbix_server" \
>> > pid="/var/run/zabbix/zabbix_server.pid" \
>> > config="/etc/zabbix/zabbix_server.conf" \
>> > op start timeout="60s" interval="0s" on-fail="restart" \
>> > op monitor timeout="60s" interval="0s" on-fail="restart" \
>> > op stop timeout="60s" interval="0s" on-fail="block"
>>
>> 　■zabbixリソースのグループ登録(VIPリソースグループへの追加)
>> # pcs resource group add GrpVIP ZabbixSV
>> # pcs resource group list
>> GrpVIP: VIP_01 ZabbixSV
>>
>>
>> ※フェイルオーバー時の起動順序は、
>> 　　①PostgreSQLのPromote
>> 　　②VIP付与
>> 　　③ZabbixServer起動
>> 　を想定しています。
>>
>> この内容で、PostgreSQL障害時はSlave(新マスタ)機へ問題なく切り替わりまし
>> たが、
>> ZabbixServer障害時はクラスタリソース全てがMaster、Slave共に停止してしま
>> いました。
>>
>> PostgreSQLに依存するクラスタリソースの登録について
>> ご教示願います。
>>
>> ご助勢の程、宜しくお願い致します。
>>
>>
>>
>> On 2016/01/14 13:48, kazuh@goo.jp wrote:
>>> ひがしと申します。
>>> お世話になります。
>>>
>>>
>>>> ＜確認１＞
>>>> 　Slave(新Master)にてフェイルオーバー後の状態を継続するものと想定して
>>>> 　いましたが、OS停止をした場合はこの様な挙動になるのは正しいのでしょうか？
>>> PG-REXでは、Pacemaker起動をMasterになってほしいノードから片方ずつ行い、
>>> そのPacemakerが完全に起動し、PostgreSQLがMasterになったことを確認してから、
>>> もう片方を起動する、というように起動する必要があります。
>>> Pacemakerからすると、2ノード同時に起動された場合、どちらのノードを優先して
>>> Masterにすべきか判断できないためです。
>>>
>>> 今回の場合、Slave(新Master)のみを先に起動すれば、きちんとMasterになったかと
>>> 思います。
>>>
>>>
>>>> ＜確認２＞
>>>> 　クラスタの復旧作業として①と②以外に行うことはありますか？
>>>> 　(※VIP_01はdebug-atartにて強制起動し、PostgreSQLは手動起動しましたが、
>>>> 　未だ〝stopped〟のままです。)
>>> ログを確認しないと断定はできませんが、両系でPGSQL.lockファイルが残存している
>>> 可能性があります。
>>>
>>> これは、データが古い可能性があることをユーザに気づかせるための印で、
>>> Pacemaker(pgsql RA)が正常停止するときのみ削除されます。つまり、異常停止時
>>> には残存し、異常停止した旨をユーザに気づかせるものです。
>>> 通常、postgreユーザのホーム配下のtmp/(/var/lib/pgsql/tmp/)にあります。
>>>
>>> データ復旧後、またはデータが古い可能性があること承知の上で、当該ノードの
>>> PostgreSQLを起動する際は、このファイルを手動で削除する必要があります。
>>>
>>>
>>>
>>> なお、手前味噌になりますが、昨年福岡で開催のオープンソースカンファレンスにて
>>> PG-REXの故障時の挙動や運用方法をまとめた講演を行いました。
>>> PostgreSQLプロセス停止後の復旧は、以下P42に掲載しています。
>>>
>>> http://linux-ha.osdn.jp/wp/archives/4137
>>> 　→PG-REXで学ぶPacemaker運用の実例
>>> 　　　P42 vip-master故障時の復旧方法
>>>
>>>
>>>> ＜確認３＞
>>>> 　そもそもの話なのですが、クラスタ起動時にVIP付与とPostgreSQL起動が
>>>> 　されない状態です。(PostgreSQLは手動起動してます)
>>>> 　設定内容を以下に示すので、不足している設定をご教示願います。
>>> 構築後、一度きちんと起動しているようなので、設定に問題は無いかと
>>> 思います。
>>> ＃STONITH, SFEX, VIPcheck等の排他制御は設定されていないようなので、
>>> 　スプリットブレイン発生時は両系ノードがMasterになってしまうのが
>>> 　問題と言えば問題ですが、今回の事象とは関係ないと思います。
>>> 　排他制御については、以下講演が詳しいです。
>>> 　　http://linux-ha.osdn.jp/wp/archives/4338
>>> 　　　→試して覚えるPacemaker入門 排他制御機能編
>>>
>>>
>>> 一度、以下の順に、起動・停止をやりなおしてみてはいかがでしょうか？
>>> (上記PGSQL.lockや片系ずつ起動、を踏まえた手順案です。)
>>>
>>> 　1) 一旦、両系のPacemakerをSlave→Masterの順に片系ずつ停止
>>> 　2) 一旦、手動起動した両系のPostgreSQLをSlave→Masterの順に片系ずつ停止
>>> 　3) 両系の/var/lib/pgsql/tmp/PGSQL.lock　を削除
>>> 　4) さきほどMasterだった方のノードのPacemakerを起動
>>> 　　 →crm_mon等でPostgreSQLがMasterになることを確認
>>> 　5) pg_basebackupを実行し、現Masterの最新データをSlaveにコピー
>>> 　6) SlaveのPacemakerを起動
>>>
>>>
>>> これでも起動しない場合、両系分のPacemakerとPostgreSQLのログを見てみる
>>> 必要があります。
>>>
>>>
>>> 以上です。
>>> よろしくお願いいたします。
>>>
>>>
>>> ----- 元のメッセージ -----
>>> From: "Pacemaker初心者" <m.hiraguchi@freebit.net>
>>> 宛先: linux-ha-japan@lists.osdn.me
>>> 送信済み: 2016年1月8日, 金曜日 午後 6:38:26
>>> 件名: [Linux-ha-jp] クラスタの復旧およびPacemakerの挙動について
>>>
>>> お世話になります。
>>>
>>> 先般、PG-REXでのPacemaker構築にて上手くいかなかったので、勉強がてら
>>> pcsコマンドにて再構築を行いました。
>>>
>>> [環境]
>>> OS ：CentOS7.1
>>> PostgresSQL ：postgresql-server-9.2.13-1
>>> Pacemaker ：pacemaker-1.1.12-22
>>>
>>>
>>> 構築後に諸々問題点が発生しており、ご助勢頂けると助かります。
>>> 以下、状況を順に記します。
>>>
>>>
>>> (１)構築後の状況
>>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>> # crm_mon -Arf -1
>>> Last updated: Tue Jan 5 21:39:19 2016
>>> Last change: Tue Jan 5 21:38:46 2016 by hacluster via crmd on zabbix01
>>> Stack: corosync
>>> Current DC: zabbix01(1) - partition with quorum
>>> Version: 1.1.12-561c4cf
>>> 2 Nodes configured
>>> 3 Resources configured
>>>
>>> Online: [ zabbix01 zabbix02 ]
>>>
>>> Full list of resources:
>>>
>>> Master/Slave Set: msPostgresql [pgsql]
>>> Masters: [ zabbix01 ]
>>> Slaves: [ zabbix02 ]
>>> Resource Group: master-group
>>> VIP_01 (ocf::heartbeat:IPaddr2): Started zabbix01
>>>
>>> Node Attributes:
>>> * Node zabbix01:
>>> + #cluster-name : zabbixcluster
>>> + #site-name : zabbixcluster
>>> + master-pgsql : 1000
>>> + pgsql-data-status : LATEST
>>> + pgsql-master-baseline : 0000000016000080
>>> + pgsql-status : PRI
>>> * Node zabbix02:
>>> + #cluster-name : zabbixcluster
>>> + #site-name : zabbixcluster
>>> + master-pgsql : 100
>>> + pgsql-data-status : STREAMING|ASYNC
>>> + pgsql-status : HS:async
>>>
>>> Migration summary:
>>> * Node zabbix02:
>>> * Node zabbix01:
>>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>>
>>>
>>> (２)Slaveへの切替
>>> 切替テストとして、Zabbix01のPostgresqlを停止しました。
>>> 停止後のクラスタの状態(下記)としては問題ないと思ってます。
>>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>> # crm_mon -Arf -1
>>> Last updated: Wed Jan 6 00:45:32 2016
>>> Last change: Wed Jan 6 00:30:22 2016 by hacluster via crmd on zabbix01
>>> Stack: corosync
>>> Current DC: zabbix01 (1) - partition with quorum
>>> Version: 1.1.12-561c4cf
>>> 2 Nodes configured
>>> 3 Resources configured
>>>
>>> Online: [ zabbix01 zabbix02 ]
>>>
>>> Full list of resources:
>>>
>>> Master/Slave Set: msPostgresql [pgsql]
>>> Masters: [ zabbix02 ]
>>> Stopped: [ zabbix01 ]
>>> Resource Group: master-group
>>> VIP_01 (ocf::heartbeat:IPaddr2): Started zabbix02p
>>>
>>> Node Attributes:
>>> * Node zabbix01:
>>> + #cluster-name : zabbixcluster
>>> + #site-name : zabbixcluster
>>> + master-pgsql : -INFINITY
>>> + pgsql-data-status : DISCONNECT
>>> + pgsql-status : STOP
>>> * Node zabbix02:
>>> + #cluster-name : zabbixcluster
>>> + #site-name : zabbixcluster
>>> + master-pgsql : 1000
>>> + pgsql-data-status : LATEST
>>> + pgsql-master-baseline : 0000000017000080
>>> + pgsql-status : PRI
>>>
>>> Migration summary:
>>> * Node zabbix02:
>>> * Node zabbix01:
>>> pgsql: migration-threshold=1 fail-count=1 last-failure='Wed Jan 6
>>> 00:30:13 2016'
>>>
>>> Failed actions:
>>> pgsql_monitor_3000 on zabbix01 'unknown error' (1): call=126,
>>> status=complete, last-rc-change='Wed Jan 6 00:30:13 2016', queued=0ms,
>>> exec=0ms
>>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>>
>>>
>>> (３)
>>> この後、切戻しを行う際に当方の不手際で、Master(Zabbix01)とSlave(Zabbix02)
>>> のOS停止をしてしまいました。
>>> 停止後、両機を起動しましたが、「pcs status」および「crm_mon -Arf -1」
>>> でのmaster-group(VIP_01)、msPostgresql(pgsql)のリソースのステータスが、
>>> 〝stopped〟となっていました。
>>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>> # pcs status
>>> Cluster name: zabbixcluster
>>> Last updated: Thr Jan 7 17:11:58 2016
>>> Last change: Thr Jan 7 15:57:37 2016 by hacluster via crmd on zabbix01
>>> Stack: corosync
>>> Current DC: zabbix02 (1) - partition with quorum
>>> Version: 1.1.12-561c4cf
>>> 2 Nodes configured
>>> 3 Resources configured
>>>
>>>
>>> Online: [ zabbix01 zabbix02 ]
>>>
>>> Full list of resources:
>>>
>>> Master/Slave Set: msPostgresql [pgsql]
>>> Stopped: [ zabbix01 zabbix02 ]
>>> Resource Group: master-group
>>> VIP_01 (ocf::heartbeat:IPaddr2): Stopped
>>>
>>> PCSD Status:
>>> zabbix01 (192.168.252.182): Online
>>> zabbix02 (192.168.252.183): Online
>>>
>>> Daemon Status:
>>> corosync: active/enabled
>>> pacemaker: active/enabled
>>> pcsd: active/enabled
>>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>>
>>> ＜確認１＞
>>> 　Slave(新Master)にてフェイルオーバー後の状態を継続するものと想定して
>>> 　いましたが、OS停止をした場合はこの様な挙動になるのは正しいのでしょうか？
>>>
>>>
>>> (４)復旧
>>> pg_basebackup、pg_ctl promote等を行い、PostgreSQLの戻しを行いました。
>>> (※「psql -h localhost -c "SELECT pg_is_in_recovery();"」にて
>>> 両PostgresSQLの起動状態(Zabbix01：f、Zabbix02：t)と、ストリーミング
>>> レプリケーションの動作を確認済)
>>>
>>> PostgreSQLの状態復旧を行った後に、
>>> 　①pcs resource cleanup msPostgresqlとpcs resource cleanup master-group
>>> 　②pcs cluster stop --allとpcs cluster start --all
>>> にて復旧を試みましたが、両リソースの状態は〝stopped〟のままです。
>>>
>>> ＜確認２＞
>>> 　クラスタの復旧作業として①と②以外に行うことはありますか？
>>> 　(※VIP_01はdebug-atartにて強制起動し、PostgreSQLは手動起動しましたが、
>>> 　未だ〝stopped〟のままです。)
>>>
>>>
>>> ＜確認３＞
>>> 　そもそもの話なのですが、クラスタ起動時にVIP付与とPostgreSQL起動が
>>> 　されない状態です。(PostgreSQLは手動起動してます)
>>> 　設定内容を以下に示すので、不足している設定をご教示願います。
>>>
>>> ■設定内容
>>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>> pcs -f cluster_cfg property set no-quorum-policy="ignore"
>>> pcs -f cluster_cfg property set stonith-enabled="false"
>>> pcs -f cluster_cfg resource defaults resource-stickiness="INFINITY"
>>> pcs -f cluster_cfg resource defaults migration-threshold="1"
>>>
>>> pcs -f cluster_cfg resource create VIP_01 IPaddr2 \
>>> ip="192.168.252.184" \
>>> nic="enp0s3" \
>>> cidr_netmask="24" \
>>> op start timeout="60s" interval="0s" on-fail="restart" \
>>> op monitor timeout="60s" interval="10s" on-fail="restart" \
>>> op stop timeout="60s" interval="0s" on-fail="block"
>>>
>>> pcs -f cluster_cfg resource create pgsql pgsql \
>>> pgctl="/usr/bin/pg_ctl" \
>>> psql="/usr/bin/psql" \
>>> pgdata="/var/lib/pgsql/data/" \
>>> rep_mode="async" \
>>> node_list="zabbix01 zabbix02" \
>>> restore_command="cp /var/lib/pgsql/pg_archive/%f %p" \
>>> primary_conninfo_opt="keepalives_idle=60 keepalives_interval=5
>>> keepalives_count=5" \
>>> master_ip="192.168.252.184" \
>>> restart_on_promote='true' \
>>> op start timeout="60s" interval="0s" on-fail="restart" \
>>> op monitor timeout="60s" interval="4s" on-fail="restart" \
>>> op monitor timeout="60s" interval="3s" on-fail="restart"
>>> role="Master" \
>>> op promote timeout="60s" interval="0s" on-fail="restart" \
>>> op demote timeout="60s" interval="0s" on-fail="stop" \
>>> op stop timeout="60s" interval="0s" on-fail="block" \
>>> op notify timeout="60s" interval="0s"
>>>
>>> pcs -f cluster_cfg resource master msPostgresql pgsql \
>>> master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true
>>>
>>> pcs -f cluster_cfg resource group add master-group VIP_01
>>>
>>> pcs -f pgsql_cfg constraint colocation add master-group with Master
>>> msPostgresql INFINITY
>>> pcs -f pgsql_cfg constraint order promote msPostgresql then start
>>> master-group symmetrical=false score=INFINITY
>>> pcs -f pgsql_cfg constraint order demote msPostgresql then stop
>>> master-group symmetrical=false score=0
>>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>>
>>> (上記を「pcs cluster cib-push cluster_cfg」にて反映しています)
>>>
>>> _______________________________________________
>>> Linux-ha-japan mailing list
>>> Linux-ha-japan@lists.osdn.me
>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>> _______________________________________________
>>> Linux-ha-japan mailing list
>>> Linux-ha-japan@lists.osdn.me
>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan


_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan
_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan

ひがし様

ご回答ありがとうございます。


おかげさまで、Zabbixserverプロセスのダウンにて、クラスタ切替ができました。
※修正はZabbixserverリソース：op monitorのintervalを見直しのみです。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
# killall zabbix_server

# ps -ef |grep zabbix_server
root 6572 2075 0 15:50 pts/0 00:00:00 grep --color=auto
zabbix_server

# crm_mon -Arf -1
Last updated: Mon Jan 18 15:50:53 2016 Last change: Mon Jan 18
15:50:46 2016 by root via crm_attribute on zabbix02
Stack: corosync
Current DC: zabbix02 (version 1.1.13-10.el7-44eb2dd) - partition with quorum
2 nodes and 4 resources configured

Online: [ zabbix01 zabbix02 ]

Full list of resources:

Master/Slave Set: msGrpPostgresql [PGSQL_01]
Masters: [ zabbix02 ]
Stopped: [ zabbix01 ]
Resource Group: GrpVIP
VIP_01 (ocf::heartbeat:IPaddr2): Started zabbix02
ZabbixSV (ocf::heartbeat:zabbixserver): Started zabbix02

Node Attributes:
* Node zabbix01:
+ PGSQL_01-data-status : DISCONNECT
+ PGSQL_01-status : STOP
+ master-PGSQL_01 : -INFINITY
* Node zabbix02:
+ PGSQL_01-data-status : LATEST
+ PGSQL_01-master-baseline : 0000000029000080
+ PGSQL_01-status : PRI
+ master-PGSQL_01 : 1000

Migration Summary:
* Node zabbix02:
* Node zabbix01:
PGSQL_01: migration-threshold=1 fail-count=1 last-failure='Mon Jan
18 15:50:47 2016'
ZabbixSV: migration-threshold=1 fail-count=1 last-failure='Mon Jan
18 15:50:39 2016'

Failed Actions:
* PGSQL_01_monitor_4000 on zabbix01 'not running' (7): call=37,
status=complete, exitreason='none',
last-rc-change='Mon Jan 18 15:50:48 2016', queued=0ms, exec=174ms
* ZabbixSV_monitor_3000 on zabbix01 'not running' (7): call=26,
status=complete, exitreason='none',
last-rc-change='Mon Jan 18 15:50:40 2016', queued=0ms, exec=0ms
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

基本的な動きが出来るようになりました。
感謝です!!　ありがとうございました。

尚、ご指摘のスプリットブレイン対策(STONITH導入)/動作検証は、今週行う予定
です。



On 2016/01/18 17:20, kazuh@goo.jp wrote:
> ひがしです。お世話になります。
>
>> ⇒Zabbix01、Zabbix02両機の/var/log/messages(該当時間帯を抽出したもの)を
>> 　貼付します。
> 17:52:58に、両系のHeartbeat通信が一瞬途切れ、その後17:53:02ごろにまたつながる、
> という事象があったように読み取れます。
> これにより、いわゆるスプリットブレイン状態になり、一時、両系がMasterになってい
> ます。(17:53:06に2系のPostgreSQLがpromote(Masterに昇格)している。)
>
> その後、Pacemakerは両系がMasterになったことを検知し、安全のため、両系のPostgreSQL
> をSlave状態にすべく、demote(降格処理)を実行したようです。そのため、両系でリソース
> が停止しました。
>
> 今回の構成は、STONITHやVIPcheck等の排他制御が導入されていないため、上記のような
> スプリットブレインを防ぐことができません。
>
> 17:52:58ごろ、両系のネットワーク通信路が切れる、または、ノードが高負荷で一時的に
> 通信ができなかった、等、両系のHeartbeat通信が一瞬途切れた原因に心当たりはないで
> しょうか？
> (高負荷の原因でよくあるのは、ノードのメモリ不足でスワップが発生した、や、ウィルス
> ソフト等によるスキャンが始まった等があります。ノードが仮想マシンの場合、ホスト側
> の高負荷や、仮想マシンに割り当てるメモリ量の不足(=スワップ発生)も疑う必要があり
> ます。)
>
>
> いずれにせよ、今回の事象は単なるZabbix故障とは違って、Heartbeat通信が途切れる
> という事象が重なったものと思われます。
>
>
> 以下、Pacemakerのログ抜粋です。
>
> 　【1系ログ】
> 　　Jan 14 17:52:58 com-zabbix01p-pnd-ppp pacemakerd[30726]: notice: crm_reap_unseen_nodes: Node com-zabbix02p-pnd-ppp[2] - state is now lost (was member)
> 　　Jan 14 17:52:58 com-zabbix01p-pnd-ppp crmd[30732]: notice: crm_reap_unseen_nodes: Node com-zabbix02p-pnd-ppp[2] - state is now lost (was member)
> 　　→2系を見失う
>
> 　　Jan 14 17:53:02 com-zabbix01p-pnd-ppp corosync[30711]: [TOTEM ] A new membership (192.168.13.52:1652) was formed. Members joined: 2
> 　　Jan 14 17:53:02 com-zabbix01p-pnd-ppp crmd[30732]: warning: Another DC detected: com-zabbix02p-pnd-ppp (op=noop)
> 　　→再び2系が接続。DCノードがバッティングしている旨Warning出力。
>
> 　　Jan 14 17:53:08 com-zabbix01p-pnd-ppp pengine[30731]: notice: Demote PGSQL_01:0 (Master -> Stopped com-zabbix02p-pnd-ppp)
> 　　Jan 14 17:53:08 com-zabbix01p-pnd-ppp pengine[30731]: notice: Demote PGSQL_01:1 (Master -> Slave com-zabbix01p-pnd-ppp)
> 　　Jan 14 17:53:08 com-zabbix01p-pnd-ppp pengine[30731]: notice: Stop VIP_01(com-zabbix01p-pnd-ppp)
> 　　Jan 14 17:53:08 com-zabbix01p-pnd-ppp pengine[30731]: notice: Stop ZabbixSV(com-zabbix01p-pnd-ppp)
> 　　→両系がMasterであることを検知し、両系Demote(Master->Slaveへ降格)することを
> 　　　判断。
>
> 　　Jan 14 17:53:08 com-zabbix01p-pnd-ppp crmd[30732]: notice: Initiating action 8:demote PGSQL_01_demote_0 on com-zabbix02p-pnd-ppp
> 　　Jan 14 17:53:08 com-zabbix01p-pnd-ppp crmd[30732]: notice: Initiating action 10: demote PGSQL_01_demote_0 on com-zabbix01p-pnd-ppp (local)
> 　　→両系でPostgreSQLのdemote(降格)を開始。
>
> 　　Jan 14 17:53:10 com-zabbix01p-pnd-ppp crmd[30732]: notice: Operation PGSQL_01_demote_0: ok (node=com-zabbix01p-pnd-ppp, call=35, rc=0, cib-update=169, confirmed=true)
> 　　→1系のPostgreSQLのdemote(降格)完了。
>
> 　　Jan 14 17:53:10 com-zabbix01p-pnd-ppp crmd[30732]: notice: Initiating action 35: stop ZabbixSV_stop_0 on com-zabbix01p-pnd-ppp (local)
> 　　Jan 14 17:53:10 com-zabbix01p-pnd-ppp zabbixserver(ZabbixSV)[2654]: ERROR: /usr/lib/ocf/lib/heartbeat/ocf-shellfuncs: line 433: kill: (32684) - No such process
> 　　Jan 14 17:53:10 com-zabbix01p-pnd-ppp zabbixserver(ZabbixSV)[2654]: INFO: Resource is not running
> 　　Jan 14 17:53:10 com-zabbix01p-pnd-ppp zabbixserver(ZabbixSV)[2654]: INFO: Resource is already stopped
> 　　Jan 14 17:53:10 com-zabbix01p-pnd-ppp crmd[30732]: notice: Operation ZabbixSV_stop_0: ok (node=com-zabbix01p-pnd-ppp, call=37, rc=0, cib-update=171, confirmed=true)
> 　　→Zabbixリソースの停止を行うが、既に停止済み(正常終了)
> 　　　(おそらく、Zabbixプロセスをkillしたため。)
>
>
> 　【2系ログ】
> 　　Jan 14 17:52:59 com-zabbix02p-pnd-ppp pacemakerd[23075]: notice: crm_reap_unseen_nodes: Node com-zabbix01p-pnd-ppp[1] - state is now lost (was member)
> 　　Jan 14 17:52:59 com-zabbix02p-pnd-ppp crmd[23081]: notice: crm_reap_unseen_nodes: Node com-zabbix01p-pnd-ppp[1] - state is now lost (was member)
> 　　→1系を見失う
>
> 　　Jan 14 17:53:01 com-zabbix02p-pnd-ppp corosync[23060]: [TOTEM ] A new membership (192.168.13.52:1648) was formed. Members
> 　　Jan 14 17:53:02 com-zabbix02p-pnd-ppp crmd[23081]: warning: Another DC detected: com-zabbix01p-pnd-ppp (op=noop)
> 　　→再び1系が接続。DCノードがバッティングしている旨Warning出力。
>
> 　　Jan 14 17:53:06 com-zabbix02p-pnd-ppp crmd[23081]: notice: Operation PGSQL_01_promote_0: ok (node=com-zabbix02p-pnd-ppp, call=20, rc=0, cib-update=51, confirmed=true)
> 　　→2系のPostgreSQLがpromote(Masterに昇格)
>
> 　　Jan 14 17:53:10 com-zabbix02p-pnd-ppp crmd[23081]: notice: Operation PGSQL_01_demote_0: ok (node=com-zabbix02p-pnd-ppp, call=24, rc=0, cib-update=53, confirmed=true)
> 　　→2系のPostgreSQLのdemote(降格)完了。
>
>
> 以上です。
> よろしくお願い致します。
>
>
> ----- 元のメッセージ -----
> From: "Pacemaker初心者" <m.hiraguchi@freebit.net>
> 宛先: linux-ha-japan@lists.osdn.me
> 送信済み: 2016年1月18日, 月曜日 午後 3:32:50
> 件名: Re: [Linux-ha-jp] クラスタの復旧およびPacemakerの挙動について
>
> ひがし様
>
> いつもお世話をお掛けします。
>
>
>> それでは、故障時に何が起きていたのかを見たいので、以下情報を
>> いただけますか？
> >・Zabbixプロセス停止実施"後"のcrm_mon -Arf -1の表示内容 　(両系分)
>
> ⇒Zabbixプロセス停止実施後(直後)の出力が残っておりません。
> 　申し訳ありません。
> 　目視の結果をお伝えするしかないのですが、これまでの内容通り、
> 　　・クラスタ(pacemaker、corosyncは、Zabbix01(Master)/Zabbix02(Slave)共
> に Running
> 　　・PostgreSQLリソースは、Zabbix01/Zabbix02共にStopped
> 　　・VIPリソースは、Zabbix01/Zabbix02共にStopped
> 　　・Zabbixserverリソースは、Zabbix01/Zabbix02共にStopped
> 　となります。
>
>> ・Zabbixプロセス停止前後の時間帯を含んだPacemakerのログ
> 　(両系分)
>
> ⇒Zabbix01、Zabbix02両機の/var/log/messages(該当時間帯を抽出したもの)を
> 　貼付します。
>
>
> >・Zabbix故障後、Pacemakerが稼働しているノードで以下コマンドを実行し、
> 生成された/tmp/cib.xml。 　
> >(Pacemakerに設定のリソース設定や属性値の内容等が含まれます。) 　
> ># cibadmin -Q > /tmp/cib.xml
>
> ⇒本日AMに出力した内容を貼付します。
>
>
>
> お忙しい中、大変申し訳ありません。
>
>
> On 2016/01/16 20:43, kazuh@goo.jp wrote:
>> ひがしです。お世話になります。
>>
>> それでは、故障時に何が起きていたのかを見たいので、以下情報を
>> いただけますか？
>>
>> ・Zabbixプロセス停止実施"後"のcrm_mon -Arf -1の表示内容
>> 　(両系分)
>>
>> ・Zabbixプロセス停止前後の時間帯を含んだPacemakerのログ
>> 　(両系分)
>> 　・・・設定次第でファイル名は異なりますが通常、
>> 　　　　/var/log/messagesや/var/log/ha-log。
>>
>> ・Zabbix故障後、Pacemakerが稼働しているノードで以下コマンドを実行し、
>> 　生成された/tmp/cib.xml。
>> 　(Pacemakerに設定のリソース設定や属性値の内容等が含まれます。)
>> 　# cibadmin -Q > /tmp/cib.xml
>>
>>
>> 以上です。
>> よろしくお願い致します。
>>
>> ----- 元のメッセージ -----
>> From: "Pacemaker初心者" <m.hiraguchi@freebit.net>
>> 宛先: linux-ha-japan@lists.osdn.me
>> 送信済み: 2016年1月15日, 金曜日 午後 6:16:58
>> 件名: Re: [Linux-ha-jp] クラスタの復旧およびPacemakerの挙動について
>>
>> ひがし様
>>
>> 毎回ご回答頂きありがとうございます。
>>
>> ■クラスタ切戻し時のPostgresqlの復旧作業
>>> 参考まで、recovery.confはPacemaker(pgsql RA)が自動的に作成するので、
>>> 手動で作成(リネーム)する必要は無いですよ。
>> ⇒そうなんですね。。。了解しました。
>>
>> ■ZabbixServerリソース障害時のクラスタ移動失敗
>>
>>> 思いつく（よくあるケース）で以下２つが考えられます。
>>> (1)リソース停止失敗していないか？
>>> ZabbixServer障害は、具体的にはどんな障害でしょうか？
>> ⇒プロセス停止を想定し、「killall |grep zabbix_server」を実施しました。
>> 　※クラスタリソース作成後は、〝systemctl stop zabbix-server〟が
>> 　　効かないので、上記killallにて停止しました。
>>
>>
>>> 今回の設定では、前回回答でも少し触れましたが、STONITH(排他制御)が設定
>>> されていないようなので、リソースの停止が失敗するケースの故障時は、
>>> フェイルオーバはできません。
>>> 具体的には、各リソース設定の以下op stop～～行の「on-fail="block"」
>>> というのが、「リソースの停止に失敗したら、フェイルオーバを中止(block)する」
>>> ということを示しています。
>>> 　op stop timeout="60s" interval="0s" on-fail="block"
>>> STONITHを導入し、かつon-fail="fence"と設定すると、リソースの停止失敗時は
>>> STONITHが発動し、相手ノードの電源を強制的に断した後、フェイルオーバが
>>> 継続します。
>> ⇒上記プロセス停止のケースであれば、zabbixserverリソースのmonitorの内容に
>> 　従うという想定をしております。
>> 　(op monitor timeout="60s" interval="0s" on-fail="restart" \)
>>
>> 　ちなみに、停止時のエラー発生した場合の挙動はSTONITHを使用しないため、、
>> 　op stop timeout="60s" interval="0s" on-fail="block"
>> 　としております。
>> 　※本初期構築時点ではSTONITHは考えておらず、将来的にIPMI関連の整備が完了した
>> 　　時点でSTONITHの導入を考えております。
>>
>>
>>> (2)フェイルカウントや制約等が残っていないか？
>>> フェイルオーバ先に、過去、故障や、手動リソース移動でついた制約が
>>> 残ってしまってないでしょうか？
>>> フェイルカウントは、「crm_mon -rfA」の表示の"Failed actions:"という
>>> 最下部の欄に何か表示があれば、残った状態です。
>>> 残っていると、Pacemakerはこのノードは故障していると判断し、
>>> リソースは起動しません。
>> ⇒Zabbixプロセス停止実施前のcrm_mon -Arf -1の表示内容からは、
>> 　「Failed actions:」および異常を示す表示はされていません。
>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>> # crm_mon -Arf -1
>> Last updated: Thu Jan 14 16:47:49 2016 Last change: Thu Jan 14 16:45:38 2016 by root via crm_attribute on com-zabbix01p-pnd-ppp
>> Stack: corosync
>> Current DC: com-zabbix01p-pnd-ppp (version 1.1.13-10.el7-44eb2dd) - partition with quorum
>> 2 nodes and 4 resources configured
>>
>> Online: [ com-zabbix01p-pnd-ppp com-zabbix02p-pnd-ppp ]
>>
>> Full list of resources:
>>
>> Master/Slave Set: msGrpPostgresql [PGSQL_01]
>> Masters: [ com-zabbix01p-pnd-ppp ]
>> Slaves: [ com-zabbix02p-pnd-ppp ]
>> Resource Group: GrpVIP
>> VIP_01 (ocf::heartbeat:IPaddr2): Started com-zabbix01p-pnd-ppp
>> ZabbixSV (ocf::heartbeat:zabbixserver): Started com-zabbix01p-pnd-ppp
>>
>> Node Attributes:
>> * Node com-zabbix01p-pnd-ppp:
>> + PGSQL_01-data-status : LATEST
>> + PGSQL_01-master-baseline : 00000000140000B8
>> + PGSQL_01-status : PRI
>> + master-PGSQL_01 : 1000
>> * Node com-zabbix02p-pnd-ppp:
>> + PGSQL_01-data-status : STREAMING|ASYNC
>> + PGSQL_01-status : HS:async
>> + master-PGSQL_01 : 100
>>
>> Migration Summary:
>> * Node com-zabbix02p-pnd-ppp:
>> * Node com-zabbix01p-pnd-ppp:
>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>
>> 現クラスタ定義を整理すると、
>>
>> 　①Zabbixserverリソースのオペレーション定義では、
>> 　　moniter　interval=0s　timeout=60s　on-fail=restart
>> 　　(startでもon-fail=restartであり、stopはon-fail=blockである)
>>
>> 　②リソースグループ定義では、
>> 　　・Postgresqlグループでは、Postgresqlリソースのみ含む
>> 　　　(Master/Slaveグループとして作成し、master-max=1、master-node-max=1
>> 　　　、clone-max=2、clone-node-max=1、notify=trueとしている)
>> 　　・VIPグループでは、VIPリソースとZabbixServerリソースの２つのリソースを含む
>> 　　　(priority設定をしていないため、VIPグループ内の起動順序は、
>> 　　　 VIPリソース⇒ZabbixServerリソースという起動になることを想定)
>>
>> 　③同居定義では、
>> 　　Master状態のPostgresqlグループとVIPグループが、INFINITY。
>>
>> 　④起動順序定義では、
>> 　　・Postgresqlグループをpromote⇒VIPグループをstartする。(INFINITY)
>> 　　・Postgresqlグループをdemote⇒VIPグループをstopする。(0(強制せず))
>>
>> となっています。
>> Postgresql障害(プロセスダウン)では、Postgresqlリソースが他のリソース起動前提
>> となっているため、Postgresqlリソースがクラスタ移動すると他のリソースが連動する
>> こととなり、正常に切り替わると考えてます。
>>
>> 今回のZabbixserver障害(プロセスダウン)を検知し、全リソースを移動(Postgresqlの
>> 切替(移動＆promote)⇒VIPリソース移動⇒Zabbix起動)させる必要があるのですが、
>> 下記定義内容にて不足している定義はありますか？
>>
>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>> ■クラスタ定義
>> pcs property set no-quorum-policy="ignore"
>> pcs property set stonith-enabled="false"
>> pcs resource defaults resource-stickness="INFINITY"
>> pcs resource defaults migration-threshold="1"
>>
>> ■VIPリソース定義
>> pcs resource create VIP_01 IPaddr2 \
>>> ip="192.168.13.125" \
>>> nic="enp0s3" \
>>> cidr_netmask="24" \
>>> op start timeout="60s" interval="0s" on-fail="resstart" \
>>> op monitor timeout="60s" interval="10s" on-fail="restart" \
>>> op stop timeout="60s" interval="0s" on-fail="block" \
>> ■PostgreSQLリソース定義
>> pcs -f /tmp/cluster_cfg resource create PGSQL_01 pgsql \
>>> pgctl="/usr/bin/pg_ctl" \
>>> psql="/usr/bin/psql" \
>>> pgdata="/var/lib/pgsql/data/" \
>>> rep_mode="async" \
>>> node_list="zabbix01 zabbix02" \
>>> restore_command="cp /var/lib/pgsql/pg_arch/arc1/%f %p" \
>>> primary_conninfo_opt="keepalives_idle=60 keepalives_interval=5 keepalives_count=5" \
>>> master_ip="192.168.13.125" \
>>> restart_on_promote='true' \
>>> repuser="rep_user" \
>>> start_opt="-i -p 5432" \
>>> op start timeout="60s" interval="0s" on-fail="restart" \
>>> op monitor timeout="60s" interval="4s" on-fail="restart" \
>>> op monitor timeout="60s" interval="3s" on-fail="restart" role="Master" \
>>> op promote timeout="60s" interval="0s" on-fail="restart" \
>>> op demote timeout="60s" interval="0s" on-fail="stop" \
>>> op stop timeout="60s" interval="0s" on-fail="block" \
>>> op notify timeout="60s" interval="0s"
>> ■同居・起動順序定義
>> pcs resource master msGrpPostgresql PGSQL_01 \
>>> master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true
>> pcs resource group add GrpVIP VIP_01
>> pcs constraint colocation add GrpVIP with Master msGrpPostgresql
>> pcs constraint order promote msGrpPostgresql then start GrpVIP symmetrical=false score=INFINITY
>> pcs constraint order demote msGrpPostgresql then stop GrpVIP symmetrical=false score=0
>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>
>> 何卒、ご助勢願います。
>>
>>
>> On 2016/01/15 13:45, kazuh@goo.jp wrote:
>>> ひがしです。お世話になります。
>>>
>>>> ⇒ご指摘の事項およびpg_basebackup、promote、recovery.done⇒recovery.confの
>>>> リネーム等
>>>> 　PostgreSQLの(Masterでの)起動条件を整理し復旧しました。
>>> うまくいったのなら良かったです。
>>> 参考まで、recovery.confはPacemaker(pgsql RA)が自動的に作成するので、
>>> 手動で作成(リネーム)する必要は無いですよ。
>>>
>>>
>>>> この内容で、PostgreSQL障害時はSlave(新マスタ)機へ問題なく切り替わりまし
>>>> たが、
>>>> ZabbixServer障害時はクラスタリソース全てがMaster、Slave共に停止してしま
>>>> いました。
>>> 思いつく（よくあるケース）で以下２つが考えられます。
>>>
>>> (1)リソース停止失敗していないか？
>>> ZabbixServer障害は、具体的にはどんな障害でしょうか？
>>> 今回の設定では、前回回答でも少し触れましたが、STONITH(排他制御)が設定
>>> されていないようなので、リソースの停止が失敗するケースの故障時は、
>>> フェイルオーバはできません。
>>>
>>> 具体的には、各リソース設定の以下op stop～～行の「on-fail="block"」
>>> というのが、「リソースの停止に失敗したら、フェイルオーバを中止(block)する」
>>> ということを示しています。
>>> 　op stop timeout="60s" interval="0s" on-fail="block"
>>>
>>> STONITHを導入し、かつon-fail="fence"と設定すると、リソースの停止失敗時は
>>> STONITHが発動し、相手ノードの電源を強制的に断した後、フェイルオーバが
>>> 継続します。
>>>
>>> このあたり、詳細は、前回も紹介の以下資料をご覧ください。
>>> 　　http://linux-ha.osdn.jp/wp/archives/4338
>>> 　　　→試して覚えるPacemaker入門 排他制御機能編
>>>
>>>
>>> (2)フェイルカウントや制約等が残っていないか？
>>> フェイルオーバ先に、過去、故障や、手動リソース移動でついた制約が
>>> 残ってしまってないでしょうか？
>>>
>>> フェイルカウントは、「crm_mon -rfA」の表示の"Failed actions:"という
>>> 最下部の欄に何か表示があれば、残った状態です。
>>> 残っていると、Pacemakerはこのノードは故障していると判断し、
>>> リソースは起動しません。
>>>
>>> 前回紹介の以下資料P34の表示例を参考に、残っていればP36のコマンドで
>>> フェイルカウントを削除してください。
>>>> http://linux-ha.osdn.jp/wp/archives/4137
>>>> 　→PG-REXで学ぶPacemaker運用の実例
>>> また、crm_resource -M -r コマンドでリソースを手動で移動した後、
>>> 「crm_resource -U -r ＜リソース名＞」を実行していない場合、
>>> 移動元のノードにはリソースが起動できない制約が残ります。
>>> (crm_mon -rfAL で確認できます。)
>>> その場合、「crm_resource -U -r ＜リソース名＞」で制約を消してください。
>>>
>>>
>>>
>>> さて、上記はあくまでも推測で、今回の事象がそれに該当するかどうかは、
>>> ログ等を確認しないとわかりません。
>>> ZabbixServer障害発生時の、「crm_mon -Arf -1」やPacemakerのログ(両系分)が
>>> あれば、もう少し今回の事象の原因を解析できると思います。
>>>
>>>
>>> 以上です。よろしくお願いいたします。
>>>
>>> ----- 元のメッセージ -----
>>> From: "Pacemaker初心者" <m.hiraguchi@freebit.net>
>>> 宛先: linux-ha-japan@lists.osdn.me
>>> 送信済み: 2016年1月14日, 木曜日 午後 8:53:15
>>> 件名: Re: [Linux-ha-jp] クラスタの復旧およびPacemakerの挙動について
>>>
>>> ひがし様
>>>
>>> ご回答ありがとうございます。
>>>
>>> ＜確認１のご回答＞
>>>> PG-REXでは、Pacemaker起動をMasterになってほしいノードから片方ずつ行い、
>>>> そのPacemakerが完全に起動し、PostgreSQLがMasterになったことを確認してから、
>>>> もう片方を起動する、というように起動する必要があります。
>>>> Pacemakerからすると、2ノード同時に起動された場合、どちらのノードを優先して
>>>> Masterにすべきか判断できないためです。
>>>> 今回の場合、Slave(新Master)のみを先に起動すれば、きちんとMasterになったかと
>>>> 思います。
>>> ⇒本ケースの再現がありましたので、Slave(新Master)機⇒Master(新Slave)機の順で、
>>> 　クラスタ起動を行いました。
>>>
>>> ＜確認２のご回答＞
>>>> ログを確認しないと断定はできませんが、両系でPGSQL.lockファイルが残存している
>>>> 可能性があります。
>>>> これは、データが古い可能性があることをユーザに気づかせるための印で、
>>>> Pacemaker(pgsql RA)が正常停止するときのみ削除されます。つまり、異常停止時
>>>> には残存し、異常停止した旨をユーザに気づかせるものです。
>>>> 通常、postgreユーザのホーム配下のtmp/(/var/lib/pgsql/tmp/)にあります。
>>>> データ復旧後、またはデータが古い可能性があること承知の上で、当該ノードの
>>>> PostgreSQLを起動する際は、このファイルを手動で削除する必要があります
>>> ⇒ご指摘の事項およびpg_basebackup、promote、recovery.done⇒recovery.confの
>>> リネーム等
>>> 　PostgreSQLの(Masterでの)起動条件を整理し復旧しました。
>>>
>>> ＜確認３のご回答＞
>>>> 構築後、一度きちんと起動しているようなので、設定に問題は無いかと
>>>> 思います。
>>>> ＃STONITH, SFEX, VIPcheck等の排他制御は設定されていないようなので、
>>>> 　スプリットブレイン発生時は両系ノードがMasterになってしまうのが
>>>> 　問題と言えば問題ですが、今回の事象とは関係ないと思います。
>>> ⇒クラスタ起動に連動し、PostgreSQLが起動するようになりました。
>>> 　※関係ないかもしれませんが、前回との変更点は、PostgreSQLリソースに
>>> 　「start_option="-i -p 5432"」の追加です。
>>>
>>>
>>> ■新たな確認事項
>>> 　VIP、PostgreSQLのクラスタリソースおよびグループ以外のリソース(Zabbix)
>>> を追加しました。
>>>
>>> 　■zabbixリソースの作成内容
>>> # pcs resource create ZabbixSV zabbixserver \
>>> > binary="/usr/sbin/zabbix_server" \
>>> > pid="/var/run/zabbix/zabbix_server.pid" \
>>> > config="/etc/zabbix/zabbix_server.conf" \
>>> > op start timeout="60s" interval="0s" on-fail="restart" \
>>> > op monitor timeout="60s" interval="0s" on-fail="restart" \
>>> > op stop timeout="60s" interval="0s" on-fail="block"
>>>
>>> 　■zabbixリソースのグループ登録(VIPリソースグループへの追加)
>>> # pcs resource group add GrpVIP ZabbixSV
>>> # pcs resource group list
>>> GrpVIP: VIP_01 ZabbixSV
>>>
>>>
>>> ※フェイルオーバー時の起動順序は、
>>> 　　①PostgreSQLのPromote
>>> 　　②VIP付与
>>> 　　③ZabbixServer起動
>>> 　を想定しています。
>>>
>>> この内容で、PostgreSQL障害時はSlave(新マスタ)機へ問題なく切り替わりまし
>>> たが、
>>> ZabbixServer障害時はクラスタリソース全てがMaster、Slave共に停止してしま
>>> いました。
>>>
>>> PostgreSQLに依存するクラスタリソースの登録について
>>> ご教示願います。
>>>
>>> ご助勢の程、宜しくお願い致します。
>>>
>>>
>>>
>>> On 2016/01/14 13:48, kazuh@goo.jp wrote:
>>>> ひがしと申します。
>>>> お世話になります。
>>>>
>>>>
>>>>> ＜確認１＞
>>>>> 　Slave(新Master)にてフェイルオーバー後の状態を継続するものと想定して
>>>>> 　いましたが、OS停止をした場合はこの様な挙動になるのは正しいのでしょうか？
>>>> PG-REXでは、Pacemaker起動をMasterになってほしいノードから片方ずつ行い、
>>>> そのPacemakerが完全に起動し、PostgreSQLがMasterになったことを確認してから、
>>>> もう片方を起動する、というように起動する必要があります。
>>>> Pacemakerからすると、2ノード同時に起動された場合、どちらのノードを優先して
>>>> Masterにすべきか判断できないためです。
>>>>
>>>> 今回の場合、Slave(新Master)のみを先に起動すれば、きちんとMasterになったかと
>>>> 思います。
>>>>
>>>>
>>>>> ＜確認２＞
>>>>> 　クラスタの復旧作業として①と②以外に行うことはありますか？
>>>>> 　(※VIP_01はdebug-atartにて強制起動し、PostgreSQLは手動起動しましたが、
>>>>> 　未だ〝stopped〟のままです。)
>>>> ログを確認しないと断定はできませんが、両系でPGSQL.lockファイルが残存している
>>>> 可能性があります。
>>>>
>>>> これは、データが古い可能性があることをユーザに気づかせるための印で、
>>>> Pacemaker(pgsql RA)が正常停止するときのみ削除されます。つまり、異常停止時
>>>> には残存し、異常停止した旨をユーザに気づかせるものです。
>>>> 通常、postgreユーザのホーム配下のtmp/(/var/lib/pgsql/tmp/)にあります。
>>>>
>>>> データ復旧後、またはデータが古い可能性があること承知の上で、当該ノードの
>>>> PostgreSQLを起動する際は、このファイルを手動で削除する必要があります。
>>>>
>>>>
>>>>
>>>> なお、手前味噌になりますが、昨年福岡で開催のオープンソースカンファレンスにて
>>>> PG-REXの故障時の挙動や運用方法をまとめた講演を行いました。
>>>> PostgreSQLプロセス停止後の復旧は、以下P42に掲載しています。
>>>>
>>>> http://linux-ha.osdn.jp/wp/archives/4137
>>>> 　→PG-REXで学ぶPacemaker運用の実例
>>>> 　　　P42 vip-master故障時の復旧方法
>>>>
>>>>
>>>>> ＜確認３＞
>>>>> 　そもそもの話なのですが、クラスタ起動時にVIP付与とPostgreSQL起動が
>>>>> 　されない状態です。(PostgreSQLは手動起動してます)
>>>>> 　設定内容を以下に示すので、不足している設定をご教示願います。
>>>> 構築後、一度きちんと起動しているようなので、設定に問題は無いかと
>>>> 思います。
>>>> ＃STONITH, SFEX, VIPcheck等の排他制御は設定されていないようなので、
>>>> 　スプリットブレイン発生時は両系ノードがMasterになってしまうのが
>>>> 　問題と言えば問題ですが、今回の事象とは関係ないと思います。
>>>> 　排他制御については、以下講演が詳しいです。
>>>> 　　http://linux-ha.osdn.jp/wp/archives/4338
>>>> 　　　→試して覚えるPacemaker入門 排他制御機能編
>>>>
>>>>
>>>> 一度、以下の順に、起動・停止をやりなおしてみてはいかがでしょうか？
>>>> (上記PGSQL.lockや片系ずつ起動、を踏まえた手順案です。)
>>>>
>>>> 　1) 一旦、両系のPacemakerをSlave→Masterの順に片系ずつ停止
>>>> 　2) 一旦、手動起動した両系のPostgreSQLをSlave→Masterの順に片系ずつ停止
>>>> 　3) 両系の/var/lib/pgsql/tmp/PGSQL.lock　を削除
>>>> 　4) さきほどMasterだった方のノードのPacemakerを起動
>>>> 　　 →crm_mon等でPostgreSQLがMasterになることを確認
>>>> 　5) pg_basebackupを実行し、現Masterの最新データをSlaveにコピー
>>>> 　6) SlaveのPacemakerを起動
>>>>
>>>>
>>>> これでも起動しない場合、両系分のPacemakerとPostgreSQLのログを見てみる
>>>> 必要があります。
>>>>
>>>>
>>>> 以上です。
>>>> よろしくお願いいたします。
>>>>
>>>>
>>>> ----- 元のメッセージ -----
>>>> From: "Pacemaker初心者" <m.hiraguchi@freebit.net>
>>>> 宛先: linux-ha-japan@lists.osdn.me
>>>> 送信済み: 2016年1月8日, 金曜日 午後 6:38:26
>>>> 件名: [Linux-ha-jp] クラスタの復旧およびPacemakerの挙動について
>>>>
>>>> お世話になります。
>>>>
>>>> 先般、PG-REXでのPacemaker構築にて上手くいかなかったので、勉強がてら
>>>> pcsコマンドにて再構築を行いました。
>>>>
>>>> [環境]
>>>> OS ：CentOS7.1
>>>> PostgresSQL ：postgresql-server-9.2.13-1
>>>> Pacemaker ：pacemaker-1.1.12-22
>>>>
>>>>
>>>> 構築後に諸々問題点が発生しており、ご助勢頂けると助かります。
>>>> 以下、状況を順に記します。
>>>>
>>>>
>>>> (１)構築後の状況
>>>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>>> # crm_mon -Arf -1
>>>> Last updated: Tue Jan 5 21:39:19 2016
>>>> Last change: Tue Jan 5 21:38:46 2016 by hacluster via crmd on zabbix01
>>>> Stack: corosync
>>>> Current DC: zabbix01(1) - partition with quorum
>>>> Version: 1.1.12-561c4cf
>>>> 2 Nodes configured
>>>> 3 Resources configured
>>>>
>>>> Online: [ zabbix01 zabbix02 ]
>>>>
>>>> Full list of resources:
>>>>
>>>> Master/Slave Set: msPostgresql [pgsql]
>>>> Masters: [ zabbix01 ]
>>>> Slaves: [ zabbix02 ]
>>>> Resource Group: master-group
>>>> VIP_01 (ocf::heartbeat:IPaddr2): Started zabbix01
>>>>
>>>> Node Attributes:
>>>> * Node zabbix01:
>>>> + #cluster-name : zabbixcluster
>>>> + #site-name : zabbixcluster
>>>> + master-pgsql : 1000
>>>> + pgsql-data-status : LATEST
>>>> + pgsql-master-baseline : 0000000016000080
>>>> + pgsql-status : PRI
>>>> * Node zabbix02:
>>>> + #cluster-name : zabbixcluster
>>>> + #site-name : zabbixcluster
>>>> + master-pgsql : 100
>>>> + pgsql-data-status : STREAMING|ASYNC
>>>> + pgsql-status : HS:async
>>>>
>>>> Migration summary:
>>>> * Node zabbix02:
>>>> * Node zabbix01:
>>>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>>>
>>>>
>>>> (２)Slaveへの切替
>>>> 切替テストとして、Zabbix01のPostgresqlを停止しました。
>>>> 停止後のクラスタの状態(下記)としては問題ないと思ってます。
>>>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>>> # crm_mon -Arf -1
>>>> Last updated: Wed Jan 6 00:45:32 2016
>>>> Last change: Wed Jan 6 00:30:22 2016 by hacluster via crmd on zabbix01
>>>> Stack: corosync
>>>> Current DC: zabbix01 (1) - partition with quorum
>>>> Version: 1.1.12-561c4cf
>>>> 2 Nodes configured
>>>> 3 Resources configured
>>>>
>>>> Online: [ zabbix01 zabbix02 ]
>>>>
>>>> Full list of resources:
>>>>
>>>> Master/Slave Set: msPostgresql [pgsql]
>>>> Masters: [ zabbix02 ]
>>>> Stopped: [ zabbix01 ]
>>>> Resource Group: master-group
>>>> VIP_01 (ocf::heartbeat:IPaddr2): Started zabbix02p
>>>>
>>>> Node Attributes:
>>>> * Node zabbix01:
>>>> + #cluster-name : zabbixcluster
>>>> + #site-name : zabbixcluster
>>>> + master-pgsql : -INFINITY
>>>> + pgsql-data-status : DISCONNECT
>>>> + pgsql-status : STOP
>>>> * Node zabbix02:
>>>> + #cluster-name : zabbixcluster
>>>> + #site-name : zabbixcluster
>>>> + master-pgsql : 1000
>>>> + pgsql-data-status : LATEST
>>>> + pgsql-master-baseline : 0000000017000080
>>>> + pgsql-status : PRI
>>>>
>>>> Migration summary:
>>>> * Node zabbix02:
>>>> * Node zabbix01:
>>>> pgsql: migration-threshold=1 fail-count=1 last-failure='Wed Jan 6
>>>> 00:30:13 2016'
>>>>
>>>> Failed actions:
>>>> pgsql_monitor_3000 on zabbix01 'unknown error' (1): call=126,
>>>> status=complete, last-rc-change='Wed Jan 6 00:30:13 2016', queued=0ms,
>>>> exec=0ms
>>>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>>>
>>>>
>>>> (３)
>>>> この後、切戻しを行う際に当方の不手際で、Master(Zabbix01)とSlave(Zabbix02)
>>>> のOS停止をしてしまいました。
>>>> 停止後、両機を起動しましたが、「pcs status」および「crm_mon -Arf -1」
>>>> でのmaster-group(VIP_01)、msPostgresql(pgsql)のリソースのステータスが、
>>>> 〝stopped〟となっていました。
>>>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>>> # pcs status
>>>> Cluster name: zabbixcluster
>>>> Last updated: Thr Jan 7 17:11:58 2016
>>>> Last change: Thr Jan 7 15:57:37 2016 by hacluster via crmd on zabbix01
>>>> Stack: corosync
>>>> Current DC: zabbix02 (1) - partition with quorum
>>>> Version: 1.1.12-561c4cf
>>>> 2 Nodes configured
>>>> 3 Resources configured
>>>>
>>>>
>>>> Online: [ zabbix01 zabbix02 ]
>>>>
>>>> Full list of resources:
>>>>
>>>> Master/Slave Set: msPostgresql [pgsql]
>>>> Stopped: [ zabbix01 zabbix02 ]
>>>> Resource Group: master-group
>>>> VIP_01 (ocf::heartbeat:IPaddr2): Stopped
>>>>
>>>> PCSD Status:
>>>> zabbix01 (192.168.252.182): Online
>>>> zabbix02 (192.168.252.183): Online
>>>>
>>>> Daemon Status:
>>>> corosync: active/enabled
>>>> pacemaker: active/enabled
>>>> pcsd: active/enabled
>>>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>>>
>>>> ＜確認１＞
>>>> 　Slave(新Master)にてフェイルオーバー後の状態を継続するものと想定して
>>>> 　いましたが、OS停止をした場合はこの様な挙動になるのは正しいのでしょうか？
>>>>
>>>>
>>>> (４)復旧
>>>> pg_basebackup、pg_ctl promote等を行い、PostgreSQLの戻しを行いました。
>>>> (※「psql -h localhost -c "SELECT pg_is_in_recovery();"」にて
>>>> 両PostgresSQLの起動状態(Zabbix01：f、Zabbix02：t)と、ストリーミング
>>>> レプリケーションの動作を確認済)
>>>>
>>>> PostgreSQLの状態復旧を行った後に、
>>>> 　①pcs resource cleanup msPostgresqlとpcs resource cleanup master-group
>>>> 　②pcs cluster stop --allとpcs cluster start --all
>>>> にて復旧を試みましたが、両リソースの状態は〝stopped〟のままです。
>>>>
>>>> ＜確認２＞
>>>> 　クラスタの復旧作業として①と②以外に行うことはありますか？
>>>> 　(※VIP_01はdebug-atartにて強制起動し、PostgreSQLは手動起動しましたが、
>>>> 　未だ〝stopped〟のままです。)
>>>>
>>>>
>>>> ＜確認３＞
>>>> 　そもそもの話なのですが、クラスタ起動時にVIP付与とPostgreSQL起動が
>>>> 　されない状態です。(PostgreSQLは手動起動してます)
>>>> 　設定内容を以下に示すので、不足している設定をご教示願います。
>>>>
>>>> ■設定内容
>>>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>>> pcs -f cluster_cfg property set no-quorum-policy="ignore"
>>>> pcs -f cluster_cfg property set stonith-enabled="false"
>>>> pcs -f cluster_cfg resource defaults resource-stickiness="INFINITY"
>>>> pcs -f cluster_cfg resource defaults migration-threshold="1"
>>>>
>>>> pcs -f cluster_cfg resource create VIP_01 IPaddr2 \
>>>> ip="192.168.252.184" \
>>>> nic="enp0s3" \
>>>> cidr_netmask="24" \
>>>> op start timeout="60s" interval="0s" on-fail="restart" \
>>>> op monitor timeout="60s" interval="10s" on-fail="restart" \
>>>> op stop timeout="60s" interval="0s" on-fail="block"
>>>>
>>>> pcs -f cluster_cfg resource create pgsql pgsql \
>>>> pgctl="/usr/bin/pg_ctl" \
>>>> psql="/usr/bin/psql" \
>>>> pgdata="/var/lib/pgsql/data/" \
>>>> rep_mode="async" \
>>>> node_list="zabbix01 zabbix02" \
>>>> restore_command="cp /var/lib/pgsql/pg_archive/%f %p" \
>>>> primary_conninfo_opt="keepalives_idle=60 keepalives_interval=5
>>>> keepalives_count=5" \
>>>> master_ip="192.168.252.184" \
>>>> restart_on_promote='true' \
>>>> op start timeout="60s" interval="0s" on-fail="restart" \
>>>> op monitor timeout="60s" interval="4s" on-fail="restart" \
>>>> op monitor timeout="60s" interval="3s" on-fail="restart"
>>>> role="Master" \
>>>> op promote timeout="60s" interval="0s" on-fail="restart" \
>>>> op demote timeout="60s" interval="0s" on-fail="stop" \
>>>> op stop timeout="60s" interval="0s" on-fail="block" \
>>>> op notify timeout="60s" interval="0s"
>>>>
>>>> pcs -f cluster_cfg resource master msPostgresql pgsql \
>>>> master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true
>>>>
>>>> pcs -f cluster_cfg resource group add master-group VIP_01
>>>>
>>>> pcs -f pgsql_cfg constraint colocation add master-group with Master
>>>> msPostgresql INFINITY
>>>> pcs -f pgsql_cfg constraint order promote msPostgresql then start
>>>> master-group symmetrical=false score=INFINITY
>>>> pcs -f pgsql_cfg constraint order demote msPostgresql then stop
>>>> master-group symmetrical=false score=0
>>>> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
>>>>
>>>> (上記を「pcs cluster cib-push cluster_cfg」にて反映しています)
>>>>
>>>> _______________________________________________
>>>> Linux-ha-japan mailing list
>>>> Linux-ha-japan@lists.osdn.me
>>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>>> _______________________________________________
>>>> Linux-ha-japan mailing list
>>>> Linux-ha-japan@lists.osdn.me
>>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>> _______________________________________________
>>> Linux-ha-japan mailing list
>>> Linux-ha-japan@lists.osdn.me
>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>>> _______________________________________________
>>> Linux-ha-japan mailing list
>>> Linux-ha-japan@lists.osdn.me
>>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>> _______________________________________________
>> Linux-ha-japan mailing list
>> Linux-ha-japan@lists.osdn.me
>> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
>
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan
> _______________________________________________
> Linux-ha-japan mailing list
> Linux-ha-japan@lists.osdn.me
> http://lists.osdn.me/mailman/listinfo/linux-ha-japan

_______________________________________________
Linux-ha-japan mailing list
Linux-ha-japan@lists.osdn.me
http://lists.osdn.me/mailman/listinfo/linux-ha-japan