30.3. データのレプリケーション

以下の 2 つの例は、my-cluster という名前のクラスターと group1 という名前のバックアップグループに存在するライブサーバーとバックアップサーバーの両方の基本設定を示しています。

以下の手順では、管理 CLI を使用して my-cluster という名前のクラスターと group1 という名前のバックアップグループに存在するライブサーバーとバックアップサーバーの両方の基本設定を提供します。

すべての設定属性の詳細は、すべてのレプリケーション設定 を参照してください。

管理 CLI を使用して、追加された後、ポリシーに設定を追加できます。これを実行するコマンドは、以下の基本構文に従います。

/subsystem=messaging-activemq/server=default/ha-policy=POLICY:write-attribute(name=ATTRIBUTE,value=VALUE)

/subsystem=messaging-activemq/server=default/ha-policy=POLICY:write-attribute(name=ATTRIBUTE,value=VALUE)

たとえば、restart-backup 属性の値を true に設定するには、以下のコマンドを使用します。

/subsystem=messaging-activemq/server=default/ha-policy=replication-slave:write-attribute(name=restart-backup,value=true)

/subsystem=messaging-activemq/server=default/ha-policy=replication-slave:write-attribute(name=restart-backup,value=true)

以下の表は、replication-master ノードと replication-slave 設定要素の HA 設定属性を示しています。

ライブとバックアップのペアはそれぞれ cluster-connection を使用して通信します。cluster-connection の call-timeout 属性は、クラスターの別のサーバーへの呼び出し後にサーバーが応答を待機する時間を設定します。call-timeout のデフォルト値は 30 秒で、ほとんどの場合、これで十分です。ただし、バックアップサーバーが、ライブサーバーから送信されるレプリケーションパケットを処理できない状況があります。これは、たとえば、ディスク操作が遅いため、または journal-min-files の値が大きいために、ジャーナルファイルの最初の事前作成に時間がかかりすぎる場合に発生することがあります。このようなタイムアウトが発生すると、ログに次のような行が表示されます。

AMQ222207: The backup server is not responding promptly introducing latency beyond the limit. Replication server being disconnected now.

AMQ222207: The backup server is not responding promptly introducing latency beyond the limit. Replication server being disconnected now.

クラスター接続のタイムアウトを防ぐには、以下のオプションを考慮してください。

バックアップサーバーは、ライブサーバーとの同期を開始すると、ジャーナルを新しい場所に移動します。デフォルトでは、ジャーナルディレクトリーは EAP_HOME/standalone の data/activemq ディレクトリーに置かれます。ドメインの場合、各サーバーは EAP_HOME/domain/servers の下に独自の serverX/data/activemq ディレクトリーを持っています。ディレクトリーの名前は、bindings、journal、largemessages、paging です。これらのディレクトリーの詳細は、永続性の設定 と ページングの設定 を参照してください。

移動すると、新しいディレクトリーの名前が oldreplica.X に変更されます。X は数字の接尾辞です。新しいフェイルオーバーにより別の同期が開始されると、moved ディレクトリーの接尾辞が 1 増えます。たとえば、最初の同期では、ジャーナルディレクトリーは oldreplica.1 に移動され、2 回目は oldreplica.2、といったように移動されます。元のディレクトリーは、ライブサーバーから同期したデータを保存します。

デフォルトでは、バックアップサーバーは、フェイルオーバーとフェイルバックの 2 つの発生を管理するように設定されています。その後、クリーンアッププロセスがトリガーされ、oldreplica.X ディレクトリーが削除されます。バックアップサーバーの max-saved-replicated-journal-size 属性を使用して、クリーンアッププロセスをトリガーするフェイルオーバーの発生回数を変更できます。

ライブサーバーとバックアップサーバーが専用のトポロジーにデプロイされ、そこで各サーバーが JBoss EAP の独自のインスタンスで実行されている場合は、以下の手順に従ってクラスターのスムーズな更新と再起動を行ってください。

スプリットブレイン状態は、ライブサーバーとそのバックアップの両方が同時にアクティブなときに発生します。両方のサーバーがクライアントおよびプロセスメッセージを処理し、一方はそれに気付きません。この場合、ライブサーバーとバックアップサーバーの間でメッセージのレプリケーションは行われなくなります。2 つのサーバー間でネットワーク障害が発生すると、スプリット状況が発生する可能性があります。

たとえば、ライブサーバーとネットワークルーター間の接続が切断されると、バックアップサーバーはライブサーバーへの接続を失います。ただし、バックアップはクラスター内の半分以上のサーバーに引き続き接続できるため、アクティブになります。ライブ/バックアップのペアが 1 つのみで、バックアップサーバーがライブサーバーへの接続を失った場合にも、バックアップがアクティブになることに注意してください。両方のサーバーがクラスター内でアクティブな場合、2 つの望ましくない状況が発生する可能性があります。

お客様は、ライブサーバーとバックアップサーバーの各ペア間に信頼できるネットワークを実装して、データのレプリケーション使用時のスプリットブレイン処理のリスクを軽減する必要があります。たとえば、複製したネットワークインターフェイスカードや、その他のネットワーク冗長性を使用します。