ユーザー管理インデックスレプリケーション

ユーザー管理インデックスレプリケーションは、リーダーインデックスの完全なコピーを1つまたは複数のフォロワーレプリカに配布します。リーダーはインデックスの更新を管理し続けます。すべてのクエリはフォロワーによって処理されます。この役割分担により、Solr は大規模な検索量に対するクエリに適切に対応できるようにスケールできます。

下の図は、インデックスレプリケーションを使用する Solr 構成を示しています。リーダサーバのインデックスがフォロワーに複製されます。

user managed replication
図 1. Solr インデックスは複数のフォロワーサーバーに複製でき、それらのサーバーがリクエストを処理します。

Solr でのインデックスレプリケーション

Solr には HTTP 経由で動作するインデックスレプリケーションが含まれています

  • レプリケーションに影響を与える構成は、単一のファイル solrconfig.xml によって制御されます。

  • インデックスファイルだけでなく、構成ファイルのレプリケーションもサポートします。

  • 同じ構成でプラットフォームをまたいで動作します。

  • OS 依存のファイルシステム機能（ハードリンクなど）に依存しません。

  • Solr と緊密に統合されており、管理ページではレプリケーションの各側面を細かく制御できます。

  • Java ベースのレプリケーション機能は、リクエストハンドラとして実装されています。したがって、レプリケーションの設定は、通常のリクエストハンドラの設定と似ています。

SolrCloud でのレプリケーション

SolrCloud クラスタには、リーダーノードまたはフォロワーノードという明示的な概念はありませんが、このページで説明する ReplicationHandler は、SolrCloud が「シャードリカバリ」をサポートするために必要に応じて使用されます。ただし、これはピアツーピア方式で行われます。

SolrCloud を使用する場合、ReplicationHandler は /replication パスを介して利用可能である必要があります。Solr は、solrconfig.xml で明示的にオーバーライドしない限り、これを暗黙的に行います。デフォルトの動作をオーバーライドする場合は、以下に説明する「リーダー」または「フォロワー」の構成オプションを設定しないようにしてください。設定すると、通常の SolrCloud の動作が妨げられます。

ReplicationHandler の設定

以下に説明するリーダーとフォロワーの役割に特有のReplicationHandler構成オプションに加えて、一般的にサポートされるいくつかの特別な構成オプションがあります（SolrCloudを使用している場合でも）。

  • maxNumberOfBackups は、このノードがbackupコマンドを受信する際にディスクに保持するバックアップの最大数を指定する整数値です。

  • Solr の他のほとんどのリクエストハンドラーと同様に、defaults, invariants, および/または appends パラメータのセットを構成して、コマンドを処理する際に、ReplicationHandlerでサポートされる任意のリクエストパラメータに対応させることができます。

リーダーサーバーの設定

レプリケーションを実行する前に、ハンドラーの初期化時に以下のパラメータを設定する必要があります。

replicateAfter

オプション

デフォルト：なし

レプリケーションを発生させるアクションを指定する文字列。有効な値は以下のとおりです。

  • commit：リーダーインデックスでコミットが実行されるたびにレプリケーションをトリガーします。

  • optimize：リーダーインデックスが最適化されるたびにレプリケーションをトリガーします。

  • startup：リーダーインデックスが起動するたびにレプリケーションをトリガーします。

このパラメータには複数の値を指定できます。例：

+

<str name="replicateAfter">startup</str>
<str name="replicateAfter">commit</str>
<str name="replicateAfter">optimize</str>

+ startupを使用する場合は、今後のコミットや最適化でレプリケーションをトリガーしたい場合に、commitおよび/またはoptimizeのエントリも追加する必要があります。

backupAfter

オプション

デフォルト：なし

バックアップを発生させるアクションを指定する文字列。有効な値はcommit、optimize、またはstartupです。このパラメータには複数の値を指定できます。レプリケーションには必須ではありませんが、バックアップを作成します。

maxNumberOfBackups

オプション

デフォルト：なし

保持するバックアップの数を指定する整数。これを使用して、最新の*N*個のバックアップを除くすべてを削除できます。

confFiles

オプション

デフォルト：なし

フォロワーにレプリケートする設定ファイルをカンマで区切って指定します。これらは、スキーマ、ストップワード、およびリーダー上で変更され、クエリの処理時に使用するためにフォロワー上で更新する必要がある同様の設定ファイルである必要があります。

solrconfig.xmlをコピーする場合は、リーダーの設定がフォロワーの設定を上書きしないように特別な注意が必要です。次のような行は、ローカル設定solrconfig_follower.xmlがフォロワーでsolrconfig.xmlとして保存されることを保証します。

