データセンター クラスタ停止のトラブルシューティング

Data Center のトラブルシューティング

このページの内容

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

複雑な環境や、詳細なログにより、Confluence Data Center クラスター停止のトラブルシューティングは難しい場合があります。

このページは、クラスター内の停止を調査するための開始点を提供します。 

発信元ノードを確立する

最も一般的な停止のシナリオは、データベース接続の問題、ネットワーク停止や、ガベージ コレクション (GC) プロセスに時間がかかるなどの原因で、ノードが 30 秒以上クラスターと通信できなくなり、Hazelcast によって削除されるというケースです。その後、影響を受けるノードはデータベースへの書き込みを継続するため、クラスター パニックが発生します。

このページの内容:

発信元ノードを確立するには:

  1. Gather the atlassian-confluence.log files from each node as soon as possible after the outage. Time is critical as the logs will roll over and you may lose the relevant time period.
  2. 各ノードの ID 情報を記録して、ログ メッセージの解釈に役立てます (各ノードの IP アドレス、ノード ID および名前)。

  3. イベントの時系列タイムラインを作成します。

    1. ユーザーや監視システムが問題の報告を開始した時刻を記録します。
    2. 各ノードのログを横に並べて確認します (ヒント: 3 つのタブをノード番号順に開くと、閲覧中のログがどれか常にわかりやすくなります)。
    3. Search the logs for 'removing member' and 'panic'. This will give you a good idea of which nodes caused the issue and when. 
    4. ノード削除のエラーからパニックまでの、イベントの時系列タイムラインを作成します。パニック後に発生したすべてのログ作成は基本的に無視することができます。これは、ノード パニックが発生したら、効果的に機能させるためにログ作成を再起動させる必要があるためです。ログには多数のノイズが発生しますが、あまり役には立ちません。最も重要な期間は、ログ内の最初の削除またはパニック イベントにつながる 1 分程度の時間です。

      例:

      2:50:15 (approx) Node 3 stopped heartbeating to the cluster for 30s 
      (we can estimate this from the time of node removal)
      02:50:45 Node 3 was removed by Node 2
      02:53:15 Node 4 panics
      02:54:15 Node 1, Node 3 and Node 4 receive the panic event and stop processing
      Node 2 remains serving requests
    5. 最初に影響を受けたノードがいつ削除されたか、または最初のクラスター パニックがいつ発生したかを確立するしたら、そのノードのログを振り返って根本原因を探してください。

共通の根本原因の調査

最初に影響を受けたノードが削除されたタイミングがわかったら、根本原因の調査を開始することができます。ここから、削除した時点前後の影響されたノードのイベントのみを調べることができます (この例では、ノード 3、2:50 頃になります)。その後の削除とパニックは通常、元のノードの削除イベントの流れで発生する効果であり、これらから有用な根本原因情報を得ることはできません。 

ガベージ コレクション

削除されたノードの GC ノード (この例ではノード 3) を確認します。Hazelcast ハートビート間隔 (デフォルトでは 30 ) より長い時間一時停止した GC はありましたか?ノードは、ガベージ コレクション中にハートビートを行うことはできません。そのため、他のいずれかのノードによってクラスターから削除されます。

クラスター パニックが発生し、最初にクラスターからノードを削除しなかった場合、パニック発生時付近の GC ログを確認してください。Confluence 5.10.1 以前では、比較的短時間 (30 秒未満) によっても、(レース状態によりにより) パニックが発生することがあります。

データベース接続

お持ちのデータベース監視ツールをご覧ください。停電時、データベース接続はいくつありましたか?ノードが接続プールから接続を取得できても、データベース自体から取得できない場合、ハートビートが失敗し、ノードがクラスターから削除される可能性があります。

Confluence ログからこれを診断することはできません。データベース用の外部監視ツールを確認する必要があります。再び停止が発生したばあい、停止中に、同時接続数を db レベルでチェックしてください。

ネットワーク接続

ネットワーク監視ツールを確認します。ノードが短時間の間ネットワークを切断し、クラスターと通信できない場合、他のノードによって削除されている可能性があります。ここでは、ロード バランサー ログが便利です。

まだ問題が解決しませんか。

サポートに問い合わせ、これらの停止のトラブルシューティングに対するサポートを受けます。調査に役立つよう、できるだけ多くの情報を提供してください。

最終更新日 2016 年 8 月 18 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.