Fork山内さん
お世話になっております。辻です。
> 以下の手順を取った場合、どうなりますでしょうか？
> 3.でpacemaker,corosync停止後に、/var/lib/pacemaker/配下のファイルを一旦削除する。
すぐに環境を扱えない状況のため、後日試して結果をお伝えします。
なお、上記手順を実施するのはどのような狙いでしょうか？
フェールオーバー発生後に、何か不要な情報をクリアする目的でしょうか？
また、この手順を実施したときの影響をご教示ください。
> また、頂いた手順にはありませんが、/var/lib/pgsql/tmp/PGSQL.lockの削除はどうされていますしょうか？
> ※通常、pgsqlはファイルが残っていると起動しませんが、手順にはないようでしたので。。。念の為、確認させて頂きました。
すみません、手順への記載を割愛していました。
このファイルは、corosync、pacemakerの起動前に削除しています。
> ちなみに、この事象ですが、再現性はありますでしょうか？(100%??)
100%再現しております。
> その場合、通常のpgsqlのリソースエージェントを利用した場合でも、問題が再現しますでしょうか？
「通常のpgsql＝デバッグを仕込んでいないpgsql」という理解でよろしければ、
通常のpgsqlでも再現しております。
> ネットワークの遅延などが、お使いの環境で起きているかもと思っています。
承知しました。
ネットワーク遅延も視野に入れて引き続き検証してみます。
> 問題の無い範囲で、cib.xml(pacemakerに流し込んでいる)を拝見できれば、もう少し分かるかも知れません。
ありがとうございます。
利用しているxmlを以下に提示させていただきます。
（"r_service_fh"というリソースのRAは、著作権の問題からご提示できませんが、
DNSに関する操作を行うRAです。）
-------------------------------------------------------------------------
<cib crm_feature_set="3.11.0" validate-with="pacemaker-3.7" epoch="14" num_updates="0" admin_epoch="0">
<configuration>
<crm_config>
<cluster_property_set id="cib-bootstrap-options">
<nvpair id="cib-bootstrap-options-no-quorum-policy" name="no-quorum-policy" value="ignore"/>
<nvpair id="cib-bootstrap-options-stonith-enabled" name="stonith-enabled" value="false"/>
</cluster_property_set>
</crm_config>
<nodes/>
<resources>
<primitive class="ocf" id="r_service_fh" provider="local" type="FloatingDNS">
<instance_attributes id="r_service_fh-instance_attributes">
<nvpair id="r_service_fh-instance_attributes-hostname" name="hostname" value="node00"/>
<nvpair id="r_service_fh-instance_attributes-zonename" name="zonename" value="mynetwork.local"/>
</instance_attributes>
<meta_attributes id="r_service_fh-meta_attributes">
<nvpair id="r_service_fh-meta_attributes-migration-threshold" name="migration-threshold" value="1"/>
<nvpair id="r_service_fh-meta_attributes-target-role" name="target-role" value="Started"/>
</meta_attributes>
<operations>
<op id="r_service_fh-monitor-interval-10s" interval="10s" name="monitor" on-fail="restart" timeout="60s"/>
<op id="r_service_fh-start-interval-0s" interval="0s" name="start" on-fail="stop" timeout="50s"/>
<op id="r_service_fh-stop-interval-0s" interval="0s" name="stop" on-fail="block" timeout="60s"/>
</operations>
</primitive>
<clone id="ms_pgsql">
<primitive class="ocf" id="r_pgsql" provider="linuxhajp" type="pgsql">
<instance_attributes id="r_pgsql-instance_attributes">
<nvpair id="r_pgsql-instance_attributes-master_ip" name="master_ip" value="node00"/>
<nvpair id="r_pgsql-instance_attributes-node_list" name="node_list" value="node01 node02"/>
<nvpair id="r_pgsql-instance_attributes-pgctl" name="pgctl" value="/usr/pgsql-14/bin/pg_ctl"/>
<nvpair id="r_pgsql-instance_attributes-pgdata" name="pgdata" value="/var/lib/pgsql/14/data"/>
<nvpair id="r_pgsql-instance_attributes-primary_conninfo_opt" name="primary_conninfo_opt" value="keepalives_idle=60 keepalives_interval=5 keepalives_count=5"/>
<nvpair id="r_pgsql-instance_attributes-psql" name="psql" value="/usr/pgsql-14/bin/psql"/>
<nvpair id="r_pgsql-instance_attributes-rep_mode" name="rep_mode" value="sync"/>
<nvpair id="r_pgsql-instance_attributes-restore_command" name="restore_command" value="false"/>
<nvpair id="r_pgsql-instance_attributes-stop_escalate" name="stop_escalate" value="0"/>
</instance_attributes>
<operations>
<op id="r_pgsql-demote-interval-0s" interval="0s" name="demote" on-fail="block" start-delay="0s" timeout="1200s"/>
<op id="r_pgsql-methods-interval-0s" interval="0s" name="methods" timeout="5s"/>
<op id="r_pgsql-monitor-interval-30s" interval="30s" name="monitor" on-fail="restart" start-delay="10s" timeout="480s"/>
<op id="r_pgsql-monitor-interval-7s" interval="7s" name="monitor" on-fail="restart" role="Master" start-delay="9s" timeout="480s"/>
<op id="r_pgsql-notify-interval-0s" interval="0s" name="notify" start-delay="0s" timeout="90s"/>
<op id="r_pgsql-promote-interval-0s" interval="0s" name="promote" on-fail="restart" start-delay="0s" timeout="9000s"/>
<op id="r_pgsql-start-interval-0s" interval="0s" name="start" on-fail="restart" start-delay="0s" timeout="1209600s"/>
<op id="r_pgsql-stop-interval-0s" interval="0s" name="stop" on-fail="block" start-delay="0s" timeout="1200s"/>
</operations>
</primitive>
<meta_attributes id="ms_pgsql-meta_attributes">
<nvpair id="ms_pgsql-meta_attributes-promotable" name="promotable" value="true"/>
<nvpair id="ms_pgsql-meta_attributes-promoted-max" name="promoted-max" value="1"/>
<nvpair id="ms_pgsql-meta_attributes-promoted-node-max" name="promoted-node-max" value="1"/>
<nvpair id="ms_pgsql-meta_attributes-clone-max" name="clone-max" value="2"/>
<nvpair id="ms_pgsql-meta_attributes-clone-node-max" name="clone-node-max" value="1"/>
<nvpair id="ms_pgsql-meta_attributes-notify" name="notify" value="true"/>
<nvpair id="ms_pgsql-meta_attributes-target-role" name="target-role" value="Master"/>
</meta_attributes>
</clone>
</resources>
<constraints>
<rsc_location id="location-ms_pgsql" rsc="ms_pgsql">
<rule id="location-ms_pgsql-rule" role="Master" score="200">
<expression attribute="#uname" id="location-ms_pgsql-rule-expr" operation="eq" value="node01"/>
</rule>
</rsc_location>
<rsc_location id="location-ms_pgsql-1" rsc="ms_pgsql">
<rule id="location-ms_pgsql-1-rule" role="Master" score="100">
<expression attribute="#uname" id="location-ms_pgsql-1-rule-expr" operation="eq" value="node02"/>
</rule>
</rsc_location>
<rsc_colocation id="colocation-r_service_fh-ms_pgsql-INFINITY" rsc="r_service_fh" rsc-role="Started" score="INFINITY" with-rsc="ms_pgsql" with-rsc-role="Master"/>
<rsc_order first="ms_pgsql" first-action="promote" id="order-ms_pgsql-r_service_fh-Optional" kind="Optional" symmetrical="false" then="r_service_fh" then-action="start"/>
<rsc_order first="ms_pgsql" first-action="demote" id="order-ms_pgsql-r_service_fh-Optional-1" kind="Optional" symmetrical="false" then="r_service_fh" then-action="stop"/>
</constraints>
<rsc_defaults>
<meta_attributes id="rsc_defaults-meta_attributes">
<nvpair id="rsc_defaults-meta_attributes-resource-stickiness" name="resource-stickiness" value="INFINITY"/>
<nvpair id="rsc_defaults-meta_attributes-migration-threshold" name="migration-threshold" value="1"/>
</meta_attributes>
</rsc_defaults>
</configuration>
<status/>
</cib>
-------------------------------------------------------------------------
以上、よろしくお願いいたします。
> -----Original Message-----
> From: renay****@ybb***** <>
> Sent: Thursday, June 9, 2022 3:25 PM
> To: 辻 真吾 <tsuji****@ryobi*****>; LINUX-HA
> <linux****@lists*****>
> Cc: d-ike****@ryobi*****
> Subject: Re: RE: RE: RE: [Linux-ha-jp] Pacemakerのフェールオーバー後のノ
> ード組込みについて
>
> 辻さん
>
> こんにちは、山内です。
>
> > > 何かお使いになっているリソースや、手順などで、node2からnode1の
> r_pgsqlのエラーカウントをクリアするような事が起きていませんでしょう
> か？
> > > もしくは、使ったことはありませんが、failure-timeoutを設定しているな
> どで、エラーカウントを一定時間で実行するような設定を使っていませんか？
> >
> > 申し訳ありません。
> > 最初のメールでお伝えした手順で記載できておりませんでした。
> > 実施した手順は、正確には以下になります。(手順7を追記しました)
> >
> > 実施手順
> > 1. ノード1のpostgresプロセスをkill
> > 2. ノード2がマスターに昇格
> > 3. ノード1のpacemaker、corosyncをsystemctlで停止
> > 4. ノード1でテーブル空間のディレクトリ配下とPGDATAのディレクトリ
> を削除
> > 5. ノード1でpg_basebackupを実施
> > 6. ノード1のcorosync、pacemakerをsystemctlで起動
> > → ここでノード1が"sync"状態になる想定ですが、
> > 実際には起動処理が実施された後に、
> > 停止状態に遷移してしまいます。※
> > 7. ノード2で「pcs resource cleanup r_pgsql」を実施
> > → ここでノード1が正常に組込まれる。
> >
> > 今回ご指摘いただいたのは、この手順7の部分のことだと思います。
> > 本件で問題としているのは、手順6でstart処理が内部的に２回呼ばれている
> 点になります。
> > 山内さんがおっしゃられている、下記の「node1のr_pgsqlのstartの失敗を
> 処理」した原因を
> > 突き止めたいと思っております。
> >
> > > ★node1のr_pgsqlのstartの失敗を処理して、クラスタは一旦安定状態に
> 入ります。
> >
> > 先日送付させていただいたログで言いますと、下記の部分でstart処理が２度
> 動作している様に
> > 見えておりまして、一度「STOP->HS:alone」に遷移した後に、
> 「HS:alone->STOP」に遷移している
> > 原因を調べたく思っております。
> > （最初に詳細にお伝えできておらず、申し訳ありません。）
> > このstartの失敗処理について、何か原因として考えられるものはありますで
> しょうか？
>
> 以下の手順を取った場合、どうなりますでしょうか？
>
> 3.でpacemaker,corosync停止後に、/var/lib/pacemaker/配下のファイルを一旦
> 削除する。
>
> また、頂いた手順にはありませんが、/var/lib/pgsql/tmp/PGSQL.lockの削除は
> どうされていますしょうか？
> ※通常、pgsqlはファイルが残っていると起動しませんが、手順にはないようで
> したので。。。念の為、確認させて頂きました。
>
> ちなみに、この事象ですが、再現性はありますでしょうか？(100%??)
> その場合、通常のpgsqlのリソースエージェントを利用した場合でも、問題が
> 再現しますでしょうか？
>
> 最初のログを頂いた時に直接関係しないと思いますが、若干、以下の点が気に
> なりました。
> ①node1を再起動した後、node2の認識が遅れている。
> ②その後、node2を認識している。
> ネットワークの遅延などが、お使いの環境で起きているかもと思っています。
>
> 問題の無い範囲で、cib.xml(pacemakerに流し込んでいる)を拝見できれば、も
> う少し分かるかも知れません。
>
> 以上、宜しくお願いいたします。
>
>
>
>
>
> > ----- Original Message -----
> >
> > From: "辻 真吾" <tsuji****@ryobi*****>
> > To: "renay****@ybb*****" <renay****@ybb*****>;
> > "LINUX-HA" <linux****@lists*****>
> > Cc: "d-ike****@ryobi*****" <d-ike****@ryobi*****>
> > Date: 2022/06/09 木 11:45
> > Subject: RE: RE: RE: [Linux-ha-jp] Pacemakerのフェールオーバー後のノ
> ード組込みについて
> >
> >
> > 山内さん
> >
> > お世話になっております。辻です。
> >
> > ログの解析、ありがとうございます。
> >
> > > まず、node1でpostgreSQLをkillしてからの停止動作には問題はないよう
> です。
> >
> > 承知しました。
> >
> >
> > > 何かお使いになっているリソースや、手順などで、node2からnode1の
> r_pgsqlのエラーカウントをクリアするような事が起きていませんでしょう
> か？
> > > もしくは、使ったことはありませんが、failure-timeoutを設定しているな
> どで、エラーカウントを一定時間で実行するような設定を使っていませんか？
> >
> > 申し訳ありません。
> > 最初のメールでお伝えした手順で記載できておりませんでした。
> > 実施した手順は、正確には以下になります。(手順7を追記しました)
> >
> > 実施手順
> > 1. ノード1のpostgresプロセスをkill
> > 2. ノード2がマスターに昇格
> > 3. ノード1のpacemaker、corosyncをsystemctlで停止
> > 4. ノード1でテーブル空間のディレクトリ配下とPGDATAのディレクトリ
> を削除
> > 5. ノード1でpg_basebackupを実施
> > 6. ノード1のcorosync、pacemakerをsystemctlで起動
> > → ここでノード1が"sync"状態になる想定ですが、
> > 実際には起動処理が実施された後に、
> > 停止状態に遷移してしまいます。※
> > 7. ノード2で「pcs resource cleanup r_pgsql」を実施
> > → ここでノード1が正常に組込まれる。
> >
> > 今回ご指摘いただいたのは、この手順7の部分のことだと思います。
> > 本件で問題としているのは、手順6でstart処理が内部的に２回呼ばれている
> 点になります。
> > 山内さんがおっしゃられている、下記の「node1のr_pgsqlのstartの失敗を
> 処理」した原因を
> > 突き止めたいと思っております。
> >
> > > ★node1のr_pgsqlのstartの失敗を処理して、クラスタは一旦安定状態に
> 入ります。
> >
> > 先日送付させていただいたログで言いますと、下記の部分でstart処理が２度
> 動作している様に
> > 見えておりまして、一度「STOP->HS:alone」に遷移した後に、
> 「HS:alone->STOP」に遷移している
> > 原因を調べたく思っております。
> > （最初に詳細にお伝えできておらず、申し訳ありません。）
> > このstartの失敗処理について、何か原因として考えられるものはありますで
> しょうか？
> >
> > ■RAのログ（RAにデバッグを仕込んで出力したログ）
> > [2022-05-31 07:38:40.554555882] Called from line:2518 **********
> > main() : start **********
> > [2022-05-31 07:38:59.233215625] Called from line:2617 pgsql_start()
> > RETURN:0
> > [2022-05-31 07:38:59.295383798] Called from line:2518 **********
> > main() : start **********
> > [2022-05-31 07:38:59.682203668] Called from line:2617 pgsql_start()
> > RETURN:1
> >
> > ■pacemaker.log
> > May 31 07:38:59 pgsql(r_pgsql)[247646]: INFO: PostgreSQL is started.
> > May 31 07:38:59 pgsql(r_pgsql)[247646]: INFO: Changing
> r_pgsql-status on node1 : STOP->HS:alone.
> > May 31 07:38:59 node1-001 pacemaker-attrd [247415]
> (attrd_peer_update) notice: Setting r_pgsql-status[node1]: STOP ->
> HS:alone | from node1
> > ・・・
> > May 31 07:38:59 node1-001 pacemaker-execd [247414] (log_finished)
> info: r_pgsql start (call 11, PID 247646) exited with status 0 (execution
> time 18738ms, queue time 0ms)
> > May 31 07:38:59 node1-001 pacemaker-execd [247414] (log_execute)
> info: executing - rsc:r_pgsql action:start call_id:13
> > May 31 07:38:59 node1-001 pacemaker-controld [247417]
> (action_synced_wait) info: pgsql_meta-data_0[248726] exited with status 0
> > May 31 07:38:59 node1-001 pacemaker-controld [247417]
> (process_lrm_event) notice: Result of start operation for r_pgsql on node1:
> ok | rc=0 call=11 key=r_pgsql_start_0 confirmed=true cib-update=43
> > May 31 07:38:59 node1-001 pacemaker-based [247412]
> (cib_process_request) info: Forwarding cib_modify operation for section
> status to all (origin=local/crmd/43)
> > May 31 07:38:59 node1-001 pacemaker-based [247412]
> (cib_perform_op) info: Diff: --- 0.547.41 2
> > May 31 07:38:59 node1-001 pacemaker-based [247412]
> (cib_perform_op) info: Diff: +++ 0.547.42 (null)
> > May 31 07:38:59 node1-001 pacemaker-based [247412]
> (cib_perform_op) info: + /cib: @num_updates=42
> > May 31 07:38:59 node1-001 pacemaker-based [247412]
> (cib_perform_op) info: +
> /cib/status/node_state[@id='1']/lrm[@id='1']/lrm_resources/lrm_resource[
> @id='r_pgsql']/lrm_rsc_op[@id='r_pgsql_last_0']:
> @transition-key=5:0:0:efb965be-11c0-45a4-adde-1b209d1f8cca,
> @transition-magic=0:0;5:0:0:efb965be-11c0-45a4-adde-1b209d1f8cca,
> @call-id=11, @rc-code=0, @op-status=0, @last-rc-change=1653982720,
> @exec-time=18738
> > May 31 07:38:59 node1-001 pacemaker-based [247412]
> (cib_process_request) info: Completed cib_modify operation for section
> status: OK (rc=0, origin=node1/crmd/43, version=0.547.42)
> > May 31 07:38:59 pgsql(r_pgsql)[248725]: INFO: Changing
> r_pgsql-status on node1 : HS:alone->STOP.
> > May 31 07:38:59 node1-001 pacemaker-attrd [247415]
> (attrd_peer_update) notice: Setting r_pgsql-status[node1]: HS:alone ->
> STOP | from node1
> > May 31 07:38:59 node1-001 pacemaker-based [247412]
> (cib_perform_op) info: Diff: --- 0.547.42 2
> > May 31 07:38:59 node1-001 pacemaker-based [247412]
> (cib_perform_op) info: Diff: +++ 0.547.43 (null)
> > May 31 07:38:59 node1-001 pacemaker-based [247412]
> (cib_perform_op) info: + /cib: @num_updates=43
> > May 31 07:38:59 node1-001 pacemaker-based [247412]
> (cib_perform_op) info: +
> /cib/status/node_state[@id='1']/transient_attributes[@id='1']/instance_attri
> butes[@id='status-1']/nvpair[@id='status-1-r_pgsql-status']:
> @value=STOP
> > May 31 07:38:59 node1-001 pacemaker-based [247412]
> (cib_process_request) info: Completed cib_modify operation for section
> status: OK (rc=0, origin=node2/attrd/16, version=0.547.43)
> > May 31 07:38:59 pgsql(r_pgsql)[248725]: INFO: Set all nodes into async
> mode.
> > May 31 07:38:59 pgsql(r_pgsql)[248725]: INFO: PostgreSQL is already
> running. PID=247940
> > /var/lib/pgsql/14/data
> > 1653982720
> > 5432
> > /var/run/postgresql
> > *
> > 51600331 13
> > ready
> > May 31 07:38:59 node1-001 pacemaker-execd [247414] (log_finished)
> info: r_pgsql start (call 13, PID 248725) exited with status 1 (execution
> time 449ms, queue time 12057ms)
> > May 31 07:38:59 node1-001 pacemaker-controld [247417]
> (process_lrm_event) notice: Result of start operation for r_pgsql on node1:
> error | rc=1 call=13 key=r_pgsql_start_0 confirmed=true cib-update=44
> > May 31 07:38:59 node1-001 pacemaker-based [247412]
> (cib_process_request) info: Forwarding cib_modify operation for section
> status to all (origin=local/crmd/44)
> >
> > 以上、よろしくお願いいたします。
> >
> > > -----Original Message-----
> > > From: renay****@ybb***** <>
> > > Sent: Wednesday, June 8, 2022 3:48 PM
> > > To: 辻 真吾 <tsuji****@ryobi*****>; LINUX-HA
> > > <linux****@lists*****>
> > > Cc: d-ike****@ryobi*****
> > > Subject: Re: RE: RE: [Linux-ha-jp] Pacemakerのフェールオーバー後のノ
> ード
> > > 組込みについて
> > >
> > > 辻さん
> > >
> > > こんにちは、山内です。
> > >
> > > まず、node1でpostgreSQLをkillしてからの停止動作には問題はないよう
> です。
> > > ログを見ると、いくつか気になる動作はしておりますが...とりあえず、２
> 度の
> > > startの件のみに限定して回答します。
> > >
> > > ２度のstartが掛かる原因ですが、以下のログが該当しています。
> > > ----
> > > May 31 07:40:19 node2-001 pacemaker-controld [242326] (run_graph)
> > > notice: Transition 3 (Complete=10, Pending=0, Fired=0, Skipped=0,
> > > Incomplete=0, Source=/var/lib/pacemaker/pengine/pe-input-301.bz2):
> > > Complete
> > > May 31 07:40:19 node2-001 pacemaker-controld [242326]
> > > (do_state_transition) info: State transition S_TRANSITION_ENGINE
> ->
> > > S_POLICY_ENGINE | input=I_PE_CALC cause=C_FSA_INTERNAL
> > > origin=notify_crmd May 31 07:40:19 node2-001
> > > pacemaker-schedulerd[242325] (unpack_config)
> > > notice: On loss of quorum: Ignore
> > > May 31 07:40:19 node2-001 pacemaker-schedulerd[242325]
> > > (determine_online_status) info: Node node1 is online
> > > May 31 07:40:19 node2-001 pacemaker-schedulerd[242325]
> > > (determine_online_status) info: Node node2 is online
> > > May 31 07:40:19 node2-001 pacemaker-schedulerd[242325]
> > > (unpack_rsc_op_failure) warning: Unexpected result (error) was
> > > recorded for start of r_pgsql:0 on node1 at May 31 07:38:59 2022 |
> > > rc=1
> > > id=r_pgsql_last_failure_0
> > > May 31 07:40:19 node2-001 pacemaker-schedulerd[242325]
> > > (pe_get_failcount) info: r_pgsql:0 has failed INFINITY times on node1
> > > May 31 07:40:19 node2-001 pacemaker-schedulerd[242325]
> > > (check_migration_threshold) warning: Forcing ms_pgsql away
> from node1
> > > after 1000000 failures (max=1)
> > > May 31 07:40:19 node2-001 pacemaker-schedulerd[242325]
> > > (pe_get_failcount) info: r_pgsql:1 has failed INFINITY times on node1
> > > May 31 07:40:19 node2-001 pacemaker-schedulerd[242325]
> > > (check_migration_threshold) warning: Forcing ms_pgsql away
> from node1
> > > after 1000000 failures (max=1)
> > > May 31 07:40:19 node2-001 pacemaker-schedulerd[242325]
> > > (pcmk__native_allocate) info: Resource r_pgsql:1 cannot run
> > > anywhere
> > > May 31 07:40:19 node2-001 pacemaker-schedulerd[242325]
> > > (pcmk__set_instance_roles) info: Promoting r_pgsql:0 (Master
> node2)
> > > May 31 07:40:19 node2-001 pacemaker-schedulerd[242325]
> > > (pcmk__set_instance_roles) info: ms_pgsql: Promoted 1
> instances of a
> > > possible 1
> > > May 31 07:40:19 node2-001 pacemaker-schedulerd[242325]
> > > (rsc_action_default) info: Leave r_service_fh (Started
> node2)
> > > May 31 07:40:19 node2-001 pacemaker-schedulerd[242325]
> > > (rsc_action_default) info: Leave r_pgsql:0 (Master node2)
> > > May 31 07:40:19 node2-001 pacemaker-schedulerd[242325]
> > > (rsc_action_default) info: Leave r_pgsql:1 (Stopped)
> > > May 31 07:40:19 node2-001 pacemaker-schedulerd[242325]
> > > (pcmk__log_transition_summary) notice: Calculated transition 4,
> > > saving inputs in /var/lib/pacemaker/pengine/pe-input-302.bz2
> > > May 31 07:40:19 node2-001 pacemaker-controld [242326]
> > > (do_state_transition) info: State transition S_POLICY_ENGINE ->
> > > S_TRANSITION_ENGINE | input=I_PE_SUCCESS
> cause=C_IPC_MESSAGE
> > > origin=handle_response May 31 07:40:19 node2-001 pacemaker-controld
> > > [242326] (do_te_invoke)
> > > info: Processing graph 4 (ref=pe_calc-dc-1653982819-61) derived
> > > from /var/lib/pacemaker/pengine/pe-input-302.bz2
> > > May 31 07:40:19 node2-001 pacemaker-controld [242326] (run_graph)
> > > notice: Transition 4 (Complete=0, Pending=0, Fired=0, Skipped=0,
> > > Incomplete=0, Source=/var/lib/pacemaker/pengine/pe-input-302.bz2):
> > > Complete
> > > May 31 07:40:19 node2-001 pacemaker-controld [242326] (do_log)
> > > info: Input I_TE_SUCCESS received in state S_TRANSITION_ENGINE
> from
> > > notify_crmd May 31 07:40:19 node2-001 pacemaker-controld [242326]
> > > (do_state_transition) notice: State transition
> S_TRANSITION_ENGINE ->
> > > S_IDLE | input=I_TE_SUCCESS cause=C_FSA_INTERNAL
> origin=notify_crmd
> > > ★node1のr_pgsqlのstartの失敗を処理して、クラスタは一旦安定状態に
> 入り
> > > ます。
> > > ----
> > > ★しばらく以下のログが続き...
> > > May 31 07:40:21 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[268937] error output [ #
> > > fh_monitor dig success[OK] STAGE: 1 stpcnt: 0 ]
> > > May 31 07:40:21 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[268937] error output [ #
> > > fh_monitor hostname success[OK] STAGE: 2 stpcnt: 0 ]
> > > May 31 07:40:21 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[268937] error output [ #
> > > fh_monitor dug_ip: xx.xx.xx.xx host_ip: xx.xx.xx.xx stpcnt: 0 ]
> > > May 31 07:40:21 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[268937] error output [ #
> > > fh_monitor Exit:OCF_SUCCESS[OK] ]
> > > May 31 07:40:24 node2-001 pacemaker-based [242321]
> > > (cib_process_ping) info: Reporting our current digest to node2:
> > > cc0b84d295ff3f31db6079faf3ac1c05 for 0.550.1 (0x564c388d0a90 0)
> > > May 31 07:40:31 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[269358] error output [ #
> > > fh_monitor dig success[OK] STAGE: 1 stpcnt: 0 ]
> > > May 31 07:40:31 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[269358] error output [ #
> > > fh_monitor hostname success[OK] STAGE: 2 stpcnt: 0 ]
> > > May 31 07:40:31 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[269358] error output [ #
> > > fh_monitor dug_ip: xx.xx.xx.xx host_ip: xx.xx.xx.xx stpcnt: 0 ]
> > > May 31 07:40:31 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[269358] error output [ #
> > > fh_monitor Exit:OCF_SUCCESS[OK] ]
> > > May 31 07:40:41 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[269783] error output [ #
> > > fh_monitor dig success[OK] STAGE: 1 stpcnt: 0 ]
> > > May 31 07:40:41 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[269783] error output [ #
> > > fh_monitor hostname success[OK] STAGE: 2 stpcnt: 0 ]
> > > May 31 07:40:41 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[269783] error output [ #
> > > fh_monitor dug_ip: xx.xx.xx.xx host_ip: xx.xx.xx.xx stpcnt: 0 ]
> > > May 31 07:40:41 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[269783] error output [ #
> > > fh_monitor Exit:OCF_SUCCESS[OK] ]
> > > May 31 07:40:51 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[270595] error output [ #
> > > fh_monitor dig success[OK] STAGE: 1 stpcnt: 0 ]
> > > May 31 07:40:51 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[270595] error output [ #
> > > fh_monitor hostname success[OK] STAGE: 2 stpcnt: 0 ]
> > > May 31 07:40:51 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[270595] error output [ #
> > > fh_monitor dug_ip: xx.xx.xx.xx host_ip: xx.xx.xx.xx stpcnt: 0 ]
> > > May 31 07:40:51 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[270595] error output [ #
> > > fh_monitor Exit:OCF_SUCCESS[OK] ]
> > > May 31 07:41:01 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[271017] error output [ #
> > > fh_monitor dig success[OK] STAGE: 1 stpcnt: 0 ]
> > > May 31 07:41:01 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[271017] error output [ #
> > > fh_monitor hostname success[OK] STAGE: 2 stpcnt: 0 ]
> > > May 31 07:41:01 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[271017] error output [ #
> > > fh_monitor dug_ip: xx.xx.xx.xx host_ip: xx.xx.xx.xx stpcnt: 0 ]
> > > May 31 07:41:01 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[271017] error output [ #
> > > fh_monitor Exit:OCF_SUCCESS[OK] ]
> > > May 31 07:41:11 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[271548] error output [ #
> > > fh_monitor dig success[OK] STAGE: 1 stpcnt: 0 ]
> > > May 31 07:41:11 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[271548] error output [ #
> > > fh_monitor hostname success[OK] STAGE: 2 stpcnt: 0 ]
> > > May 31 07:41:11 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[271548] error output [ #
> > > fh_monitor dug_ip: xx.xx.xx.xx host_ip: xx.xx.xx.xx stpcnt: 0 ]
> > > May 31 07:41:11 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[271548] error output [ #
> > > fh_monitor Exit:OCF_SUCCESS[OK] ]
> > > May 31 07:41:21 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[272286] error output [ #
> > > fh_monitor dig success[OK] STAGE: 1 stpcnt: 0 ]
> > > May 31 07:41:21 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[272286] error output [ #
> > > fh_monitor hostname success[OK] STAGE: 2 stpcnt: 0 ]
> > > May 31 07:41:21 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[272286] error output [ #
> > > fh_monitor dug_ip: xx.xx.xx.xx host_ip: xx.xx.xx.xx stpcnt: 0 ]
> > > May 31 07:41:21 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[272286] error output [ #
> > > fh_monitor Exit:OCF_SUCCESS[OK] ]
> > > May 31 07:41:31 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[272782] error output [ #
> > > fh_monitor dig success[OK] STAGE: 1 stpcnt: 0 ]
> > > May 31 07:41:31 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[272782] error output [ #
> > > fh_monitor hostname success[OK] STAGE: 2 stpcnt: 0 ]
> > > May 31 07:41:31 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[272782] error output [ #
> > > fh_monitor dug_ip: xx.xx.xx.xx host_ip: xx.xx.xx.xx stpcnt: 0 ]
> > > May 31 07:41:31 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[272782] error output [ #
> > > fh_monitor Exit:OCF_SUCCESS[OK] ]
> > > May 31 07:41:41 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[273223] error output [ #
> > > fh_monitor dig success[OK] STAGE: 1 stpcnt: 0 ]
> > > May 31 07:41:41 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[273223] error output [ #
> > > fh_monitor hostname success[OK] STAGE: 2 stpcnt: 0 ]
> > > May 31 07:41:41 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[273223] error output [ #
> > > fh_monitor dug_ip: xx.xx.xx.xx host_ip: xx.xx.xx.xx stpcnt: 0 ]
> > > May 31 07:41:41 node2-001 pacemaker-execd [242323]
> (log_op_output)
> > > notice: r_service_fh_monitor_10000[273223] error output [ #
> > > fh_monitor Exit:OCF_SUCCESS[OK] ]
> > > ----
> > > ★S_IDLE(07:40:19)から1分27秒後にnode1のエラーが、node2からクリ
> アさ
> > > れています。
> > > May 31 07:41:46 node2-001 pacemaker-attrd [242324]
> > > (attrd_peer_update) notice: Setting
> last-failure-r_pgsql#start_0[node1]:
> > > 1653982739 -> (unset) | from node2
> > > May 31 07:41:46 node2-001 pacemaker-attrd [242324]
> (write_attribute)
> > > info: Sent CIB request 21 with 2 changes for
> > > last-failure-r_pgsql#start_0 (id n/a, set n/a)
> > > May 31 07:41:46 node2-001 pacemaker-based [242321]
> > > (cib_process_request) info: Forwarding cib_modify operation for
> section
> > > status to all (origin=local/attrd/21)
> > > May 31 07:41:46 node2-001 pacemaker-attrd [242324]
> > > (attrd_peer_update) notice: Setting
> fail-count-r_pgsql#start_0[node1]:
> > > INFINITY -> (unset) | from node2
> > > May 31 07:41:46 node2-001 pacemaker-attrd [242324]
> (write_attribute)
> > > info: Sent CIB request 22 with 2 changes for
> > > fail-count-r_pgsql#start_0 (id n/a, set n/a)
> > > May 31 07:41:46 node2-001 pacemaker-based [242321]
> > > (cib_process_request) info: Forwarding cib_modify operation for
> section
> > > status to all (origin=local/attrd/22)
> > > May 31 07:41:46 node2-001 pacemaker-based [242321]
> (cib_perform_op)
> > > info: Diff: --- 0.550.1 2
> > > May 31 07:41:46 node2-001 pacemaker-based [242321]
> (cib_perform_op)
> > > info: Diff: +++ 0.550.2 (null)
> > > May 31 07:41:46 node2-001 pacemaker-based [242321]
> (cib_perform_op)
> > > info: --
> > > /cib/status/node_state[@id='1']/transient_attributes[@id='1']/instan
> > > ce_attri
> > >
> butes[@id='status-1']/nvpair[@id='status-1-last-failure-r_pgsql.start_0']
> > > May 31 07:41:46 node2-001 pacemaker-based [242321]
> (cib_perform_op)
> > > info: + /cib: @num_updates=2
> > > May 31 07:41:46 node2-001 pacemaker-based [242321]
> > > (cib_process_request) info: Completed cib_modify operation for
> section
> > > status: OK (rc=0, origin=node2/attrd/21, version=0.550.2)
> > > May 31 07:41:46 node2-001 pacemaker-attrd [242324]
> > > (attrd_cib_callback) info: CIB update 21 result for
> > > last-failure-r_pgsql#start_0: OK | rc=0
> > > May 31 07:41:46 node2-001 pacemaker-attrd [242324]
> > > (attrd_cib_callback) info: *
> last-failure-r_pgsql#start_0[node1]=(null)
> > > May 31 07:41:46 node2-001 pacemaker-attrd [242324]
> > > (attrd_cib_callback) info: *
> last-failure-r_pgsql#start_0[node2]=(null)
> > > May 31 07:41:46 node2-001 pacemaker-controld [242326]
> > > (abort_transition_graph) info: Transition 4 aborted by deletion of
> > > nvpair[@id='status-1-last-failure-r_pgsql.start_0']: Transient
> > > attribute change
> > > | cib=0.550.2 source=abort_unless_down:327
> > > path=/cib/status/node_state[@id='1']/transient_attributes[@id='1']/i
> > > nstanc
> > > e_attributes[@id='status-1']/nvpair[@id='status-1-last-failure-r_pgs
> > > ql.start_
> > > 0'] complete=true
> > > May 31 07:41:46 node2-001 pacemaker-controld [242326]
> > > (do_state_transition) notice: State transition S_IDLE ->
> S_POLICY_ENGINE
> > > | input=I_PE_CALC cause=C_FSA_INTERNAL
> origin=abort_transition_graph
> > >
> > > ★この為、以降で、エラーが解除された為、再度、node1のr_pgsqlのstart
> が
> > > 計算・実行されています。
> > > ----
> > >
> > > 何かお使いになっているリソースや、手順などで、node2からnode1の
> r_pgsql
> > > のエラーカウントをクリアするような事が起きていませんでしょうか？
> > > もしくは、使ったことはありませんが、failure-timeoutを設定しているな
> どで、
> > > エラーカウントを一定時間で実行するような設定を使っていませんか？
> > >
> > > なお、pacemakaerに流し込んでいる設定ファイルを開示して頂ければ、
> こちら
> > > の手元でも、簡易な構成で確認してみることは可能です。
> > >
> > > 以上、宜しくお願いいたします。
> > >
> > >
> > >
> > > > ----- Original Message -----
> > > >
> > > > From: "辻 真吾" <tsuji****@ryobi*****>
> > > > To: "renay****@ybb*****" <renay****@ybb*****>;
> > > "LINUX-HA" <linux****@lists*****>
> > > > Cc: "d-ike****@ryobi*****" <d-ike****@ryobi*****>
> > > > Date: 2022/06/07 火 17:09
> > > > Subject: RE: RE: [Linux-ha-jp] Pacemakerのフェールオーバー後のノ
> ード
> > > 組込みについて
> > > >
> > > >
> > > > 山内さん
> > > >
> > > > お世話になっております。辻です。
> > > >
> > > > > まだ、ログについては、これから拝見しますが、2度start(例えば、故
> 障な
> > > どが
> > > > > 起きてstopしてstart(restart))は聞いたことがありません。
> > > >
> > > > 承知しました。ありがとうございます。
> > > >
> > > > > また、ログを拝見してご連絡いたします。
> > > >
> > > > ありがとうございます。お手数をおかけします。
> > > >
> > > > 以上、よろしくお願いいたします。
> > > >
> > > > > -----Original Message-----
> > > > > From: renay****@ybb***** <>
> > > > > Sent: Tuesday, June 7, 2022 4:57 PM
> > > > > To: tsuji****@ryobi*****; LINUX-HA <linux****@lists*****>
> > > > > Cc: d-ike****@ryobi*****
> > > > > Subject: Re: RE: [Linux-ha-jp] Pacemakerのフェールオーバー後のノ
> ード
> > > 組込
> > > > > みについて
> > > > >
> > > > > 辻さん
> > > > >
> > > > > こんにちは、山内です。
> > > > >
> > > > > ログの送付ありがとうございました。拝見させていただきます。
> > > > >
> > > > > > ちなみに、これまでに他の利用者で同様に二度startされたようなケ
> ース
> > > は
> > > > > > ございますか？
> > > > > > どのような時に二度startされるのか、情報をお持ちでしたら可能な
> 範囲
> > > で
> > > > > > 共有いただけますと幸いです。
> > > > > まだ、ログについては、これから拝見しますが、2度start(例えば、故
> 障な
> > > どが
> > > > > 起きてstopしてstart(restart))は聞いたことがありません。
> > > > >
> > > > > 他に知見がある方が、コメントしてくれるかも知れません。
> > > > >
> > > > > 1)2)について、承知いたしました。
> > > > > また、ログを拝見してご連絡いたします。
> > > > >
> > > > > 以上、よろしくお願いたします。
> > > > >
> > > > >
> > > > > > ----- Original Message -----
> > > > > >
> > > > > > From: "辻 真吾" <tsuji****@ryobi*****>
> > > > > > To: "renay****@ybb*****"
> <renay****@ybb*****>;
> > > > > "LINUX-HA" <linux****@lists*****>
> > > > > > Cc: "d-ike****@ryobi*****" <d-ike****@ryobi*****>
> > > > > > Date: 2022/06/07 火 15:42
> > > > > > Subject: RE: [Linux-ha-jp] Pacemakerのフェールオーバー後のノ
> ード
> > > 組込
> > > > > みについて
> > > > > >
> > > > > >
> > > > > > 山内さん
> > > > > >
> > > > > > お世話になります。辻です。
> > > > > >
> > > > > > ※先ほど、本メールと同じ内容のメールを送信しましたが、
> > > > > > ※送信エラーになりましたので、再送します。
> > > > > > ※重複して受信された場合は、先のメールの破棄をお願いします。
> > > > > >
> > > > > > 早速のお返事、ありがとうございます。
> > > > > >
> > > > > > > RAが２度startされているとのことですが、ログなど拝見出来れ
> ばな
> > > にか
> > > > > わか
> > > > > > > るかも知れません。
> > > > > >
> > > > > > 恐縮ですが、ログを送付させていただきますので、何かお気付きの
> 点が
> > > > > > ありましたら、ご助言いただけますと幸いです。
> > > > > > （添付ファイルの送信でエラーになったようですので、このメール
> の後
> > > で
> > > > > > 山内さん個別にログを送付させていただきます。）
> > > > > >
> > > > > > ちなみに、これまでに他の利用者で同様に二度startされたようなケ
> ース
> > > は
> > > > > > ございますか？
> > > > > > どのような時に二度startされるのか、情報をお持ちでしたら可能な
> 範囲
> > > で
> > > > > > 共有いただけますと幸いです。
> > > > > >
> > > > > > > 1)STONITHは組み込まれていると思いますが、マスターノードは
> 正常
> > > にフ
> > > > > ェン
> > > > > > > シング終了して、再起動しているでしょうか？
> > > > > >
> > > > > > 停止時のログでfencing関連のメッセージは以下のものがありまし
> た。
> > > > > > 最後の「disconnected」により停止されているように見えますが、
> > > > > > いかがでしょうか？
> > > > > > このメッセージより後に、組込みの起動を行っております。
> > > > > >
> > > > > > May 31 07:32:28 node1-001 pacemaker-controld [224147]
> > > > > (stonith__watchdog_fencing_enabled_for_node_api) warning:
> > > > > watchdog-fencing-query failed
> > > > > > May 31 07:34:36 node1-001 pacemaker-controld [224147]
> > > > > (stonith__watchdog_fencing_enabled_for_node_api) warning:
> > > > > watchdog-fencing-query failed
> > > > > > May 31 07:35:19 node1-001 pacemaker-controld [224147]
> > > > > (tengine_stonith_connection_destroy) info: Fencing daemon
> > > disconnected
> > > > > >
> > > > > >
> > > > > > > 2)corosync/pacemakerのsystemdの自動起動が有効になってい
> たり
> > > しま
> > > > > せん
> > > > > > > でしょうか？
> > > > > >
> > > > > > こちらの設定は、無効化しております。
> > > > > >
> > > > > > 以上、よろしくお願いいたします。
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Linux-ha-japan <> On Behalf Of
> > > > > > > renay****@ybb*****
> > > > > > > Sent: Saturday, June 4, 2022 9:20 AM
> > > > > > > To: linux****@lists*****
> > > > > > > Cc: d-ike****@ryobi*****
> > > > > > > Subject: Re: [Linux-ha-jp] Pacemakerのフェールオーバー後のノ
> ード
> > > 組込
> > > > > みに
> > > > > > > ついて
> > > > > > >
> > > > > > > 辻さん
> > > > > > >
> > > > > > > こんにちは、山内です。
> > > > > > >
> > > > > > > 5)が正常に終わっているとのことですので、マスターに昇格した
> スレ
> > > ーブ
> > > > > との
> > > > > > > 同期は正しく実行されていると思いますので、
> > > > > > > 再起動して、スレーブ起動しようとしているpacemakerのリソー
> ス起
> > > 動中
> > > > > に何
> > > > > > > か起きていると思われます。
> > > > > > >
> > > > > > > RAが２度startされているとのことですが、ログなど拝見出来れ
> ばな
> > > にか
> > > > > わか
> > > > > > > るかも知れません。
> > > > > > >
> > > > > > > 以下の点、とりあえず、確認して見た方が良いかと思います。
> > > > > > > 1)STONITHは組み込まれていると思いますが、マスターノードは
> 正常
> > > にフ
> > > > > ェン
> > > > > > > シング終了して、再起動しているでしょうか？
> > > > > > > 2)corosync/pacemakerのsystemdの自動起動が有効になってい
> たり
> > > しま
> > > > > せん
> > > > > > > でしょうか？
> > > > > > >
> > > > > > > 以上、よろしくお願いいたします。
> > > > > > >
> > > > > > > > ----- Original Message -----
> > > > > > > >
> > > > > > > > From: "辻 真吾" <tsuji****@ryobi*****>
> > > > > > > > To: "LINUX-HA" <linux****@lists*****>
> > > > > > > > Cc: "d-ike****@ryobi*****" <d-ike****@ryobi*****>
> > > > > > > > Date: 2022/06/03 金 16:29
> > > > > > > > Subject: [Linux-ha-jp] Pacemakerのフェールオーバー後のノー
> ド組
> > > 込み
> > > > > に
> > > > > > > ついて
> > > > > > > >
> > > > > > > >
> > > > > > > > 初めて投稿させていただきます。
> > > > > > > > 辻と申します。
> > > > > > > >
> > > > > > > > DBサーバ(PostgreSQLレプリケーション構成)を
> > > > > > > > Pacemaker+Corosyncを使用してHAクラスタ構成としていま
> す。
> > > > > > > >
> > > > > > > > クラスタ構成において、フェールオーバーを発生させて、
> > > > > > > > その後に、ダウンさせたノードの組込みを実施したところ、
> > > > > > > > 組込みに失敗するという事象が発生しております。
> > > > > > > >
> > > > > > > > 初期状態のノードを以下の構成として、実施した手順を記載い
> たし
> > > ます。
> > > > > > > > - マスターノード：ノード1
> > > > > > > > - スレーブノード：ノード2
> > > > > > > >
> > > > > > > > 実施手順
> > > > > > > > 1. ノード1のpostgresプロセスをkill
> > > > > > > > 2. ノード2がマスターに昇格
> > > > > > > > 3. ノード1のpacemaker、corosyncをsystemctlで停止
> > > > > > > > 4. ノード1でテーブル空間のディレクトリ配下とPGDATAの
> ディ
> > > レク
> > > > > トリ
> > > > > > > を削除
> > > > > > > > 5. ノード1でpg_basebackupを実施
> > > > > > > > $ /usr/pgsql-14/bin/pg_basebackup -h <ノード2> -D
> > > $PGDATA
> > > > > -Xs
> > > > > > > -P -n
> > > > > > > > 6. ノード1のcorosync、pacemakerをsystemctlで起動
> > > > > > > > → ここでノード1が"sync"状態になる想定ですが、
> > > > > > > > 実際には起動処理が実施された後に、
> > > > > > > > 停止状態に遷移してしまいます。※
> > > > > > > >
> > > > > > > > ※
> > > > > > > > 手順6の起動を実施した際に、RAのpgsqlでstart処理が二
> 度呼
> > > ばれ
> > > > > てい
> > > > > > > ます。
> > > > > > > > 一度目のstartは正常終了していますが、二度目のstartが異
> 常終
> > > 了し
> > > > > て、
> > > > > > > > 停止状態に遷移しています。
> > > > > > > >
> > > > > > > > 使用しているバージョンは以下の通りです。
> > > > > > > > corosync ： 3.1.5-1
> > > > > > > > pacemaker： 2.1.0-8
> > > > > > > > pcs ： 0.10.10-4
> > > > > > > > PotgreSQL： 14.1
> > > > > > > >
> > > > > > > > 原因と対処方法などをご存じの方がおられましたら、ご教授く
> ださ
> > > い。
> > > > > > > > よろしくお願いいたします。
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > Linux-ha-japan mailing list Linux****@lists*****
> > > > > > > > https://lists.osdn.me/mailman/listinfo/linux-ha-japan
> > > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Linux-ha-japan mailing list
> > > > > > > Linux****@lists*****
> > > > > > > https://lists.osdn.me/mailman/listinfo/linux-ha-japan
> > > > > >
> > > >
> > > >
> >