kompiraの冗長機能使用時のエラーについて

コメント

3件のコメント

  • 正式なコメント
    Ichiro Takahashi

    フィックスポイントの高橋です。

    再起動される以前に、冗長構成は適切に構築されて、アクティブ状態およびスタンバイ状態のサーバが正常に動作していたものとして回答いたします。

    冗長構成においてアクティブ状態であったサーバが再起動すると、その時点でフェイルオーバーしてそれまでスタンバイ状態であったサーバがアクティブ状態になります。再起動したサーバは(故障とみなされており)自動的にはクラスタに参加せずに、片系で動作している状態になります。

    再起動したサーバで以下コマンドを実行することで、現アクティブのサーバとデータベースを同期してクラスタへの参加と冗長構成の回復を試みます。

    /opt/kompira/bin/sync_master.sh

    問題なくデータベースの同期とクラスタへの参加が成功すると、再起動したサーバはスタンバイ状態で動作しているはずです。

    オンラインドキュメント「1.管理ガイド」の「1.8.4. フェイルオーバー時の動作とフェイルバック」にも、簡単な説明がございますのでご確認ください。

    コメントアクション Permalink
  • 井上雄一

    kompiraにて待機系をリブートすると必ずdbのlockファイルが出来て、上記
    /opt/kompira/bin/sync_master.sh
    を入力しないと冗長状態に復帰しないように見えます。
    そのような仕様でしょうか?

    0
    コメントアクション Permalink
  • Ichiro Takahashi

    フィックスポイントの高橋です。

    基本的には待機系のリブート時に同期を回復させるためには sync_master.sh を実行してください、とご案内しておりますが、「リブートすると必ず lock ファイルができる」というのは Kompira 自体の仕様としてはございません。Postgresql がそのときどきの状況によってレプリケーションを再開できたり、lock ファイルがあれば起動を失敗する、といった振る舞いをします。

    たとえば、フェイルオーバーが発生してたときに lock が生成されたりしますが、これが残ったまま(sync_master を実施していない)の状態ですと、待機系の Postgresql は起動失敗します。

    一方で、手元の kompira v1.5.5.post8 の冗長構成で簡単に確認したところ、同期できている待機系を単純にリブートした場合は、そのまま sync_master.sh せずとも起動に成功しています。

    ただし、ご利用状態によっては待機系をリブートしたときに、レプリケーションの再開に失敗する可能性もあるかと思いますので、基本的にはリブート時(あるいは再起動後に同期が取れていない時)は sync_master.sh を実行するようにしていただくのがよいかと思います。

    0
    コメントアクション Permalink

サインインしてコメントを残してください。