Data Center クラスタのスプリットブレイン状態から回復する

お困りですか?

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

コミュニティに質問

この記事は Confluence Data Center 5.8.5 以降に適用されます。

症状

Confluence Data Center node will not start up and you see the following message in the Confluence logs (<confluence-home>/logs/atlassian-confluence.log):

2014-08-15 15:23:00,023 ERROR [scheduler_Worker-6] [confluence.cluster.safety.ClusterPanicListener] onClusterPanicEvent Received a panic event, stopping processing on the node: Clustered Confluence: Database is being updated by an instance which is not part of the current cluster. You should check network connections between cluster nodes, especially multicast traffic.
2014-08-15 15:23:00,035 WARN [scheduler_Worker-6] [confluence.cluster.safety.ClusterPanicListener] onClusterPanicEvent  com.atlassian.confluence.cluster.hazelcast.HazelcastClusterInformation@29f82619
2014-08-15 15:23:00,036 WARN [scheduler_Worker-6] [confluence.cluster.safety.ClusterPanicListener] onClusterPanicEvent Shutting down Quartz scheduler

これは既知のクラスタのスプリットブレイン状態 (クラスタ パニックとも呼ばれます) であり、あらゆるノードで起こりえます (たとえば 1 つのノードを再起動したときに、同じノードまたは別のノードで上記のクラスタのスプリットブレインのメッセージが表示されることがあります)。 

背景

クラスタの安全性を保つためのメカニズムは、1 人のユーザーによる更新がほかのユーザーに表示されないことで Confluence の一貫性が失われてしまうことのないように設計されています。このメカニズムの失敗は Confluence における致命的なエラーであり、クラスタのスプリットブレインと呼ばれます。クラスタの安全性を保つためのメカニズムは、Confluence の任意の 2 つのコピーが同じデータベースに接続しているときにデータの一貫性を保つことを支援します。このため、Confluence Data Center だけでなくすべての Confluence インスタンスで有効化されています。

クラスタの安全性を保つためのメカニズムの仕組み...

スケジュール済みタスクである ClusterSafetyJob が 30 秒ごとに実行されます。クラスタでは、このジョブはいずれかのノードでのみ実行されます。このスケジュール済みのタスクは、クラスタ内のデータベースと分散キャッシュの両方に保持されるランダムに生成された番号である、セーフティ番号を使用して実行されます。次の処理を行います。

  1. 新しいランダムな番号を生成します。
  2. データベースとキャッシュの両方に既存のセーフティ番号がある場合、既存のセーフティ番号を比較します。
  3. 数字が異なる場合、ClusterPanicEvent を発行します。Confluence では現在、これが起こると、クラスタの各ノードに次のような影響があります。
    • アプリケーションへのすべてのアクセスの無効化
    • すべてのスケジュール済みタスクの無効化
    • Confluence 5.5 以前の場合、データベースのセーフティ番号を新しい値に更新。これにより、データベースにアクセスするすべてのノードが失敗します。Confluence 5.6 以降の場合、データベースのセーフティ番号は更新されないため、他の Confluence ノードは引き続きリクエストを処理できます。
  4. 番号が同じか、未設定の場合、セーフティ番号を更新します。
    • データベースのセーフティ番号を新しいランダムな数字に更新
    • キャッシュのセーフティ番号を新しいランダムな数字に設定

診断

Cluster split-brain can have a number of causes.

If confluence.cluster.join.type is set to multicast you should:

  1. Check that the network connectivity for multicast traffic is working between the nodes.
  2. Check that the same multicast address is being used by all the nodes.
    To determine the multicast address being used by a node, look in the Confluence logs (<confluence-home>/logs/atlassian-confluence.log) for the string Configuring Hazelcast with. For example:

    2014-08-15 15:20:08,140 INFO [RMI TCP Connection(4)-127.0.0.1] [confluence.cluster.hazelcast.HazelcastClusterManager] 
    configure Configuring Hazelcast with instanceName [nutella-buster], multicast address 238.150.128.250:54327, multicast 
    TTL [1], network interfaces [fe80:0:0:0:0:0:0:1%1, 0:0:0:0:0:0:0:1, 127.0.0.1] and local port 580

If confluence.cluster.join.type is set to tcp_ip you should:

  1. Check that all the nodes of the cluster can reach each other on hazelcast port (default 5801) with one of the below command:

    telnet <cluster.node.ip.address> 5801
    nc <cluster.node.ip.address> 5801
    curl <cluster.node.ip.address>:5801
    nmap <cluster.node.ip.address> -p 5081

ソリューション

クラスタのスプリットブレインから回復するには、次のことを行います。

  1. ネットワーク接続が適切な状態であることを確認します。 
    1. Double check parameter confluence.cluster.peers (for tcp_ip node discovery) that all the IPs are listed and confluence.cluster.address (for multicast node discovery) that the same multicast address is being used by all the nodes in confleunce.cfg.xml 
    2. Double check parameter confluence.cluster.join.type  in confleunce.cfg.xml for all the nodes as its the same
  2. パニック状態に陥ったノードを 1 つずつ再起動し、それぞれがクラスタに再ジョインしたことを確認してから (> [全般設定] > [クラスタリング] に移動) してから次のノードを開始します。

最終更新日: 2022 年 12 月 30 日

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

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