シャード管理コマンド
SolrCloud では、シャードはコレクションの論理パーティションです。このパーティションには、コレクション全体のインデックスの一部が格納されます。
シャードの数は、単一のコレクションに格納できるドキュメントの総数を決定するのに役立ち、検索パフォーマンスにも影響します。
このセクションのすべての例は、「techproducts」Solr の例を実行していることを前提としています。
bin/solr -c -e techproductsSPLITSHARD: シャードの分割
V1 API
入力
https://127.0.0.1:8983/solr/admin/collections?action=SPLITSHARD&collection=techproducts&shard=shard1出力
{
"responseHeader": {
"status": 0,
"QTime": 137
}
}V2 API 入力
curl -X POST https://127.0.0.1:8983/api/collections/techproducts/shards -H 'Content-Type: application/json' -d '
{
"split":{
"shard":"shard1"
}
}
'出力
{
"responseHeader": {
"status": 0,
"QTime": 125
}
}シャードを分割すると、既存のシャードが 2 つに分割され、2 つの（新しい）シャードとしてディスクに書き込まれます。元のシャードには、これまでと同じデータが含まれますが、リクエストは新しいシャードにリダイレクトされ始めます。新しいシャードには、元のシャードと同じ数のレプリカがあります。ソフトコミットは、シャード分割後に自動的に発行されるため、ドキュメントはサブシャードで表示されます。分割操作中にインデックスが自動的にディスクに永続化されるため、分割操作後に明示的なコミット（ハードまたはソフト）は必要ありません。
このコマンドを使用すると、シームレスな分割が可能になり、ダウンタイムは発生しません。分割中のシャードは、クエリとインデックス作成リクエストを引き続き受け入れ、この操作が完了すると、自動的に新しいシャードへのリクエストのルーティングを開始します。このコマンドは、numShards パラメーターを使用して作成された SolrCloud コレクション、つまり、Solr のハッシュベースのルーティングメカニズムに依存するコレクションでのみ使用できます。
分割は、元のシャードのハッシュ範囲を 2 つの等しいパーティションに分割し、元のシャード内のドキュメントを新しいサブレンジに従って分割することによって実行されます。以下で説明する 2 つのパラメーター、ranges と split.key は、分割方法をさらに制御します。
新しく作成されたシャードには、親シャードと同じ数のレプリカがあり、同じレプリカタイプになります。
splitMethod=rewrite （デフォルト）を使用する場合、分割を成功させるには、親シャードのリーダーを実行しているノードに十分な空きディスク容量、つまり、インデックスサイズの 2 倍以上の容量があることを確認する必要があります。
また、結果のサブシャードの最初のレプリカは、常にシャードリーダーノードに配置されます。
シャード分割は、長時間実行されるプロセスになる可能性があります。タイムアウトを回避するには、非同期呼び出しとして実行する必要があります。
SPLITSHARD パラメーター
collection-
必須
デフォルト: なし
分割するシャードを含むコレクションの名前。このパラメーターは必須です。
shard-
オプション
デフォルト: なし
分割するシャードの名前。
split.keyが指定されていない場合、このパラメーターは必須です。 ranges-
オプション
デフォルト: なし
ranges=0-1f4,1f5-3e8,3e9-5dcのような 16 進数のハッシュ範囲のカンマ区切りリスト。このパラメーターは、元のシャードのハッシュ範囲を、16 進数で指定された任意のハッシュ範囲間隔に分割するために使用できます。たとえば、元のハッシュ範囲が
0-1500の場合、パラメーターranges=0-1f4,1f5-3e8,3e9-5dcを追加すると、元のシャードはハッシュ範囲0-500、501-1000、1001-1500の 3 つのシャードにそれぞれ分割されます。 split.key-
オプション
デフォルト: なし
インデックスの分割に使用するキー。
このパラメーターを使用すると、指定されたルートキーのすべてのドキュメントが単一の専用サブシャードに収まるようにルートキーを使用してシャードを分割できます。この場合、ルートキーで正しいシャードを特定するのに十分であるため、
shardパラメーターを指定する必要はありません。複数のシャードにまたがるルートキーはサポートされていません。例えば、
split.key=A!がハッシュ値として12-15の範囲になり、範囲0-20を持つシャード 'shard1' に属するとします。このルートキーで分割すると、範囲0-11、12-15、16-20を持つ3つのサブシャードが生成されます。ルートキーのハッシュ範囲を持つサブシャードには、ハッシュ範囲が重複する他のルートキーのドキュメントも含まれる可能性があることに注意してください。 numSubShards-
オプション
デフォルト:
2親シャードを分割するサブシャードの数。許可される値は
2から8の範囲です。このパラメーターは、
rangesまたはsplit.keyが指定されていない場合にのみ使用できます。 splitMethod-
オプション
デフォルト:
rewrite現在、シャード分割には2つの方法がサポートされています。*
rewrite: 各パーティションに保持するドキュメントを選択した後、このメソッドはサブインデックスを最初から作成します。これは、CPUとI/Oを大量に消費する長いプロセスですが、各パーティションに属していないドキュメントのデータを含まない、最適サイズのサブインデックスが得られます。*link: ファイルシステムレベルのハードリンクを使用して、元のインデックスファイルのコピーを作成し、各パーティションで削除されたドキュメントのリストを含むファイルのみを変更します。この方法は、rewriteメソッドよりもはるかに高速でリソースを消費しませんが、結果のサブインデックスは、パーティションに属さないドキュメントのデータもまだ含まれているため、元のインデックスと同じくらい大きくなります。これにより、レプリケーションプロセスが遅くなり、レプリカノードでより多くのディスク容量が消費されます（ハードリンクがサポートされていない場合を除き、複数のハードリンクされたコピーはリーダノードで追加のディスク容量を占有しません）。 splitFuzz-
オプション
デフォルト:
0.0サブシャードの範囲を、シャード範囲の合計のこのパーセンテージで変動させることを可能にする、
0.5より小さい浮動小数点値。奇数シャードは大きく、偶数シャードは小さくなります。 property.name=value-
オプション
デフォルト: なし
コアプロパティ name を value に設定します。サポートされるプロパティと値の詳細については、コアディスカバリーのセクションを参照してください。
waitForFinalState-
オプション
デフォルト:
falsetrueの場合、影響を受けるすべてのレプリカがアクティブになった場合にのみリクエストが完了します。falseの場合、APIは単一のアクションのステータスを返します。これは、新しいレプリカがオンラインになりアクティブになる前である可能性があります。 timing-
オプション
デフォルト:
falsetrueの場合、処理の各段階が計測され、応答にtimingセクションが含まれます。 async-
オプション
デフォルト: なし
このアクションを追跡するためのリクエストID。これは非同期的に処理されます。
splitByPrefix-
オプション
デフォルト:
falsetrueの場合、分割点はシャード内の compositeId 値の分布を考慮して選択されます。compositeId は<prefix>!<suffix>の形式を持ち、同じプレフィックスを持つすべてのドキュメントはハッシュ空間内で同じ場所に配置されます。分割されるシャードに複数のプレフィックスがある場合、分割点は、プレフィックスを分割することなく、プレフィックスをできるだけ均等なサイズのシャードに分割するように選択されます。シャードにプレフィックスが1つしかない場合、プレフィックスの範囲は半分に分割されます。id フィールドは通常、各プレフィックスを持つドキュメントの数を決定するためにスキャンされます。最適化として、オプションのフィールド
id_prefixが存在し、各ドキュメントのドキュメントプレフィックス（!を含む）がインデックスされている場合、それがカウントの生成に使用されます。id_prefixを設定する簡単な方法の1つは、スキーマ内の copyField です。
<!-- OPTIONAL, for optimization used by splitByPrefix if it exists -->
<field name="id_prefix" type="composite_id_prefix" indexed="true" stored="false"/>
<copyField source="id" dest="id_prefix"/>
<fieldtype name="composite_id_prefix" class="solr.TextField">
<analyzer>
<tokenizer class="solr.PatternTokenizerFactory" pattern=".*!" group="0"/>
</analyzer>
</fieldtype>現在の実装の詳細と制限
-
プレフィックスのサイズは、プレフィックスを持つドキュメントの数を使用して計算されます。
-
2レベルの compositeId のみがサポートされています。
-
シャードは2つにのみ分割できます。
SPLITSHARD レスポンス
出力には、リクエストのステータスと新しいシャード名が含まれます。新しいシャード名は、元のシャードをベースにし、アンダースコアと番号を追加したものになります。たとえば、「shard1」は「shard1_0」と「shard1_1」になります。ステータスが「success」以外の場合は、リクエストが失敗した理由を説明するエラーメッセージが表示されます。
その他の構成
シャードを分割する場合、リーダシャードのローカルファイルシステムで空きディスク容量チェックが実行されます。これは、solr.shardSplit.checkDiskSpace.enabled システムプロパティ（つまり、-Dsolr.shardSplit.checkDiskSpace.enabled=false）を使用して無効にできます。これは、HDFS ではデフォルトで無効になっています。
CREATESHARD: シャードの作成
シャードは、'implicit' ルーター（つまり、コレクションの作成時に router.name=implicit が指定された場合）を使用するコレクションに対してのみ、このAPIで作成できます。既存の 'implicit' コレクションに対して、名前付きの新しいシャードを作成できます。
'compositeId' ルーター（router.key=compositeId）で作成されたコレクションには、SPLITSHARD を使用してください。
V1 API
入力
https://127.0.0.1:8983/solr/admin/collections?action=CREATESHARD&shard=newShardName&collection=techproducts出力
{
"responseHeader": {
"status": 0,
"QTime": 120
}
}V2 API 入力
curl -X POST https://127.0.0.1:8983/api/collections/techproducts/shards -H 'Content-Type: application/json' -d '
{
"shard":"newShardName"
}
'出力
{
"responseHeader": {
"status": 0,
"QTime": 125
}
}コレクションの replicationFactor または nrtReplicas、tlogReplicas、pullReplicas のデフォルト値は、新しいシャード用に作成されるレプリカの数を決定するために使用されます。これは、リクエストに対応するパラメーターを明示的に渡すことによってカスタマイズできます。
CREATESHARD パラメーター
collection-
必須
デフォルト: なし
分割するシャードを含むコレクションの名前。v1リクエストではクエリパラメーターとして、v2リクエストではパスパラメーターとして提供されます。
shard-
必須
デフォルト: なし
作成するシャードの名前。
createNodeSet-
オプション
デフォルト: なし
新しいコレクションを分散させるノードを定義できます。指定しない場合、CREATESHARD 操作は、すべてのライブ Solr ノードに分散されたシャードレプリカを作成します。
形式は、
localhost:8983_solr,localhost:8984_solr,localhost:8985_solrのような、カンマ区切りのノード名のリストです。 nrtReplicas-
オプション
デフォルト: *説明を参照*
新しいシャード用に作成する必要がある
nrtレプリカの数。省略した場合、コレクションのデフォルトが使用されます。 tlogReplicas-
オプション
デフォルト: *説明を参照*
新しいシャード用に作成する必要がある
tlogレプリカの数。省略した場合、コレクションのデフォルトが使用されます。 pullReplicas-
オプション
デフォルト: *説明を参照*
新しいシャード用に作成する必要がある
pullレプリカの数。省略した場合、コレクションのデフォルトが使用されます。 property.name=value-
オプション
デフォルト: なし
コアプロパティ name を value に設定します。サポートされるプロパティと値の詳細については、コアディスカバリーのセクションを参照してください。
waitForFinalState-
オプション
デフォルト:
falsetrueの場合、影響を受けるすべてのレプリカがアクティブになった場合にのみリクエストが完了します。falseの場合、APIは単一のアクションのステータスを返します。これは、新しいレプリカがオンラインになりアクティブになる前である可能性があります。 async-
オプション
デフォルト: なし
このアクションを追跡するためのリクエストID。これは非同期的に処理されます。
DELETESHARD: シャードの削除
シャードを削除すると、シャードのすべてのレプリカがアンロードされ、コレクションの state.json から削除され、(デフォルトでは) 各レプリカの instanceDir と dataDir が削除されます。非アクティブなシャード、またはカスタムシャーディングに範囲が指定されていないシャードのみが削除されます。
V1 API
https://127.0.0.1:8983/solr/admin/collections?action=DELETESHARD&shard=shard1&collection=techproductsV2 API
curl -X DELETE https://127.0.0.1:8983/api/collections/techproducts/shards/shard1DELETESHARD パラメーター
collection-
必須
デフォルト: なし
削除するシャードを含むコレクションの名前。v1およびv2リクエストでは、それぞれクエリパラメーターまたはパスパラメーターとして提供されます。
shard-
必須
デフォルト: なし
削除するシャードの名前。v1およびv2リクエストでは、それぞれクエリパラメーターまたはパスパラメーターとして提供されます。
deleteInstanceDir-
オプション
デフォルト:
trueデフォルトでは、Solrは削除された各レプリカのインスタンスディレクトリ全体を削除します。インスタンスディレクトリが削除されないようにするには、これを
falseに設定します。 deleteDataDir-
オプション
デフォルト:
trueデフォルトでは、Solrは削除された各レプリカのデータディレクトリを削除します。データディレクトリが削除されないようにするには、これを
falseに設定します。 deleteIndex-
オプション
デフォルト:
trueデフォルトでは、Solrは削除された各レプリカのインデックスを削除します。インデックスディレクトリが削除されないようにするには、これを
falseに設定します。 followAliases-
オプション
デフォルト: false
コレクションパラメーターを、解決される実際のコレクション名のエイリアスとして扱うことを許可するフラグ。
async-
オプション
デフォルト: なし
このアクションを追跡するためのリクエストID。これは非同期的に処理されます。
FORCELEADER: シャードリーダーの強制
シャードがリーダーを失う可能性の低い場合に、新しいリーダーの選出を強制するために、このコマンドを呼び出すことができます。
V1 API
入力
https://127.0.0.1:8983/solr/admin/collections?action=FORCELEADER&collection=techproducts&shard=shard1出力
{
"responseHeader": {
"status": 0,
"QTime": 78
}
}V2 API 入力
curl -X POST https://127.0.0.1:8983/api/collections/techproducts/shards/shard1/force-leader出力
{
"responseHeader": {
"status": 0,
"QTime": 125
}
}INSTALLSHARDDATA: シャードへのデータのインストール/インポート
通常、データはインデックス作成ドキュメントによって、Solr コレクション（および構成するシャード）に追加されます。ただし、ユースケースによっては、シャードごとのインデックスをオフラインで構築する必要がある場合があります。多くの場合、これは、クエリトラフィックをインデックス作成負荷から隔離する手段として、または使用中の ETL パイプラインが特に複雑であるためです。INSTALLSHARDDATA API を使用すると、これらの事前に構築されたインデックスをコレクション内の個々のシャードにインストールできます。インストールは、インデックスファイルをシャード内のすべてのレプリカにコピーし、そのシャードが保持する既存のデータを上書きします。
シャードにデータをインストールするには、まず、MODIFYCOLLECTION API を使用して、そのシャードを所有するコレクションを "readOnly" モードにする必要があります。読み取り専用モードになったら、シャードのインストールをシリアルまたは並行して実行できます。データは、Solr のプラグ可能な バックアップリポジトリ抽象化でサポートされている任意の repository および location からインポートできます。
指定された location には、コアの data/index ディレクトリを構成するすべてのファイルが含まれている必要があります。ユーザーは、シャードにインストールされたインデックスが、そのシャードをホストするコレクションのスキーマと構成と互換性があることを保証する責任があります。
V1 API
入力
https://127.0.0.1:8983/solr/admin/collections?action=INSTALLSHARDDATA&collection=techproducts&shard=shard1&repository=localfs&location=/mounts/myNFSDrive/tech/shard1/data/index出力
{
"responseHeader": {
"status": 0,
"QTime": 78
}
}V2 API 入力
curl -X POST https://127.0.0.1:8983/api/collections/techproducts/shards/shard1/install -H 'Content-Type: application/json' -d '
{
"repository": "localfs",
"location": "/mounts/myNFSDrive/tech/shard1/data/index"
}
'出力
{
"responseHeader": {
"status": 0,
"QTime": 125
}
}INSTALLSHARDDATA パラメーター
collection-
必須
デフォルト: なし
コレクションの名前。このパラメーターは必須です。v1リクエストではクエリパラメーターとして、v2リクエストではパスセグメントとして指定されます。
shard-
必須
デフォルト: なし
データをインストールするシャードの名前。このパラメーターは必須です。v1リクエストではクエリパラメーターとして、v2リクエストではパスセグメントとして指定されます。
location-
必須
デフォルト: なし
インストールするインデックスファイルを見つけるために、指定されたバックアップリポジトリ内の場所。v1リクエストではクエリパラメーターとして、v2リクエストではリクエストボディで指定されます。
repository-
オプション
デフォルト: なし
インデックスファイルを検索するバックアップリポジトリの名前。v1リクエストではクエリパラメーターとして、v2リクエストではリクエストボディで指定されます。リポジトリパラメーターが指定されていない場合、Solr のデフォルトのバックアップリポジトリ (solr.xml で定義されている場合) がフォールバックとして使用されます。
async-
オプション
デフォルト: なし
このアクションを追跡するためのリクエストID。これは非同期的に処理されます。