CoreAdmin API
Core Admin API は、主に Collections API が SolrCloud クラスタを実行する際に、内部的に使用されます。
SolrCloud ユーザーは通常、CoreAdmin API を直接使用すべきではありませんが、API はユーザー管理クラスタまたは単一ノードインストールでコアメンテナンス操作を行うユーザーにとって役立つ場合があります。
CoreAdmin API は、Solr コアを管理するために使用される特殊な リクエストハンドラー である CoreAdminHandler によって実装されます。他のリクエストハンドラーとは異なり、CoreAdminHandler は単一のコアにアタッチされていません。代わりに、各 Solr ノードには、そのノードで実行されているすべてのコアを管理し、/solr/admin/cores パスでアクセスできる CoreAdminHandler の単一のインスタンスがあります。
CoreAdmin アクションは、action リクエストパラメータを指定し、追加のアクション固有の引数を追加のパラメータとして提供する HTTP リクエストを介して実行できます。
すべてのアクション名はすべて大文字で、以下のセクションで詳細に定義されています。
このセクションのすべての例は、"techproducts" Solr の例を実行していることを前提としています。
bin/solr start -DconfigSetBaseDir=./server/solr/configsets -e techproducts以下の例では、sample_techproducts_configs configset を使用して新しいコアを作成できるように、configSetBaseDir の明示的な相対パスを渡しています。
STATUS
STATUS アクションは、実行中のすべての Solr コアのステータス、または指定されたコアのみのステータスを返します。
V1 API
https://127.0.0.1:8983/solr/admin/cores?action=STATUS&core=techproductsV2 API
curl -X GET https://127.0.0.1:8983/api/cores/単一のコアのステータスを取得するには
curl -X GET https://127.0.0.1:8983/api/cores/techproductsインデックスに関する情報の返却をスキップするには
curl -X GET https://127.0.0.1:8983/api/cores?indexInfo=falseCREATE
CREATE アクションは、新しいコアを作成して登録します。
指定された名前の Solr コアが既に存在する場合、新しいコアが初期化されている間もリクエストを処理し続けます。新しいコアの準備が整うと、新しいリクエストを受け付け、古いコアはアンロードされます。
admin/cores?action=CREATE&name=コア名&instanceDir=パス/ディレクトリ/&config=solrconfig.xml&dataDir=data
V1 API
既存の configSet を使用して新しいコアを作成する場合
https://127.0.0.1:8983/solr/admin/cores?action=CREATE&&name=techproducts_v2&configSet=sample_techproducts_configsディスクに既に既存のコアファイルがデプロイされており、それらから Solr コアを作成する必要がある場合、URL は次のようになります。
https://127.0.0.1:8983/solr/admin/cores?action=CREATE&name=_core-name_&instanceDir=_path/to/dir_&config=solrconfig.xml&dataDir=dataV2 API
curl -X POST https://127.0.0.1:8983/api/cores -H 'Content-Type: application/json' -d '
{
"create": {
"name": "techproducts_v2",
"configSet": "sample_techproducts_configs"
}
}
'このコマンドは、Core Admin API コマンドの中で、core パラメーターをサポートしない唯一のコマンドであることに注意してください。代わりに、以下に示すように、name パラメーターが必要です。
CREATE は設定を見つけられないと成功しないことに注意してください。
SolrCloud を実行していて、コレクションの新しいコアを作成する場合、設定はコレクションから継承されます。各コレクションは、ZooKeeper に保存されている configName にリンクされています。これにより、設定要件が満たされます。ただし、SolrCloud を実行している場合は、CoreAdmin API を一切使用すべきではありません。代わりに、Collections API を使用してください。
ユーザー管理のクラスターでは、Configsets が定義されている場合、以下に示すように configSet パラメーターを使用できます。configset がない場合、CREATE 呼び出しで指定された instanceDir は既に存在する必要があり、conf ディレクトリを含んでいる必要があり、その conf ディレクトリはさらに solrconfig.xml、スキーマ（通常は managed-schema.xml または schema.xml という名前）、およびこれらの設定で参照されるすべてのファイルを含んでいる必要があります。
config とスキーマのファイル名は、config パラメーターと schema パラメーターで指定できますが、これらはエキスパート向けのオプションです。conf ディレクトリの作成を避けるためにできることの 1 つは、絶対パスを指す config パラメーターと schema パラメーターを使用することですが、これは、自分が何をしているかを完全に理解していない限り、混乱を招く設定につながる可能性があります。
|
CREATE と
core.properties ファイル
|
CREATE コアのパラメーター
name-
必須
デフォルト: なし
新しいコアの名前。
<core>要素のnameと同じです。 instanceDir-
オプション
デフォルト：説明を参照
このコアのファイルが保存されるディレクトリ。
<core>要素のinstanceDirと同じです。デフォルトは、指定されていない場合はnameパラメーターに指定された値です。このディレクトリは、SOLR_HOME、SOLR_DATA_HOME、またはシステムプロパティsolr.allowPathsで指定されたパスのいずれかの中にある必要があります。 config-
オプション
デフォルト：
solrconfig.xmlinstanceDirを基準とした設定ファイル（つまり、solrconfig.xml）の名前。 schema-
オプション
デフォルト：説明を参照
コアで使用するスキーマファイルの名前。「managed schema」（デフォルトの動作）を使用している場合、有効な
managedSchemaResourceNameと一致しないこのプロパティの値は、一度読み取られ、バックアップされ、managed schema での使用のために変換されることに注意してください。詳細については、スキーマファクトリの設定を参照してください。 dataDir-
オプション
デフォルト：
datainstanceDirを基準としたデータディレクトリの名前。絶対値を使用する場合は、SOLR_HOME、SOLR_DATA_HOME、またはシステムプロパティsolr.allowPathsで指定されたパスのいずれかの中にある必要があります。 configSet-
オプション
デフォルト: なし
このコアに使用する configset の名前。詳細については、Configsets のセクションを参照してください。
collection-
オプション
デフォルト：説明を参照
このコアが属するコレクションの名前。デフォルトはコアの名前です。
collection.param=valueを使用すると、新しいコレクションが作成される場合に、param=valueのプロパティが設定されます。新しいコレクションの設定を指すには、collection.configName=config-nameを使用します。存在しないコレクションのコアを作成することは可能ですが、このアプローチはサポートされておらず、推奨されていません。常に、コアを直接作成する前に、Collections API を使用してコレクションを作成してください。 shard-
オプション
デフォルト: なし
このコアが表すシャード ID。これは特別な状況でのみ必要になるはずです。通常は、シャード ID が自動的に割り当てられるようにする必要があります。
property.name=value-
オプション
デフォルト: なし
コアプロパティ name を value に設定します。core.properties ファイルの内容の定義に関するセクションを参照してください。
async-
オプション
デフォルト: なし
非同期で処理されるこのアクションを追跡するためのリクエスト ID。
新しいコレクションの設定を指すには、collection.configName=configname を使用します。
RELOAD
RELOAD アクションは、既存の登録済み Solr コアの設定から新しいコアをロードします。新しいコアが初期化されている間、既存のコアは要求を処理し続けます。新しい Solr コアの準備が整うと、引き継ぎ、古いコアはアンロードされます。
V1 API
https://127.0.0.1:8983/solr/admin/cores?action=RELOAD&core=techproductsV2 API
curl -X POST https://127.0.0.1:8983/api/cores/techproducts/reloadこれは、新しいフィールド定義の追加など、ディスク上の Solr コアの設定を変更した場合に役立ちます。RELOAD アクションを呼び出すと、Solr を再起動することなく新しい設定を適用できます。
|
RELOAD は、既存のオブジェクトを再利用して SolrCore の「ライブ」リロードを実行します。 |
RENAME
RENAME アクションは、Solr コアの名前を変更します。
V1 API
curl -X GET "https://127.0.0.1:8983/solr/admin/cores?action=RENAME&core=currentCoreName&other=newCoreName"V2 API
curl -X POST https://127.0.0.1:8983/api/cores/currentCoreName/rename -H 'Content-Type: application/json' -d '
{
"to": "newCoreName"
}
'RENAME パラメーター
core-
必須
デフォルト: なし
名前を変更する既存の Solr コアの名前。v1 リクエストを行う場合はクエリパラメーターとして、v2 API を使用する場合はパスパラメーターとして指定します。
other(v1),to(v2)-
必須
デフォルト: なし
Solr コアの新しい名前。v1 リクエストを行う場合はクエリパラメーターとして、v2 API を使用する場合はリクエスト本文のプロパティとして指定します。
<solr>の persistent 属性がtrueの場合、新しい名前はsolr.xmlに<core>属性のname属性として書き込まれます。 async-
オプション
デフォルト: なし
非同期で処理されるこのアクションを追跡するためのリクエスト ID。
SWAP
SWAP は、2 つの既存の Solr コアにアクセスするために使用される名前をアトミックにスワップします。これは、新しいコンテンツを本番環境にスワップするために使用できます。以前のコアは引き続き使用可能であり、必要に応じてスワップバックできます。スワップ後、各コアは他方の名前で識別されます。
V1 API
`admin/cores?action=SWAP&core=_core-name_&other=_other-core-name_`V2 API
curl -X POST https://127.0.0.1:8983/api/cores/_core-name_/swap -H 'Content-Type: application/json' -d '
{
"with": "_other-core-name_"
}
'|
SolrCloud ノードで |
UNLOAD
UNLOAD アクションは、Solr からコアを削除します。アクティブなリクエストは引き続き処理されますが、指定されたコアに新しいリクエストが送信されることはありません。1 つのコアが複数の名前で登録されている場合は、指定された名前のみが削除されます。
V1 API
https://127.0.0.1:8983/solr/admin/cores?actionUNLOAD&core=techproductsV2 API
curl -X POST https://127.0.0.1:8983/api/cores/techproducts/unload -H 'Content-Type: application/json' -d '
{}
'UNLOAD アクションには、削除するコアを識別するパラメーター（core）が必要です。<solr> の persistent 属性が true に設定されている場合、この name 属性を持つ <core> 要素は solr.xml から削除されます。
|
SolrCloud コレクション内のすべてのコアをアンロードすると、そのコレクションのメタデータが ZooKeeper から削除されます。 |
UNLOAD パラメーター
core-
必須
デフォルト: なし
削除するコアの名前。このパラメーターは必須です。
deleteIndex-
オプション
デフォルト：
falsetrueの場合、コアのアンロード時にインデックスを削除します。 deleteDataDir-
オプション
デフォルト：
falsetrueの場合、dataディレクトリとそのすべてのサブディレクトリを削除します。 deleteInstanceDir-
オプション
デフォルト：
falsetrueの場合、インデックスディレクトリ、設定ファイル、その他の関連ファイルなど、コアに関連するすべてを削除します。 async-
オプション
デフォルト: なし
非同期で処理されるこのアクションを追跡するためのリクエスト ID。
MERGEINDEXES
MERGEINDEXES アクションは、1 つ以上のインデックスを別のインデックスにマージします。インデックスはコミットを完了している必要があり、マージが完了するまで書き込みに対してロックする必要があり、そうしないとマージされたインデックスが破損する可能性があります。ターゲットコアインデックスは既に存在し、マージされる 1 つ以上のインデックスと互換性のあるスキーマを持っている必要があります。マージが完了したら、ターゲットコアで別のコミットも実行する必要があります。
V1 API
curl -X GET "https://127.0.0.1:8983/solr/admin/cores?action=MERGEINDEXES&core=targetCoreName&indexDir=path/to/core1/data/index&indexDir=path/to/core2/data/index"V2 API
curl -X POST https://127.0.0.1:8983/api/cores/targetCoreName/merge-indices -H 'Content-Type: application/json' -d '
{
"indexDirs": ["path/to/core1/data/index","path/to/core2/data/index"]
}
'この例では、indexDir パラメーター（v2 API では indexDirs）を使用して、ソースコアのインデックスの場所を定義します。core パラメーターはターゲットインデックスを定義します。このアプローチの利点は、Solr コアに関連付けられていない可能性のある、Lucene ベースのインデックスをマージできることです。
または、代わりに、以下の例のように srcCore パラメーター（v2 API では srcCores）を使用することもできます。
V1 API
curl -X GET "https://127.0.0.1:8983/solr/admin/cores?action=mergeindexes&core=targetCoreName&srcCore=core1&srcCore=core2"V2 API
curl -X POST https://127.0.0.1:8983/api/cores/targetCoreName/merge-indices -H 'Content-Type: application/json' -d '
{
"srcCores": ["core1","core2"]
}
'このアプローチでは、ターゲットコアと同じ物理サーバー上にインデックスパスがない可能性のあるコアを定義できます。ただし、ソースインデックスとして Solr コアのみを使用できます。このアプローチのもう 1 つの利点は、ソースインデックスと並行して書き込みが発生した場合に、破損のリスクがそれほど高くないことです。
async パラメーターを指定してリクエスト ID を渡すことにより、この呼び出しを非同期で実行できます。この ID を使用して、REQUESTSTATUS API を使用して、既に送信されたタスクのステータスを確認できます。
SPLIT
SPLIT アクションは、1 つのインデックスを 2 つ以上のインデックスに分割します。分割されるインデックスは、リクエストを処理し続けることができます。分割された部分は、サーバーのファイルシステムの指定されたディレクトリに配置することも、実行中の Solr コアにマージすることもできます。
SPLIT アクションは、以下の表で説明する 5 つのパラメーターをサポートします。
SPLIT パラメーター
core-
必須
デフォルト: なし
分割するコアの名前。
path-
オプション
デフォルト: なし
複数値、インデックスの一部が書き込まれるディレクトリパス。このパラメーターまたは
targetCoreのいずれかを指定する必要があります。これが指定されている場合、targetCoreパラメーターを使用することはできません。 targetCore-
オプション
デフォルト: なし
複数値、インデックスの一部がマージされるターゲット Solr コア。このパラメーターまたは
pathのいずれかを指定する必要があります。これが指定されている場合、pathパラメーターを使用することはできません。 ranges-
オプション
デフォルト: なし
16 進数形式のハッシュ範囲のコンマ区切りリスト。このパラメーターを使用する場合、
split.keyは使用しないでください。このパラメーターの使用方法の例については、以下のSPLIT の例を参照してください。 split.key-
オプション
デフォルト: なし
インデックスの分割に使用するキー。このパラメータを使用する場合、
rangesは使用しないでください。このパラメータの使用例については、以下のSPLITの例を参照してください。 async-
オプション
デフォルト: なし
非同期で処理されるこのアクションを追跡するためのリクエスト ID。
SPLITの例
coreインデックスは、pathまたはtargetCoreパラメータの数と同じ数に分割されます。
2つのtargetCoreパラメータを使用する場合:
https://127.0.0.1:8983/solr/admin/cores?action=SPLIT&core=core0&targetCore=core1&targetCore=core2ここでは、coreインデックスが2つに分割され、2つのtargetCoreインデックスにマージされます。
2つのpathパラメータを使用する場合:
https://127.0.0.1:8983/solr/admin/cores?action=SPLIT&core=core0&path=/path/to/index/1&path=/path/to/index/2coreインデックスは2つに分割され、指定された2つのディレクトリパスに書き込まれます。
split.keyパラメータを使用する場合:
https://127.0.0.1:8983/solr/admin/cores?action=SPLIT&core=core0&targetCore=core1&split.key=A!ここでは、split.key、つまりA!と同じルートキーを持つすべてのドキュメントがcoreインデックスから分割され、targetCoreに書き込まれます。
rangesパラメータを使用する場合:
https://127.0.0.1:8983/solr/admin/cores?action=SPLIT&core=core0&targetCore=core1&targetCore=core2&targetCore=core3&ranges=0-1f4,1f5-3e8,3e9-5dcこの例では、16進数で指定されたハッシュ範囲0-500、501-1000、および1001-1500でrangesパラメータを使用しています。ここでは、インデックスは3つに分割され、各targetCoreは指定されたハッシュ範囲に一致するドキュメントを受け取ります。つまり、core1はハッシュ範囲0-500のドキュメントを取得し、core2はハッシュ範囲501-1000のドキュメントを受け取り、最後にcore3はハッシュ範囲1001-1500のドキュメントを受け取ります。少なくとも1つのハッシュ範囲を指定する必要があります。単一のハッシュ範囲をルートキーのハッシュ範囲と同じにすることは、複数のルートキーが同じ範囲にハッシュされる可能性があるため、split.keyパラメータを使用することと同じではないことに注意してください。
targetCoreはすでに存在する必要があり、coreインデックスと互換性のあるスキーマを持つ必要があります。分割される前に、coreインデックスで自動的にコミットが呼び出されます。
このコマンドは、SolrCloudのSPLITSHARDコマンドの一部として使用されますが、ユーザー管理のクラスタ内のコアにも使用できます。split.keyパラメータなしでユーザー管理クラスタのコアに対して使用する場合、このアクションはソースインデックスを分割し、そのドキュメントを交互に分散して、各分割ピースに同数のドキュメントが含まれるようにします。split.keyパラメータが指定されている場合、同じルートキーを持つドキュメントのみがソースインデックスから分割されます。
REQUESTSTATUS
すでに送信された非同期のCoreAdmin API呼び出しのステータスをリクエストします。
V1 API
https://127.0.0.1:8983/solr/admin/cores?action=REQUESTSTATUS&requestid=idV2 API
curl -X GET https://127.0.0.1:8983/api/node/commands/id