NAKAHIRA Kazutomo
nakahira_kazutomo_b1****@lab*****
2014年 10月 2日 (木) 15:50:21 JST
TO：稲垣様 中平と申します。 Pacemakerが出力するログは大量かつ煩雑で、生のログを追っかけて 動作を確認することはあまりお勧めできません。 PG-REX9.3利用マニュアル_第1.0版(公開用利用者マニュアル).docx の手順に従って環境を構築されているのであれば、pm_logconv-hb という Pacemakerのログ変換ツールが一緒にインストールされて いると思いますので、こちらのログを参照することで、稲垣様が 確認されたい事項は大抵読み取る事ができるかと思います。 上記ツールは、デフォルトで /var/log/pm_logconv.out に変換後 のログを出力しています。 出力されるログ一覧は以下に挙げられていますが、例えばリソース の起動開始から完了までの時刻を知りたいなら No.1-1 と 1-2 を、 フェイルオーバ開始から完了までの時刻を知りたいなら No.F0-1 と F12-1のログを確認する、といった使い方ができます。 http://sourceforge.jp/projects/linux-ha/wiki/hb-logconv_message # 記述内容が旧バージョンのものから更新されていないため、一部最新 # のメッセージと異なったり不足があるかもしれません。 # そのようなものについては、適宜ご自身の環境で出力されているもの # に置き換えて参照して下さい。 また上記ログを参照する際の注意点として、出力内容がノードによって 異なる点が挙げられます。 当たり前といえばそうなのですが、リソースの起動・終了を示すログは 実際にリソースが稼働しているノードのみで出力され、片方のノードの ログだけを見ては、全てのリソースに関する情報を把握できません。 またフェイルオーバの開始/終了ログは DCノードと呼ばれるクラスタを 管理するノード(Pacemakerが自動的に決定)でのみ出力されます。 ある特定のノードにすべてのログが集約して出力される、というような 動作にはなっておりませんので、ログ解析を行うときには両系のログを 参照しつつ作業を進める必要があります。 以上、ご参考までに。 On 2014/10/01 10:34, tsuyo****@hitac***** wrote: > ひがしさま > > 稲垣です。 > > 早々のご回答ありがとうございました。 > 試してみたいと思います。 > > PS > フェイルオーバ、フェイルバックのノードやプロセスの動き（例えば障害検知 > まで何秒かかっている、postgresをキックはこのタイミング…等）を確認するため > syslogを追っかけたりしてますが、もし、まとまった資料などありましたら > 教えていただけると助かります。 > もしくは、syslogを読む勉強会など開いてくださると助かります（ニッチですねｗ）。 > > 以上、よろしくお願いします。 > > 稲垣 > > >> 稲垣様 >> >> ひがしと申します。 >> お世話になっております。 >> >> >> PG-REXの構築および運用は、以下PG-REXコミュニティに >> あるマニュアルが詳しいです。 >> >> PG-REXコミュニティ： >> http://sourceforge.jp/projects/pg-rex/ >> >> PG-REX9.3マニュアル： >> http://sourceforge.jp/projects/pg-rex/releases/61544 >> →PG-REX9.3利用マニュアル_第1.0版(公開用利用者マニュアル).docx >> >> このマニュアルでは基本的にPG-REX運用補助ツールというものを >> 使用する前提で記述されていますが、付録にツール無しでの運用方法も >> 記載されています。 >> >> >>> 質問内容： >>> 現在の検証環境はプロセスやノードに障害がおこるとフェイルオーバ >>> します。Postgresql(マスタ)のプロセス障害を想定してkillした後、 >>> 再度（スレーブに移行した）postgresqlのプロセスをサービスに影響 >>> なく復活させたいのですが、どのような手続きがあるのか、教えて >>> いただけると助かります。 >> 例えば、node01がMaster、node02がSlaveの状態でMasterをkill(故障)すると、 >> node02がMasterに昇格し、node01のPostgreSQLは停止(pgsql-status: STOP) >> しているはずです。 >> >> その状態で、node01をSlaveとして復旧するには、上記マニュアルの >> 「A.3. Slaveの起動」の手順をnode01に対して行ってください。 >> >> 手順をざっくり言うと、node01で、 >> ・Pacemaker停止 >> ・現Masterから最新データをコピー >> ・ロックファイル削除 >> ・Pacemaker起動 >> →node01がSlaveとして起動する >> という感じです。 >> >> この手順中、node02はMasterとして稼働したままなので、 >> サービスには影響有りません。 >> >> >> 以上です。 >> 参考になれば幸いです。 >> >> 2014/10/01 (Wed) 09:57, tsuyo****@hitac***** wrote: >>> お世話になります。 >>> 稲垣と申します。 >>> >>> 下記の環境で検証しています。初心者的な質問で恐縮ですが、 >>> ご教授いただけると助かります。 >>> >>> 環境： >>> CentOS 6.5 64bit x2台 >>> heartbeat-3.0.5-1.1.el6.x86_64 >>> pacemaker-1.0.13-1.el6.x86_64 >>> postgresql93-9.3.5-1PGDG.rhel6.x86_64 >>> （PostgreSQLはストリーミングレプリケーション使用） >>> >>> crmの設定は、講演資料を参考に作っていますので、 >>> 同じ内容と考えていただければよいかと思います。 >>> >>> 質問内容： >>> 現在の検証環境はプロセスやノードに障害がおこるとフェイルオーバ >>> します。Postgresql(マスタ)のプロセス障害を想定してkillした後、 >>> 再度（スレーブに移行した）postgresqlのプロセスをサービスに影響 >>> なく復活させたいのですが、どのような手続きがあるのか、教えて >>> いただけると助かります。 >>> >>> ・crm resource start <リソース名> >>> では、一旦サービス停止状態になってしまうので、方法がないかと >>> 思っています。 >>> >>> ちなみに、crm resource start <リソース>で起動すると、リソースが >>> 2つになったように見えるのですが、問題があるのでしょうか？ >>> >>> Node Attributes: >>> * Node pgres1: >>> + app-connect : 100 >>> + master-res-pgsql:0 : 100 >>> + master-res-pgsql:1 : -INFINITY >>> + res-pgsql-data-status : STREAMING|SYNC >>> + res-pgsql-status : HS:sync >>> * Node pgres2: >>> + app-connect : 100 >>> + master-res-pgsql:0 : 1000 >>> + master-res-pgsql:1 : 1000 >>> + res-pgsql-data-status : LATEST >>> + res-pgsql-master-baseline : 00000000070E8810 >>> + res-pgsql-status : PRI >>> >>> >>> 以上、よろしくお願いします。 >>> >>> 稲垣 >>> >>> _______________________________________________ >>> Linux-ha-japan mailing list >>> Linux****@lists***** >>> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan >>> >> > > _______________________________________________ > Linux-ha-japan mailing list > Linux****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan > -- NTTデータ先端技術株式会社 中平 和友 TEL: 03-5860-5135 FAX: 03-5463-6490 Mail: nakahira_kazutomo_b1****@lab*****
Fork