読者です 読者をやめる 読者になる 読者になる

smellman's Broken Diary

クソみたいなもんです

postgresql(同期レプリケーション)+pacemaker+corosyncでsecondaryが復帰しない状態の簡単な対処方法

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とします。

  1. pg01のcorosyncを落とす
  2. pg02がprimaryに昇格(これはOK)
  3. 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をごまかしてしまう。
こんな感じでやりました。

  1. pg01のcorosyncを起動しながらpg_ctl -D data start でスタートさせる
  2. (ログ見ながら)レプリケーションが終わったらpg_ctl -D data stop で停止させる
  3. pg01のcorosyncを再起動する
  4. もう一度 pg_ctl -D data start でスタートさせる
  5. (ログ見ながら)レプリケーションが終わったらpg_ctl -D data stop で停止させる
  6. pg01のcorosyncを再起動する

これでrep_mode.confに正しい情報が書かれ、ちゃんとSlavesとしても認識してくれます。
これはcrm_mon -A で監視しながら作業するとわかるのですが、pg_ctl -D start で起動させると、corosync+pacemaker側からのpostgresqlの起動には失敗しているのに関わらずHS:syncというステータスを出してくれる。つまり、ちゃんと監視はしているんです。ただ、Failした状態には変わらなく、pg01はSlavesとしては認識してくれないので再起動を繰り返して正しく認識させるとこまで持っていくという感じです。
しかし、コマンドラインが充実してるとトラブルシューティングが楽になりましたね。heartbeat2時代に比べてコンフィグのぶち込み方が異常に楽になってるのでいろいろ試せてとても良いですね>pacemaker