kazuh****@goo*****
kazuh****@goo*****
2016年 1月 16日 (土) 20:43:47 JST
ひがしです。お世話になります。 それでは、故障時に何が起きていたのかを見たいので、以下情報を いただけますか？ ・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.hir****@freeb*****> 宛先: linux****@lists***** 送信済み: 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***** 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.hir****@freeb*****> > 宛先: linux****@lists***** > 送信済み: 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***** 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.hir****@freeb*****> >> 宛先: linux****@lists***** >> 送信済み: 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****@lists***** >> http://lists.osdn.me/mailman/listinfo/linux-ha-japan >> _______________________________________________ >> Linux-ha-japan mailing list >> Linux****@lists***** >> http://lists.osdn.me/mailman/listinfo/linux-ha-japan > _______________________________________________ > Linux-ha-japan mailing list > Linux****@lists***** > http://lists.osdn.me/mailman/listinfo/linux-ha-japan > _______________________________________________ > Linux-ha-japan mailing list > Linux****@lists***** > http://lists.osdn.me/mailman/listinfo/linux-ha-japan _______________________________________________ Linux-ha-japan mailing list Linux****@lists***** http://lists.osdn.me/mailman/listinfo/linux-ha-japan
Fork