現象

スレーブインスタンスの開始のエラーは、次のような様々なシナリオで表示されます。

a) コールドバックアップでスレーブノードを停止し、バックアップを開始します
b) メンテナンス操作でクラスターを停止し、クラスターノードを開始します

 

原因

1) インフラストラクチャ側でのネットワークの問題 - スレーブに「マスタータイムアウトからの読み取り」状況が発生しています

On Master:
com.day.crx.core.cluster.ClusterMaster I/O error while processing connect. java.net.SocketTimeoutException: Read timed out
On Slave:
com.day.crx.core.cluster.ClusterMaster I/O error while processing connect. java.net.SocketTimeoutException: Read timed out

解決策:ネットワークインフラストラクチャを確認し、マスターとスレーブノードが互いに通信できるか検証するためにファイアウォールの変更または障害がないことを確認してください。

 

2) クラスターノードの停止の開始に続く不正なシーケンス - これにより、「非同期」状況が発生しています

* ClusterTarSet: Could not open (ClusterTarSet.java, line 820)
java.io.IOException: This cluster node and the master are out of sync. Operation stopped.
Please ensure the repository is configured correctly.
To continue anyway, please delete the index and data tar files on this cluster node and restart.
Please note the Lucene index may still be out of sync unless it is also deleted

非同期クラスターノードの分析および考えられる理由

クラスターノードの一連のシャットダウンと再起動の順序が不適切なために、この状況が発生します。マスターインスタンスが配置されていたサーバーが定期的なメンテナンスの一部として停止し、スレーブが新しいマスターとして引き継ぎ、許可された場合は、スタンドアロンとして実行します。後にスレーブがシャットダウンし、マスターインスタンスが開始されたとき、スレーブは参加を拒否し、ノードが非同期になりました。これは、スレーブに新しいリビジョンがあると予想されます。 

 

解決策: 

a) 古いスレーブノードを新しいマスターとして実行させます。

b) 古いマスターを開始し、現在のスレーブとして参加させます。

c) 古いマスター [現在のスレーブ] が古いスレーブ [新しいマスター] に接続し、それ自身を最新のリビジョンで同期することを許可します。 

d) 同期が完了したら、現在のマスター [古いスレーブ] ノードを停止して再起動するだけで、マスターおよびスレーブノードの役割を切り替えることができます。

e) 現在のマスター [古いスレーブ] が停止すると、現在のスレーブ [古いマスター] がマスターの役割に戻ります。

 

3) 停止したクラスターノードのマーカーファイル Clustered.txt の手動削除 - これにより、スレーブノードとして開始し、既存のマスターを参加させることを前提としている際、インスタンスがマスターノードとして開始します

非同期クラスターノードの分析および考えられる理由

実行中のマスターインスタンスの予期しない状況ややむを得ないシャットダウンを実行した場合、マスターインスタンスは再起動後にクラスターを再び参加させることができません。これは、マスターノードが停止した時点での書き込み処理が進行中であった場合や、マスターインスタンスが停止する前に書き込み操作が数秒発生した場合に発生する可能性があります。このような場合、スレーブインスタンスはマスターインスタンスからすべての変更を受け取ることはできません。マスターが再起動されると、CRX は残りのクラスターインスタンスと同期していないことを検出し、リポジトリは起動しません。

clustered.txt ファイルを手動で削除して、マスタークラスターノードを起動しようとした可能性があります。通常、clustered.txt はインスタンスを起動するときはいつも削除しないでください。これは、このインスタンスが次回の起動時にスレーブとして参加する必要があることを通知するマーカーファイルです。最後に停止したクラスターノードには、clustered.txt ファイルがありません。これは、このノードが最後に実行しているマスターノードであったことを識別するために役立ち、最初に起動する必要があります。

このファイルが存在する場合、ノードをマスターノードとして起動することはできません。以下のようなメッセージが表示されます。

説明:

ノードが最新のリビジョンとコンテンツを持つように、このノードが停止した後も、別のクラスターノードが実行されたことを意味します。したがって、クラスター内で最後に停止しているノードは、クラスターノードを起動するたびにマスターノードになります。

 

ClusterController: Trying to connect to a master, as the file clustered.txt exists.

注意:

インスタンスを起動するには、clustered.txt をいつも削除する必要はありません。これは、インスタンスをスタンドアロンとして起動し、クラスターの一部にしない場合にのみ実行する必要があります。

解決策:

a) この非同期の例外をスローしたスレーブノードを停止します

b)(clustered.txt ファイルを削除して起動した)現在実行中のマスターノードを停止します

c) スレーブノードを起動します(この場合は、最新のリビジョンがあるため最後に実行しているマスターです)。これは新しいマスターとして引き継ぎます

d) スレーブとしてクラスターに参加するマスターノードを起動します

e) 同期が完了すると、現在実行中のマスターノード(古いスレーブ)を停止して起動し、マスターとして動作しているマスターとスレーブとして動作しているスレーブのロールの一貫性を戻すことができます。

注意:

 

a) 非同期の状況について詳しくは、当社のドキュメントリンクを参照してください

b) スレーブのクローンを作成する手順について詳しくは、当社のドキュメントリンクを参照してください

 

スレーブを作成するためにマスターをクローンする場合は注意してください

やむを得ないシャットダウン/ハード再起動/ネットワークの問題/停電などが原因です。いずれのクラスターノードの場合でも、クラスターノードが互いに同期していない場合に非同期の問題が発生した場合は、復元手順として、古いバックアップから復元するか、クラスターノードを再作成する必要があります。

このようなシナリオでは、クラスターノードのクローンを作成し、新しいスレーブとしてクラスターに参加させる必要があります。したがって、最後に実行しているマスターノードであったノードが最新のコンテンツとリビジョンを持っているノードであることを識別する必要があります。次に、そのノードでバックアップを実行し、スレーブを作成することのみ必要があります。

注意:

(古いマスターが最初に停止している)間違ったノードをクローンしようとすると、最後に実行しているノードに存在するデータが失われる可能性が高くなります。そのため、クローンするノードを選択するときに、正しいものを識別します。

注意:

この記事は、CRX バージョン 2.x(2.2.0.36以上)のみを持つすべての CQ 5.x のバージョンに適用されます。

本作品は Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License によってライセンス許可を受けています。  Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。

法律上の注意   |   プライバシーポリシー