Jira Data Center のキャッシュ レプリケーション

Jira Data Center 7.9 以降でのキャッシュ レプリケーションは非同期で行われます。つまり、キャッシュ レプリケーションは、発生後すぐには他のノードにレプリケートされず、ローカル キューに追加されます。その後、キュー内での順序に基づいてバックグラウンドでレプリケートされます。 

このアプローチは、以下を実現できるようサポートします。

• クラスターの拡張性の向上
• ノード間でのキャッシュ量の不一致を軽減
• レプリケーションとキャッシュ変更を分け、プロセス全体を簡素化して迅速化

キャッシュ変更のレプリケーション

ローカル キュー

キャッシュ変更をキューに追加する前に、各ノードでローカル キューを作成する必要があります。変更が適切にグループ化され、順序化されるよう、各ノードには個別のキューが作成されます。

キューは自動的に作成されます。クラスターにノードを追加するたびに、残りのノードがそれを検出し、ファイル システム上にキューを作成します。ノードは次のクエリを使用して、クラスター全体についての情報をデータベースから取得します。

select node_id, node_state from clusternode

このクエリの出力は次のようになります (ポート番号や IP アドレスなどの詳細も含まれます)。

active 状態の各ノードに対し、それぞれのノードはファイル システム上に 10 個の個別キューを作成します。アトラシアンではスループットを増加させるために、キューの数を 10 としています。これは、多数のアクションを完了させる必要があるため、1 件の変更の複製を高速化することはできませんが、同時に 10 件の変更を複製できるためです。

Node 1、Node 2、および Node 3 の 3 ノード クラスターでは、次のキューが作成されます。

Node 1:

• 変更を Node 2 に複製する 10 個のキュー
• 変更を Node 3 に複製する 10 個のキュー

Node 2:

• 変更を Node 1 に複製する 10 個のキュー
• 変更を Node 3 に複製する 10 個のキュー

Node 3:

• 変更を Node 1 に複製する 10 個のキュー
• 変更を Node 2 に複製する 10 個のキュー

ファイル システムでの見え方

キューは、各ノードの <local-home-directory>/localq ディレクトリで作成されます。このディレクトリのコンテンツは次のようになります。

queue_Node2_0_f5f366263dcc357e2720042f33286f8f
..
queue_Node2_9_f5f366263dcc357e2720042f33286f8f
queue_Node3_0_bbb747b1516b5225f1ec1c65887b39fc
..
queue_Node3_9_bbb747b1516b5225f1ec1c65887b39fc 

キューが作成されると、キャッシュ変更をキューに追加する準備が整います。クラスターにノードを追加するたびに、このノード用にさらに 10 のキューが既存の各ノード上で作成されます。新しいノードは、すべてのアクティブな既存ノードのキューを作成します。

キャッシュ変更をローカル キューに追加する

すべてのキューが配置されると、特定のノードで発生する各キャッシュ イベントが適切なキューに追加されます。

例として、Node 1 を使用してみましょう。

Node 1:

1. キャッシュ イベントが発生します (権限スキームへの変更など)。
2. 変更はデータベース内で行われ、この変更に関するローカル キャッシュは削除されます。
3. キャッシュを削除するリクエストが次のローカル キューに追加され、そこから適切なノードにレプリケートされます。
   • queue_Node2 (Node 2 の場合)
   • queue_Node3 (Node 3 の場合)。

1 つのスレッド内で発生した変更は、常に同じキューに追加されます。これは、1 つのスレッド内の 2 つのイベントが互いに依存している場合に、それらのレプリケーション順序を維持するためです。

キャッシュ変更をローカル ノードから他のノードにレプリケートする

キャッシュの変更がローカル キューに追加されると、それらは別のスレッドによって処理されます。各キューには、次の処理を行うスレッド 1 つあります。

• キューからキャッシュ変更リクエストを読み込む。
• RMI を介して、キャッシュ変更リクエストを宛先ノードに配信する。
• キューからキャッシュ変更リクエストを削除する。

Node 1 の queue_Node2 および queue_Node3 にキャッシュ変更が追加された同じ例を使用すると、この変更での以降の手順は次のようになります。

• キューに追加された変更を処理するスレッドは、ローカル キュー queue_Node2 から変更を読み込み、RMI を介して Node 2 に配信しようとします。
• キューに追加された変更を処理する別のスレッドは、ローカル キュー queue_Node3 から変更を読み込み、RMI を介して Node 3 に配信しようとします。

変更が正常にレプリケートされると、そのキューから削除されます。レプリケーションに失敗すると、ログにエラーが書き込まれます。

キャッシュ レプリケーションの監視

ログ ファイルに書き込まれた統計のレビューを行うことで、キャッシュ レプリケーションを監視できます。ログ ファイルでは、ローカル キューのサイズ、キャッシュ変更が正常にレプリケートされたかどうか、またはキュー内に長時間残っているかどうかなどを確認できます。ほとんどの場合、いくつかのパラメーターを監視するだけで、レプリケーションが正常に動作しているかどうかがわかります。

詳細については、「キャッシュ レプリケーションの監視」を参照して下さい。

キャッシュ レプリケーションの構成

キャッシュ レプリケーションでは、キュー内の変更の最大数や、統計の保存頻度など、いくつかのオプションを設定できます。

これらはシステム プロパティであることにご注意ください。 

詳細情報

キャッシュ レプリケーションについて詳しく理解するには、以下のセクションを展開してください。

Not enough space left for persisting localQCacheOp, usableSpaceInBytes: {}, estimateObjectSizeInBytes: {}. Skipping replication of this cache event.

Checked exception: {exception name} occurred when processing: {cache replication request} from cache replication queue: {queue name}, failuresCount: {}. Will retry indefinitely.

Runtime exception: {exception-name} occurred when processing: {cache-replication-message} from cache replication queue: {queue-name}, failuresCount: {}/{}, error: {exception}

Abandoning sending: {cache-replication-message} from cache replication queue: {queue-name}, failuresCount: {}/{}. Removing from queue. Error: {exception}"

Cache {cache-name} requested bootstrap but a CacheException occured.

java.rmi.ConnectIOException: Exception creating connection to: {destination_hostname}