<str name="confFiles">solrconfig_follower.xml:solrconfig.xml,managed-schema.xml,stopwords.txt</str>

リーダーサーバーでは、フォロワー設定ファイルの名前は何でもかまいませんが、confFiles文字列で名前が正しく識別されている必要があります。次に、コロン ':' の後に表示されるファイル名で保存されます。上記の例では、他のすべてのファイルは元の名前で保存されます。

commitReserveDuration

オプション

デフォルト：00:00:10

コミットが非常に頻繁でネットワークが遅い場合は、このパラメータを調整して、データ転送に必要と予想される時間を増やすことができます。デフォルトは00:00:10、つまり10秒です。

以下の例は、ReplicationHandlerの可能な「リーダー」構成を示しています。これには、固定数のバックアップと、フォロワーがネットワークインターフェイスを飽和させないようにするためのmaxWriteMBPerSecリクエストパラメータの不変設定が含まれています。

<requestHandler name="/replication" class="solr.ReplicationHandler">
  <lst name="leader">
    <str name="replicateAfter">optimize</str>
    <str name="backupAfter">optimize</str>
    <str name="confFiles">schema.xml,stopwords.txt,elevate.xml</str>
  </lst>
  <int name="maxNumberOfBackups">2</int>
  <str name="commitReserveDuration">00:00:10</str>
  <lst name="invariants">
    <str name="maxWriteMBPerSec">16</str>
  </lst>
</requestHandler>

フォロワーサーバーの設定

フォロワーの設定は、このアプローチではフォロワーが更新されたインデックスおよびその他のファイルのリクエストをリーダーに開始するため、リーダーとは異なる必要があります。

以下のパラメータを使用します。

leaderUrl

オプション

デフォルト：なし

リーダーのレプリケーションハンドラーの完全修飾URL。

このパラメータは、リーダーから新しいインデックスファイルと設定ファイルをフェッチするために定義する必要がありますが、solrconfig.xmlで定義する必要はありません。fetchindexコマンドのリクエストパラメータとして渡すことができます。

pollInterval

オプション

デフォルト：なし

フォロワーがリーダーをポーリングする間隔。形式はHH:mm:ssです。これが指定されていない場合、フォロワーは自動的にポーリングしません。

構成されていない場合は、管理者UIまたはHTTP APIからfetchindexをトリガーできます。

compression

オプション

デフォルト：なし

インデックスファイルの転送中の圧縮を有効にします。可能な値はinternalまたはexternalです。値がexternalの場合は、リーダーのSolrにAccept-Encodingヘッダーを尊重するための設定があることを確認してください。これがinternalに設定されている場合は、すべてが自動的に処理されます。

このパラメータは一般的に使用すると便利に見えるかもしれませんが、リーダーノードとフォロワーノード間の帯域幅が一貫して低い場合にのみ必要になるのが通常です。

httpConnTimeout

オプション

デフォルト：5000

リーダーへの接続を待機する時間（ミリ秒単位）。帯域幅が極端に低い場合や、レイテンシが非常に高い場合を除き、通常はデフォルトのままにすることができます。

httpReadTimeout

オプション

デフォルト：10000

インデックスファイルの読み込みを待機する時間（ミリ秒単位）。httpConnTimeoutと同様に、帯域幅が極端に低い場合や、レイテンシが非常に高い場合を除き、通常はデフォルトのままにすることができます。

httpBasicAuthUser

オプション

デフォルト：なし

リーダーがHTTP Basic認証で構成されている場合に使用するユーザー名。

httpBasicAuthPassword

オプション

デフォルト：なし

リーダーがHTTP Basic認証で構成されている場合に使用するパスワード。

次の例は、フォロワーでのReplicationHandler構成を示しています。

<requestHandler name="/replication" class="solr.ReplicationHandler">
  <lst name="follower">
    <str name="leaderUrl">http://remote_host:port/solr/core_name/replication</str>
    <str name="pollInterval">00:00:20</str>

    <!-- THE FOLLOWING PARAMETERS ARE USUALLY NOT REQUIRED-->
    <str name="compression">internal</str>
    <str name="httpConnTimeout">5000</str>
    <str name="httpReadTimeout">10000</str>
    <str name="httpBasicAuthUser">username</str>
    <str name="httpBasicAuthPassword">password</str>
  </lst>
</requestHandler>

ReplicationHandlerを使用したリピーターの設定

