NAKAHIRA Kazutomo
nakahira_kazutomo_b1****@lab*****
2014年 8月 15日 (金) 14:32:42 JST
TO：久慈さん 中平と申します。 松島さんの回答に加え、以下の共有ディスクの監視についてですが > この場合、リソースエージェントFilesystemに加えてリソースエージェント diskdをクローン化し、両系でのディスク監視も行った方が良いのでしょうか。 diskdをクローン化し、両系で監視を行うことをお勧めします。 現用系では diskdがなくとも Filesystem RAの monitor処理で故障を検知し フェイルオーバが起きる可能性がありますが、diskdがあった方がより確実に 故障を検知できます。 また待機系で共有ディスクの監視が行われない場合、実際にフェイルオーバが 発生し待機系で Filesystemのマウントを試みるまで共有ディスクとの接続に 異常があることに気付くことができず、この時点で問題が発生するとサービス が停止してしまいます。 このような事態を防ぐために、待機系でも定期的な共有ディスクの監視を行い 正常にフェイルオーバが可能な状態であることを確認する必要があります。 On 2014/08/15 14:15, Takehiro Matsushima wrote: > 久慈さん > > こんにちは、松島です。 > > >> 2.共有ディスクの監視について > > 共有ディスクの運用経験がありませんので、こちらにつきましてはなにもお伝え出来ません。 > 申し訳ございません。 > > >> 1.リソースエージェントpgsqlについて > >> リソースエージェントpgsqlと/etc/rc.d/init.d/postgresql-9.2を見比べたところ、見ているpidファイルが >> 違うためのようなのですが、これはRAの仕様というかそういうものなのでしょうか。 >> (heartbeatで管理しているか、serviceで管理しているかを区別するため？) > > PostgreSQLのPIDファイルがRAとSysV initスクリプトとで違うのは単純に仕様の違いだと思います。 > SysV initスクリプトの方はシステムグローバルな管理をするため、/var/runにPIDファイルを置いています。 > この/var/runに置かれたPIDファイルには文字通り「PID」の情報のみが入っており、ディストリ標準のPID確認関数を使用して > 状態の確認が可能になります。 > 元々のデータベースクラスタに生成されたPIDファイルにはポートやbindされたアドレス等の情報が含まれています。 > > RAはあえてこの「PIDだけを取り出してファイルに書き出す」ということをしていないだけだと思われますので、特別に > RAとserviceとを「区別する」という意図はそこには無いはずです。 > > >> また、その場合postgresqlが起動しているか否かを確認する方法としては、リソースが起動しているか >> 否か(crm resource show postgresqlコマンドで確認)という認識でよろしいでしょうか。 > > さて、PostgreSQLのプロセスが起動しているかどうかを確認する方法ですが、Pacemaker側からですと仰るとおり > リソースの状態を見れば良いと思います。 > プロセスが起動していなければmonitorアクションに失敗するので、信用に足るものと考えられます。 > > もうひとつ、PostgreSQL側から直接確認することも可能です。pg_ctlを使って次のようにします(私の環境はCentOS6.5 > PostgreSQL9.3です)。 > > [root ＠ db1 /]# sudo -u postgres /usr/pgsql-9.3/bin/pg_ctl status -D > /var/lib/pgsql/9.3/data/ > pg_ctl: サーバが動作中です(PID: 27446) > /usr/pgsql-9.3/bin/postgres "-D" "/var/lib/pgsql/9.3/data" "-c" > "config_file=/var/lib/pgsql/9.3/data/postgresql.conf" > > やっていることは結局同じなのですが...別途監視することが目的でしたら後者が良いと思います。 > > 余談ですが、PostgreSQL9.3であれば、pg_isreadyというコマンドもあります。これは接続を受け入れ可能かどうかまで確認されます。 > > -- NTTデータ先端技術株式会社 中平 和友 TEL: 03-5860-5135 FAX: 03-5463-6490 Mail: nakahira_kazutomo_b1****@lab*****
Fork