dsetoolを使用したSolrコアの再読み込み

Solrコードの再読み込みを簡素化するには、dsetool reload_coreを使用します。コマンドの構文は以下のとおりです。

$ dsetool reload_core keyspace.table [option ...]

ここで、optionは以下のオプションの1つまたは複数を表します。

オプション	設定	デフォルト	説明
schema=	`filepath`	なし	スキーマ・ファイルのパス
solrconfig=	`filepath`	なし	solrconfig.xmlファイルのパス
distributed=	trueまたはfalse	true	trueの場合、再読み込み操作がローカルDCのすべてのノードに分散および適用されます。 falseの場合、再読み込み操作が送信されたノードにのみ適用されます。
reindex=	trueまたはfalse	false	trueの場合、データのインデックスが再作成されます。 falseの場合、データのインデックスは再作成されません。
deleteAll=	trueまたはfalse	false	trueの場合、インデックスが再作成される前に、既存のインデックスが削除されます。インデックスの再作成中は、検索結果にデータはまったく表示されないか、一部のデータのみが表示されます。 falseの場合、既存のインデックスは削除されず、インデックスの再作成がその場で実行されます。インデックスの更新中は、検索結果に部分的に不正な結果が返されます。

注: コアを再度読み込み、インデックスの再作成を防ぐには、デフォルトの値reindex=falseおよびdeleteAll=falseを受け入れます。

これらのオプションは、いずれも必須ではありません。schema.xmlまたはsolrconfig.xmlあるいは両方が提供される場合、DataStax Enterpriseはそれらのファイルをアップロードしてから、コアを再度読み込みます。これらのオプションについては、「自動リソース生成によるコアの作成」で説明してありますが、dsetoolコマンドまたはHTTP RELOAD要求と同じ方法で使用します。

スキーマを変更すると、既存のインデックスと新しいスキーマの互換性が不確実になります。スキーマを変更することにより、フィールドのタイプが変更される場合、インデックスとスキーマの互換性は損なわれます。フィールドのタイプの変更は、ごくわずかで、schema.xmlファイル自体は変更されないこともあります。たとえば、その他の構成ファイル（synonymsなど）に変更を加えると、スキーマが変わってしまうことがあります。そのような非互換性が存在する場合、Solrデータのインデックスを全面的に再作成することが必要になります。これには、古いデータをすべて削除することも含まれます。これらの場合には、インデックスを全面的に再作成しないと、スキーマの変更が効果を発揮しません。通常は、Solrスキーマに変更を加えると、インデックスを全面的に再作成する必要が生じます。

注: 1つ以上のノードが分散操作でコアを再度読み込むことができない場合、エラー・メッセージには故障ノードのリストが表示されます。distributed=falseを使用して、これらの故障ノードでのみ、再度読み込みを発行します。

その場でインデックスを再作成する

reindex=trueおよびdeleteAll=falseを設定すると、データのインデックスが再作成され、既存のLuceneインデックスが維持されます。アップロード処理中であると、ユーザーは不正確な結果を検索することになります。インデックスの再作成をその場で実行するには、以下の構文を使用します。

dsetool reload_core keyspace.table reindex=true deleteAll=false

インデックスを全部再作成する

reindex=trueおよびdeleteAll=trueを設定すると、Luceneインデックスが削除され、データセットのインデックスが再作成されます。ユーザー検索を実行しても、初回は何もドキュメントが返されないか、一部のドキュメントのみが返されます。これは、Solrコアが再度読み込まれ、データのインデックスが再作成されるからです。

dsetool reload_core keyspace.table reindex=true deleteAll=true

インデックス作成のステータスを確認する

Solr Adminを使用して、インデックス作成のステータスを確認します。