リーダーは、パフォーマンスに影響を与えることなく、ごく少数のフォロワーしかサービスを提供できない場合があります。一部の組織では、複数のデータセンターにフォロワーサーバーをデプロイしています。各フォロワーがリモートデータセンターからインデックスをダウンロードすると、結果としてダウンロードが過剰なネットワーク帯域幅を消費する可能性があります。このような場合のパフォーマンス低下を回避するために、1つ以上のフォロワーをリピーターとして構成できます。リピーターは、リーダーとフォロワーの両方として機能するノードです。

サーバーをリピーターとして構成するには、solrconfig.xmlファイル内のレプリケーションrequestHandlerの定義に、リーダーとフォロワーの両方で使用するファイルリストを含める必要があります。

メインリーダーでreplicateAfterがoptimizeに設定されている場合でも、replicateAfterパラメータをcommitに設定してください。これは、リピーター（または任意のフォロワー）では、インデックスがダウンロードされた後にのみコミットが呼び出されるためです。フォロワーでoptimizeコマンドが呼び出されることはありません。

オプションで、compressionパラメータを使用して、リーダーから圧縮されたファイルをフェッチするようにリピーターを構成して、インデックスのダウンロード時間を短縮できます。

以下は、リピーターのReplicationHandler構成の例です。

<requestHandler name="/replication" class="solr.ReplicationHandler">
  <lst name="leader">
    <str name="replicateAfter">commit</str>
    <str name="confFiles">schema.xml,stopwords.txt,synonyms.txt</str>
  </lst>
  <lst name="follower">
    <str name="leaderUrl">http://leader.solr.company.com:8983/solr/core_name/replication</str>
    <str name="pollInterval">00:00:60</str>
  </lst>
</requestHandler>

レプリケーション画面

レプリケーション画面には、指定したコアの現在のレプリケーション状態が表示されます。

この画面は、SolrをSolrCloudモードで実行していない場合にのみ表示されます。

リーダー/フォロワーインデックスレプリケーションを使用している場合は、この画面を使用して以下を実行できます。

  1. レプリケーション可能なインデックスの状態を表示する（リーダーノードの場合）

  2. 現在のレプリケーションステータスを表示する（フォロワーノードの場合）

  3. レプリケーションを無効にする（リーダーノードの場合）

image

フォロワーレプリケーション

リーダーはフォロワーをまったく認識していません。

フォロワーは、（pollIntervalパラメータに応じて）リーダーの現在のインデックスバージョンを確認するために、リーダーを継続的にポーリングします。フォロワーがリーダーに新しいバージョンのインデックスがあることを検出すると、レプリケーションプロセスを開始します。

手順は次のとおりです。

  • フォロワーはfilelistコマンドを発行して、ファイルのリストを取得します。このコマンドは、ファイルの名前と、いくつかのメタデータ（サイズ、最終更新タイムスタンプ、エイリアスなど）を返します。

  • フォロワーは、ローカルインデックスにこれらのファイルがあるかどうかを確認します。次に、filecontentコマンドを実行して、欠落しているファイルをダウンロードします。これは、（HTTPチャンクエンコーディングのような）カスタム形式を使用して、ファイル全体または各ファイルの一部をダウンロードします。途中で接続が切断された場合、ダウンロードは失敗した場所から再開されます。どの時点でも、フォロワーはレプリケーションを完全に諦める前に5回試行します。

  • ファイルは一時ディレクトリにダウンロードされるため、ダウンロードプロセス中にフォロワーまたはリーダーがクラッシュした場合でも、ファイルが破損することはありません。代わりに、現在のレプリケーションは単に中止されます。

  • ダウンロードが完了すると、新しいファイルがライブインデックスディレクトリに移動され、ファイルのタイムスタンプはリーダー上の対応するファイルと同じになります。

  • フォロワーのReplicationHandlerによって、フォロワーでコミットコマンドが発行され、新しいインデックスがロードされます。

設定ファイルのレプリケーション

設定ファイルをレプリケートするには、confFilesパラメータでそれらを定義します。リーダーのSolrインスタンスのconfディレクトリにあるファイルのみがレプリケートされます。

Solrは、インデックス自体がレプリケートされた場合にのみ設定ファイルをレプリケートします。つまり、リーダーで設定ファイルが変更された場合でも、そのファイルはリーダーのインデックスで新しいコミットまたは最適化が行われた後にのみレプリケートされます。

タイムスタンプが同一かどうかを判断するのに十分なインデックスファイルとは異なり、設定ファイルはチェックサムと比較されます。スキーマファイル（リーダーとフォロワー）は、チェックサムが同一である場合に同一であると判断されます。

