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

レプリケーションを使用すると、ライブとバックアップサーバーのペアが同じデータディレクトリーを共有せず、すべてのデータ同期がネットワーク経由で行われます。したがって、ライブサーバーが受信したすべての (永続的な) データがバックアップに複製されます。

ライブサーバーが正常にシャットダウンされると、バックアップサーバーがアクティブになり、クライアントはバックアップにフェイルオーバーします。この動作は事前に決定し、データのレプリケーション使用時に設定することはできません。

バックアップサーバーは、最初にライブサーバーのすべての既存データを同期してから置き換える必要があります。したがって、共有ストレージとは異なり、複製バックアップは、起動直後に完全に機能する訳ではありません。同期にかかる時間は、同期されるデータ量とネットワーク速度によって異なります。また、バックアップが起動すると、クライアントは initial-replication-sync-timeout の間ブロックされることに注意してください。このタイムアウトが過ぎると、同期が完了しない場合でもクライアントのブロックが解除されます。

フェイルオーバーが成功すると、バックアップのジャーナルは、ライブサーバーのデータよりも新しいデータの保持を開始します。フェイルバックを実行し、再起動後にライブサーバーになるように元のライブサーバーを設定できます。フェイルバックは、ライブサーバーがオンラインに戻る前に、バックアップサーバーとライブサーバーの間でデータを同期します。

両方のサーバーがシャットダウンしている場合、管理者はどのサーバーのジャーナルに最新データがあるかを判断する必要があります。バックアップジャーナルに最新のデータがある場合は、そのジャーナルをライブサーバーにコピーします。最新データがない場合は、再度アクティブになるたびに、バックアップはライブサーバーから古いジャーナルデータを複製し、独自のジャーナルデータを削除します。ライブサーバーのデータが最新の場合、アクションは不要で、サーバーを正常に起動できます。

重要

レイテンシーが高く、データセンター間のネットワークが信頼できない可能性があるため、データセンター間の高可用性に複製ジャーナルの設定と使用は推奨されず、サポートされていません。

ライブとバックアップの複製ペアは、クラスターの一部である必要があります。cluster-connection 設定要素は、バックアップサーバーがライブ一致を見つける方法を定義します。

レプリケーションには、ネットワーク分離のリスクを軽減するには、少なくとも 3 つのライブ/バックアップペアが必要ですが、このリスクを排除することはできません。3 つ以上のライブ/バックアップのペアを使用する場合、クラスターはクォーラム voting を使用して 2 つのライブブローカーを使用しないようにすることができます。

cluster-connection を設定する場合は、以下の詳細を確認してください。

  • ライブサーバーとバックアップサーバーはいずれも同じクラスター内に含まれる必要があります。単純なライブ/バックアップ複製ペアでも、クラスター設定が必要になることに注意してください。
  • クラスターのユーザーとパスワードは、ペアの各サーバーで一致している必要があります。

<master> および <slave> 要素の両方に group-name 属性を設定して、ライブ/バックアップサーバーのペアを指定 し ます。バックアップサーバーは、同じ group-name を共有するライブサーバーにのみ接続します。

group-name を使用する例として、ライブサーバーと 3 つのバックアップサーバーがあるとします。ライブサーバーはそれぞれ独自のバックアップとペアする必要があるため、以下のグループ名を割り当てます。

  • live1 および backup1 は、pair1group-name を使用します。
  • live2 および backup2 は、pair2group-name を使用します。
  • live3 および backup3 は、pair3group-name を使用します。

上記の例では、サーバー backup1 は同じ group-namepair1 でライブサーバーを検索します。この場合は、サーバーは live1 です。

共有ストアの場合と同様に、ライブサーバーが停止またはクラッシュすると、複製するペアのバックアップがアクティブになり、その役割を引き継ぎます。特に、ライブサーバーへの接続が失われると、ペアのバックアップがアクティブになります。これは、一時的なネットワークの問題が原因でも発生することがあるため、問題となる可能性があります。この問題に対処するために、ペアのバックアップは、クラスター内の他のサーバーにまだ接続できるかどうかを判断しようとします。半分を超えるサーバーに接続できる場合、アクティブになります。ライブサーバーのほか、クラスター内の半分を超える他のサーバーとの通信が失われた場合、ペアのバックアップは待機し、ライブサーバーとの再接続を試みます。これにより、バックアップサーバーとライブサーバーの両方がメッセージを処理し、一方がそれに気付かない「スプリットブレイン」状況のリスクが軽減されます。

重要

これは、ライブサーバーが見つからず、ジャーナルのファイルロックが解放された場合にバックアップがアクティブになり、クライアント要求の処理を開始する共有ストアバックアップとの重要な違いです。また、レプリケーションでは、バックアップサーバーは、保持している可能性のあるデータが最新であるかどうかがわからないため、自動的にアクティブ化することを決定できないことに注意してください。保持しているデータを使用して複製バックアップサーバーをアクティブにするには、管理者はスレーブをマスターに変更することで、設定を変更してライブサーバーにする必要があります。

30.3.1. データのレプリケーションの設定

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

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

注記

以下の例は、standalone-full-ha 設定プロファイルを使用して JBoss EAP を実行していることを前提とします。

管理 CLI コマンドを使用して、データレプリケーションにライブサーバーを設定する

  1. ha-policy をライブサーバーに追加します

    /subsystem=messaging-activemq/server=default/ha-policy=replication-master:add(check-for-live-server=true,cluster-name=my-cluster,group-name=group1)

    check-for-live-server 属性は、指定された ID を持つ他のサーバーがクラスター内にないことを確認するようにライブサーバーに指示します。JBoss EAP 7.0 では、この属性のデフォルト値は false でした。JBoss EAP 7.1 以上では、デフォルト値は true です。

  2. ha-policy をバックアップサーバーに追加します

    /subsystem=messaging-activemq/server=default/ha-policy=replication-slave:add(cluster-name=my-cluster,group-name=group1)
  3. 共有された cluster-connection が存在することを確認します。

    ライブサーバーとバックアップサーバーの間の適切な通信には cluster-connection が必要です。以下の管理 CLI コマンドを使用して、同じ cluster-connection がライブサーバーとバックアップサーバーの両方に設定されていることを確認します。この例では、standalone-full-ha 設定プロファイルにあるデフォルトの cluster-connection を使用しています。ほとんどの場合、これで十分なはずです。クラスター接続の設定方法の詳細は、「クラスター接続の設定」を参照してください。

    以下の管理 CLI コマンドを使用して、ライブおよびバックアップサーバーの両方で同じ cluster-connection を使用していることを確認します。

    /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster:read-resource

    cluster-connection が存在する場合、出力は現在の設定を提供します。存在しない場合は、エラーメッセージが表示されます。

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