kompiraの冗長機能使用時のエラーについて
kompiraにて冗長機能を設定時にprimaryを再起動した際、再起動してきたprimaryが
冗長状態にて組み込めません。
crm_mon -A1
にて確認すると以下のようなログが出て、DBのlockファイルが残っていて
DBが起動できずに止まっているように見えます。
---
Failed Resource Actions:
* res_pgsql_start_0 on ha-kompira1 'unknown error' (1): call=32, status=complete, exitreason='My data may be inconsistent. You have to remove /var/lib/pgsql/9.6/tmp/PGSQL.lock file to force start.',
last-rc-change='Wed Aug 5 03:31:20 2020', queued=0ms, exec=323ms
---
この事象は想定通りの動作でしょうか?
どのように解決すればよろしいのでしょうか?
-
正式なコメント
フィックスポイントの高橋です。
再起動される以前に、冗長構成は適切に構築されて、アクティブ状態およびスタンバイ状態のサーバが正常に動作していたものとして回答いたします。
冗長構成においてアクティブ状態であったサーバが再起動すると、その時点でフェイルオーバーしてそれまでスタンバイ状態であったサーバがアクティブ状態になります。再起動したサーバは（故障とみなされており）自動的にはクラスタに参加せずに、片系で動作している状態になります。
再起動したサーバで以下コマンドを実行することで、現アクティブのサーバとデータベースを同期してクラスタへの参加と冗長構成の回復を試みます。
/opt/kompira/bin/sync_master.sh
問題なくデータベースの同期とクラスタへの参加が成功すると、再起動したサーバはスタンバイ状態で動作しているはずです。
オンラインドキュメント「1.管理ガイド」の「1.8.4. フェイルオーバー時の動作とフェイルバック」にも、簡単な説明がございますのでご確認ください。
コメントアクション -
フィックスポイントの高橋です。
基本的には待機系のリブート時に同期を回復させるためには sync_master.sh を実行してください、とご案内しておりますが、「リブートすると必ず lock ファイルができる」というのは Kompira 自体の仕様としてはございません。Postgresql がそのときどきの状況によってレプリケーションを再開できたり、lock ファイルがあれば起動を失敗する、といった振る舞いをします。
たとえば、フェイルオーバーが発生してたときに lock が生成されたりしますが、これが残ったまま（sync_master を実施していない）の状態ですと、待機系の Postgresql は起動失敗します。
一方で、手元の kompira v1.5.5.post8 の冗長構成で簡単に確認したところ、同期できている待機系を単純にリブートした場合は、そのまま sync_master.sh せずとも起動に成功しています。
ただし、ご利用状態によっては待機系をリブートしたときに、レプリケーションの再開に失敗する可能性もあるかと思いますので、基本的にはリブート時（あるいは再起動後に同期が取れていない時）は sync_master.sh を実行するようにしていただくのがよいかと思います。
サインインしてコメントを残してください。
コメント
3件のコメント