設定ファイルをレプリケートする際の予防策として、Solrは設定ファイルを一時ディレクトリにコピーしてから、confディレクトリの最終的な場所に移動します。古い設定ファイルは、同じconf/ディレクトリで名前が変更されて保持されます。ReplicationHandlerは、これらの古いファイルを自動的にクリーンアップしません。

レプリケーションに少なくとも1つの設定ファイルのダウンロードが含まれている場合、ReplicationHandlerはコミットコマンドの代わりにcore-reloadコマンドを発行します。

フォロワーサーバーでの破損問題の解決

ドキュメントがフォロワーに追加されると、フォロワーはリーダーと同期しなくなります。ただし、リーダーに新しいインデックスデータがあるまで、フォロワーは同期を維持するためのアクションを実行しません。

リーダーでコミット操作が行われると、リーダーのインデックスバージョンはフォロワーのインデックスバージョンとは異なります。フォロワーはファイルのリストをフェッチし、リーダーに存在するファイルの一部がローカルインデックスにも存在するが、サイズとタイムスタンプが異なることを検出します。これは、リーダーとフォロワーのインデックスに互換性がないことを意味します。

この問題を修正するために、フォロワーはリーダーからすべてのインデックスファイルを新しいインデックスディレクトリにコピーし、コアに新しいディレクトリから新しいインデックスをロードするように要求します。

ReplicationHandlerのHTTP APIコマンド

以下のHTTPコマンドを使用して、ReplicationHandlerの操作を制御できます。

enablereplication

すべてのフォロワーに対して、「リーダー」でのレプリケーションを有効にします。

http://_leader_host:port_/solr/_core_name_/replication?command=enablereplication
disablereplication

すべてのフォロワーに対して、リーダーでのレプリケーションを無効にします。

http://_leader_host:port_/solr/_core_name_/replication?command=disablereplication
indexversion

指定されたリーダーまたはフォロワーの最新のレプリケーション可能なインデックスのバージョンを返します。

V1 API

http://_host:port_/solr/_core_name_/replication?command=indexversion

V2 API

http://_host:port_/api/cores/_core_name_/replication/indexversion
fetchindex

指定されたフォロワーに、リーダーからインデックスのコピーを取得させます。

http://_follower_host:port_/solr/_core_name_/replication?command=fetchindex

leaderUrl や compression などの追加属性（またはフォロワーサーバーの設定で説明されているその他のパラメーター）を渡して、リーダーから1回限りのレプリケーションを実行できます。これにより、フォロワー構成でリーダーのURLをハードコードする必要がなくなります。

abortfetch

リーダーから指定されたフォロワーへのインデックスのコピーを中止します。

http://_follower_host:port_/solr/_core_name_/replication?command=abortfetch
enablepoll

指定されたフォロワーがリーダーの変更をポーリングできるようにします。

http://_follower_host:port_/solr/_core_name_/replication?command=enablepoll
disablepoll

指定されたフォロワーがリーダーの変更をポーリングできないようにします。

http://_follower_host:port_/solr/_core_name_/replication?command=disablepoll
details

構成の詳細と現在のステータスを取得します。

http://_follower_host:port_/solr/_core_name_/replication?command=details
filelist

指定されたホストのインデックスに存在するLuceneファイルのリストを取得します。

V1 API

http://_host:port_/solr/_core_name_/replication?command=filelist&generation=<_generation-number_>

V2 API

http://_host:port_/api/cores/_core_name_/replication/files?generation=<_generation-number_>

indexversion コマンドを実行すると、インデックスの世代番号を調べることができます。

backup

サーバーにコミットされたインデックスデータがある場合、リーダーにバックアップを作成します。それ以外の場合は、何も行いません。

http://_leader_host:port_/solr/_core_name_/replication?command=backup

このコマンドは、定期的なバックアップを作成するのに役立ちます。いくつかのサポートされているリクエストパラメータがあります

numberToKeep

これは、ハンドラーで maxNumberOfBackups 初期化パラメーターが指定されていない限り、backupコマンドで使用できます。指定されている場合は、常に maxNumberOfBackups が使用され、numberToKeep リクエストパラメーターを使用しようとするとエラーが発生します。

name

(オプション) バックアップ名。スナップショットは、コアのデータディレクトリ内の snapshot.<name> という名前のディレクトリに作成されます。デフォルトでは、名前は yyyyMMddHHmmssSSS 形式の日付を使用して生成されます。location パラメーターが渡された場合は、データディレクトリの代わりに使用されます。

repository

使用するバックアップリポジトリの名前。指定しない場合は、デフォルトでローカルファイルシステムになります。

