Keisuke Nakamura
k.xna****@gmail*****
2016年 1月 27日 (水) 11:15:58 JST
Forkひがし様、関係者各位
お世話になっております。nakaと申します。
返信が遅くなってしまい申し訳ありません。
ご連絡頂き有難うございます。
> 待機系(hoge02v)で起動したという２つのMySQLはそれぞれ誰が起動したものか
> 心当たりはないでしょうか？
> (元々、待機系(hoge02v)で手動でMySQLを起動させてはいませんでしたか？
> もしくはOSのMySQLサービスの自動起動が有効になっていませんか？)
特に待機系側で手動でMySQLを起動させていたわけでもなく、
OSでMySQLサービスの自動起動を有効にしていたわけでもありませんでした。
MySQLサービススクリプトは独自のものを使っており、LSBに準拠した形（7つの
返り値のルール）で作っておりました。
2つのMySQLはそれぞれ誰が起動してるのか、ログを調べました。
どうやらサービスリソースのstartとmonitorの起動がほぼ同時に行われてるのが原因かなと
推測しています。MySQLサービスが完全に起動する前にmonitorがstatusをチェックして
「MySQLは起動していないから、restartしよう」と動作し、二重起動になってしまった
かなと考えています。
# grep "rsc:" /var/log/heartbeat_info.log-20160124
(一部抜粋)
6 local3.info<158> 2016-01-20T10:57:27.110393+09:00 hoge02v lrmd:
[2729]: info: rsc:service_sfdb01v start[18] (pid 8866) ★
6 local3.info<158> 2016-01-20T10:57:27.192217+09:00 hoge02v lrmd:
[2729]: info: rsc:service_sfdb01v monitor[19] (pid 8938) ★
6 local3.info<158> 2016-01-20T10:57:27.617212+09:00 hoge02v lrmd:
[2729]: info: rsc:service_sfdb01v stop[20] (pid 9573)
6 local3.info<158> 2016-01-20T10:57:27.667986+09:00 hoge02v lrmd:
[2729]: info: rsc:service_sfdb01v start[21] (pid 9637)
6 local3.info<158> 2016-01-20T10:57:29.721799+09:00 hoge02v lrmd:
[2729]: info: rsc:service_sfdb01v monitor[22] (pid 10364)
6 local3.info<158> 2016-01-20T10:59:10.098877+09:00 hoge02v lrmd:
[2729]: info: rsc:service_sfdb01v stop[23] (pid 13968)
6 local3.info<158> 2016-01-20T10:59:10.152291+09:00 hoge02v lrmd:
[2729]: info: rsc:service_sfdb01v start[24] (pid 14000)
6 local3.info<158> 2016-01-20T11:00:40.268121+09:00 hoge02v lrmd:
[2729]: info: rsc:service_sfdb01v stop[25] (pid 18137)
試しに、開始時間を遅らせるオプションをサービスリソースに設定してみました。
primitive service_sfdb01v lsb:pkg_sfdb01v \
op monitor interval="300s" enabled="true" timeout="20s"
start-delay="10s" \
として「start-delay="10s"」を追記してみたところ、OSハングさせると想定通りに
待機系へF/Oしてくれました。startの10秒後にmonitorが起動する旨のログが出ていました。
疑問なのは、
shutdownコマンドを実施した時、/etc/init.d/heartbeat stopさせた時等のケースでは、
上記のstart-delayオプションをつけなくても必ず正常に待機系へF/Oしてくれます。
ログを見ると、サービスがstartしてから数秒後～数十秒後にminitorが起動しているので、
サービスがstartしたことをどこかでちゃんと認識してるようです。
OSハングアップの時では、start・monitorの開始が必ずほぼ同じタイミングで行われます。
OSハングアップ時だと挙動が異なるものなのでしょうか。。？
同じ境遇でstart-delayオプションを設定した方はいらっしゃいませんでしょうか。
お手数おかけ致しますが、もし情報等お持ちでしたら共有頂けると幸いです。
以上、宜しくお願い致します。
2016年1月14日 14:09 <kazuh****@goo*****>:
>
> naka様
>
> ひがしと申します。
> お世話になります。
>
> >実際に稼働系を
> ># echo c > /proc/sysrq-trigger
> >でハングアップさせたところ、待機系(hoge02v)でなぜかMySQLインスタンスが二重起動
> >しておかしな
> >状態になりました。その後元々の稼働系(hoge01v)のOSが起動してきた後、hoge01vにク
> >ラスタリソースがF/Bされました。
>
> 待機系(hoge02v)で起動したという２つのMySQLはそれぞれ誰が起動したものか
> 心当たりはないでしょうか？
> (元々、待機系(hoge02v)で手動でMySQLを起動させてはいませんでしたか？
> もしくはOSのMySQLサービスの自動起動が有効になっていませんか？)
>
> Pacemaker以外がMySQLを起動することの無いよう、運用を行ってください。
>
>
> > primitive service_sfdb01v lsb:pkg_sfdb01v \
> とのことなので、Pacemakerに付属(resource-agentsパッケージに同梱のmysql RAでは
> なく、独自のスクリプトでMySQLを制御しているとお見受けしました。
>
> Pacemakerのリソース制御スクリプトとして使用するためには、スクリプトは
> 以下の仕様(LSB)を満たす必要があります。
>
> http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html/Pacemaker_Explained/ap-lsb.html
>
> 特に、既に起動時にstartされた場合や、既に停止時にstopされた場合の挙動と引数も
> 重要です。
>
> 今回のケースでは、この「既に起動時にstartされた場合」に、pkg_sfdb01vが、
> 「何もせず、0を返す。(already running等ログメッセージを表示してもよい。)」
> という動作になるか、確認してください。(上記URLの3のケース)
>
>
> 以上です。
> よろしくお願いいたします。
>
>
> ----- 元のメッセージ -----
> From: "Keisuke Nakamura" <k.xna****@gmail*****>
> 宛先: linux****@lists*****
> 送信済み: 2016年1月8日, 金曜日 午後 7:20:26
> 件名: [Linux-ha-jp] OSハングアップ時の挙動
>
>
>
>
>
> 関係者各位
> お世話になっております。nakaと申します。
> 小出しで申し訳ありません。
>
> 環境：
> CentOS 6.2(x86_64)
> pacemaker-1.0.12-1.el6.x86_64
> 稼働系：hoge01v
> 待機系：hoge02v
>
> 異常時の動作検証をしております。
> 2ノードクラスタ構成にて、稼働系をSYSRQにてハングアップさせた時に
> 待機系にF/Oしてそのまま待機系でサービスリソース(MySQL)が起動することを
> 期待しております。
>
> 実際に稼働系を
> # echo c > /proc/sysrq-trigger
> でハングアップさせたところ、待機系(hoge02v)でなぜかMySQLインスタンスが二重起動しておかしな
> 状態になりました。その後元々の稼働系(hoge01v)のOSが起動してきた後、hoge01vにクラスタリソースがF/Bされました。
>
> （crm_mon -Afr1）
> Migration summary:
> * Node hoge02v:
> service_sfdb01v: migration-threshold=1000000 fail-count=1000000
> * Node hoge01v:
>
> Failed actions:
> service_sfdb01v_monitor_300000 (node=hoge02v, call=24, rc=7, status=complete): not running
> service_sfdb01v_start_0 (node=hoge02v, call=27, rc=-2, status=Timed Out): unknown exec error
>
> 「service_sfdb01v」というのがMySQLサービスのリソースとなります。
>
>
>
> （設定内容）
> # crm configure save current.crm
>
> # cat current.crm
>
> node $id="1fc381d6-d6ad-a50f-9aab-cd8ace90fa70" hoge01v
> node $id="4a851515-443f-6140-b38f-dfb4bb46c010" hoge02v
> primitive ip_sfdb01v ocf:heartbeat:IPaddr2 \
> meta migration-threshold="5" \
> params ip="10.2.28.62" cidr_netmask="24" nic="eth0" iflabel="0" \
> op monitor interval="3s"
> primitive res_ping ocf:pacemaker:ping \
> params name="eth0_ping_set" host_list="10.2.28.1" multiplier="200" dampen="1" debug="true" attempts="10" \
> op monitor interval="10s" timeout="60" \
> op start interval="0" timeout="60"
> primitive service_naka01v lsb:pkg_naka01v \
> op start interval="0s" timeout="90s" \
> op monitor interval="300s" timeout="20s" \
> op stop interval="0s" timeout="100s" \
> meta is-managed="true"
> primitive service_sfdb01v lsb:pkg_sfdb01v \
> op start interval="0s" timeout="90s" \
> op monitor interval="300s" enabled="true" timeout="20s" \
> op stop interval="0s" timeout="100s" \
> meta is-managed="true"
> primitive vgsfdb01v ocf:heartbeat:LVM \
> params volgrpname="vgsfdb01v"
> primitive vgsfdb01v_LogVol00 ocf:heartbeat:Filesystem \
> meta migration-threshold="5" \
> params device="/dev/vgsfdb01v/LogVol00" fstype="ext4" directory="/mysf" \
> op monitor interval="20s"
> primitive vgsfdb01v_lv_quorum ocf:heartbeat:sfex \
> params index="1" device="/dev/vgsfdb01v/lv_quorum"
> group pkg_naka01v service_naka01v \
> meta is-managed="true" target-role="Started"
> group pkg_sfdb01v ip_sfdb01v vgsfdb01v vgsfdb01v_lv_quorum vgsfdb01v_LogVol00 service_sfdb01v \
> meta is-managed="true" target-role="Started"
> clone clone_ping res_ping \
> meta target-role="Started"
> location pkg_naka01v-location pkg_naka01v \
> rule $id="pkg_naka01v-location-0" 200: #uname eq hoge01v \
> rule $id="pkg_naka01v-location-1" 100: #uname eq hoge02v
> location pkg_naka01v-service-location pkg_naka01v \
> rule $id="pkg_naka01v-service-location-rule" -inf: defined eth0_ping_set and eth0_ping_set lt 200
> location pkg_sfdb01v-location pkg_sfdb01v \
> rule $id="pkg_sfdb01v-location-0" 200: #uname eq hoge01v \
> rule $id="pkg_sfdb01v-location-1" 100: #uname eq hoge02v
> location pkg_sfdb01v-service-location pkg_sfdb01v \
> rule $id="pkg_sfdb01v-service-location-rule" -inf: defined eth0_ping_set and eth0_ping_set lt 200
> property $id="cib-bootstrap-options" \
> dc-version="1.0.12-066152e" \
> cluster-infrastructure="Heartbeat" \
> stonith-enabled="false" \
> no-quorum-policy="ignore" \
> default-action-timeout="120s" \
> last-lrm-refresh="1450681148" \
> maintenance-mode="false"
> rsc_defaults $id="rsc-options" \
> resource-stickiness="INFINITY"
>
>
> 異常時にどのような仕組みでF/Oするか正確なところを理解しておらず、私も
> 調査段階ではありますが、被疑箇所とみられる部分等ご存知でしたら、アドバイスを
> 頂けると幸いです。Packemakerというより、こちらのMySQL起動停止のスクリプトだったり
> エラーハンドリングに問題があるのかも未調査です。
>
>
> 曖昧な状態でのメールとなり恐縮ですが、宜しくお願い致します。
>
> 以上、宜しくお願い致します。
>
> --
>
> Nakamura
>
> _______________________________________________
> 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
--
Nakamura