postgresql 9.1.2(同期レプリケーション) + pacemaker + corosync ではまりました。
環境は CentOS 6.2, pacemaker-1.1.6(CentOS付属), corosync-1.4.1(CentOS付属), postgresql91-server-9.1.2(PGDG) + PostgreSQL 9.1 ストリーミングレプリケーション対応 リソースエージェントです。
わかりやすくpg01が最初のprimary、pg02が最初のsecondaryとします。
- pg01のcorosyncを落とす
- pg02がprimaryに昇格(これはOK)
- pg01のcorosyncを起動するとpostgresqlの起動に失敗する
この直後にはこんなログ。
LOG: parameter "synchronous_standby_names" changed to "pg02"
LOG: standby "pg02" is now the synchronous standby with priority 1
LOG: received fast shutdown request
LOG: aborting any active transactions
LOG: autovacuum launcher shutting down
LOG: shutting down
LOG: database system is shut down
pg02がprimaryなのに何ぬかしてんだボケという感じ？
RA側の動作では/var/lib/pgsql/rep_mode.confにsecondary側の場合は自分がsecondaryと書かれるんだけど、どうも切り替え直後は上手く動かないみたい。
なので、corosync+pacemakerをごまかしてしまう。
こんな感じでやりました。
- pg01のcorosyncを起動しながらpg_ctl -D data start でスタートさせる
- (ログ見ながら)レプリケーションが終わったらpg_ctl -D data stop で停止させる
- pg01のcorosyncを再起動する
- もう一度 pg_ctl -D data start でスタートさせる
- (ログ見ながら)レプリケーションが終わったらpg_ctl -D data stop で停止させる
- pg01のcorosyncを再起動する
これでrep_mode.confに正しい情報が書かれ、ちゃんとSlavesとしても認識してくれます。
これはcrm_mon -A で監視しながら作業するとわかるのですが、pg_ctl -D start で起動させると、corosync+pacemaker側からのpostgresqlの起動には失敗しているのに関わらずHS:syncというステータスを出してくれる。つまり、ちゃんと監視はしているんです。ただ、Failした状態には変わらなく、pg01はSlavesとしては認識してくれないので再起動を繰り返して正しく認識させるとこまで持っていくという感じです。
しかし、コマンドラインが充実してるとトラブルシューティングが楽になりましたね。heartbeat2時代に比べてコンフィグのぶち込み方が異常に楽になってるのでいろいろ試せてとても良いですね>pacemaker