location

バックアップの場所。値は使用中のリポジトリによって異なります。ファイルシステムリポジトリの場合、場所はデフォルトでコアのdataDir（データディレクトリ）になり、指定する場合は、SOLR_HOME、SOLR_DATA_HOME、またはsolr.xml allowPaths パラメーターで指定されたパス内に存在する必要があります。

restore

バックアップリポジトリからバックアップを復元します。

http://_leader_host:port_/solr/_core_name_/replication?command=restore

このコマンドは、バックアップを復元するために使用されます。いくつかのサポートされているリクエストパラメーターがあります

name

(オプション) バックアップ名。復元するバックアップされたインデックススナップショットの名前。名前が指定されていない場合は、locationディレクトリにsnapshot.<timestamp>形式のバックアップを探します。その場合は、最新のタイムスタンプのバックアップを選択します。

repository

バックアップが格納されているバックアップリポジトリの名前。指定しない場合は、デフォルトでローカルファイルシステムになります。

location

バックアップの場所。値は使用中のリポジトリによって異なります。ファイルシステムリポジトリの場合、場所はデフォルトでコアのdataDir（データディレクトリ）になり、指定する場合は、SOLR_HOME、SOLR_DATA_HOME、またはsolr.xml allowPaths パラメーターで指定されたパス内に存在する必要があります。

restorestatus

実行中の復元操作のステータスを確認します。

http://_leader_host:port_/solr/_core_name_/replication?command=restorestatus

このコマンドは、復元操作のステータスを確認するために使用されます。このコマンドはパラメータを取りません。

ステータス値は、「In Progress」、「success」、または「failed」のいずれかです。失敗した場合は、応答で「exception」も送信されます。

deletebackup

backup コマンドを使用して作成されたバックアップを削除します。

http://_leader_host:port_ /solr/_core_name_/replication?command=deletebackup

サポートされているパラメータは2つあります。

name

スナップショットの名前。snapshot.name という名前のスナップショットが存在する必要があります。存在しない場合はエラーが返されます。

location

スナップショットが作成される場所。

分散インデックスの最適化

インデックスの最適化は、ほとんどのユーザーが通常気にする必要はないものです。特に、ReplicationHandler を使用している場合は、インデックスの最適化の影響に注意する必要があります。

リーダーインデックスの最適化に必要な時間は、大幅に異なる場合があります。小さなインデックスは数分で最適化できる場合があります。非常に大きなインデックスには数時間かかる場合があります。変数には、インデックスのサイズとハードウェアの速度が含まれます。

新しく最適化されたインデックスの配布には、数分から1時間以上かかる場合があります。これもインデックスのサイズと、ネットワーク接続とディスクのパフォーマンス機能によって異なります。最適化中はマシンに負荷がかかり、クエリを適切に処理しません。フォロワーに1時間に数回更新をスケジュールすることを考えると、コミットされたスナップショットごとに最適化を実行することはできません。

最適化されたインデックスをコピーするということは、次の snappull 中に全体インデックスを転送する必要があることを意味します。これは大きなコストですが、どこでも最適化を実行するほど大きくはありません。

この例を考えてみましょう。3つのフォロワーと1つのリーダー構成で、新しく最適化されたインデックスを配布するには、合計で約80秒かかります。階層全体に変更をロールアウトするには、マシン（またはマシン グループ）あたり約10分かかります。この最適化がクエリ層全体でロールアウトされ、最適化されている各フォロワーノードが無効になり、クエリを受信していない場合、ロールアウトには少なくとも20分、場合によっては1時間半もかかる可能性があります。さらに、最適化の後、snappull が独立して最適化されたファイルが異なると思うことがないように、ファイルを同期する必要があります。これにより、各インデックスがリーダーの完全なコピーである代わりに、インデックスの独立した破損につながる可能性もあります。

リーダーでの最適化により、直接的な最適化操作が可能になります。サービスを停止する必要があるクエリフォロワーはありません。最適化されたインデックスは、クエリが通常どおりサービスされている間にバックグラウンドで配布できます。最適化は、インデックスの更新を提供するアプリケーションにとって都合の良いときにいつでも発生する可能性があります。

最適化が一部の状況でいくつかの利点をもたらす可能性がある一方で、急速に変化するインデックスはその利点を長く保持せず、最適化は集中的なプロセスであるため、マージファクターを下げるなど、他のオプションを検討する方が良い場合があります（セグメントサイズの制御に関するセクションで説明しています）。

検索パフォーマンスが大幅に向上するという具体的な証拠がない限り、インデックスを最適化することを選択しないでください。