私たちの検索は流動的な状態にあるのでお願いしますが、インデックスに変更を加えるたびに (トークナイザーやフィルター、またはシャード/レプリカの数を変更する)、インデックス全体を吹き飛ばして、すべての Rails モデルを Elasticsearch に再インデックス化します。これは、すべてのレコードを再インデックス化するためにダウンタイムを考慮に入れる必要があることを意味します。
私が気付いていない、これを行うためのよりスマートな方法はありますか?
私たちの検索は流動的な状態にあるのでお願いしますが、インデックスに変更を加えるたびに (トークナイザーやフィルター、またはシャード/レプリカの数を変更する)、インデックス全体を吹き飛ばして、すべての Rails モデルを Elasticsearch に再インデックス化します。これは、すべてのレコードを再インデックス化するためにダウンタイムを考慮に入れる必要があることを意味します。
私が気付いていない、これを行うためのよりスマートな方法はありますか?
@karmi が正しいと思います。ただし、もう少し簡単に説明しましょう。いくつかの新しいプロパティまたは分析設定を使用して、運用スキーマを時々アップグレードする必要がありました。私は最近、以下に説明するシナリオを使用して、ライブで一定の負荷がかかり、ダウンタイムのないインデックスの移行を開始しました。それはリモートで行うことができます。
手順は次のとおりです。
real1
と aliasesがありreal_write
、real_read
それを指しています。real_write
、読み取りのみreal_read
、_source
ドキュメントのプロパティが利用可能です。real2
選択した新しいマッピングと設定でインデックスを作成します。
次の一括クエリ スイッチ書き込みエイリアスを使用します。
curl -XPOST 'http://esserver:9200/_aliases' -d '
{
"actions" : [
{ "remove" : { "index" : "real1", "alias" : "real_write" } },
{ "add" : { "index" : "real2", "alias" : "real_write" } }
]
}'
これはアトミック操作です。この時点からreal2
、すべてのノードに新しいクライアントのデータが取り込まれます。リーダーはまだ古いreal1
via を使用していreal_read
ます。これが結果整合性です。
データを からreal1
に移行する必要がありますがreal2
、 の新しいドキュメントreal2
を古いエントリで上書きすることはできません。スクリプトの移行では、bulk
API を使用してcreate
操作を行う必要があります (index
またはではありませんupdate
)。簡単な Ruby スクリプトes-reindexを使用します。これは ETA ステータスが良好です。
$ ruby es-reindex.rb http://esserver:9200/real1 http://esserver:9200/real2
UPDATE 2017スクリプトを使用する代わりに、新しいReindex APIを検討することができます。競合レポートなどの興味深い機能がたくさんあります。
現在real2
は最新であり、クライアントはそれに書き込みを行っていますが、まだ から読み込んでいreal1
ます。リーダー エイリアスを更新しましょう。
curl -XPOST 'http://esserver:9200/_aliases' -d '
{
"actions" : [
{ "remove" : { "index" : "real1", "alias" : "real_read" } },
{ "add" : { "index" : "real2", "alias" : "real_read" } }
]
}'
書き込みと読み取りは に行きreal2
ます。real1
ES クラスターからインデックスをバックアップおよび削除できます。
終わり!
はい、ダウンタイムなしでデータを再インデックス化するよりスマートな方法があります。
まず、絶対に「最終的な」インデックス名を実際のインデックス名として使用しないでください。したがって、インデックスに「articles」という名前を付けたい場合は、その名前を物理的なインデックスとして使用しないでください。「articles-2012-12-12」または「articles-A」、「articles」などのインデックスを作成してください。 -1」など
次に、そのインデックスを指すエイリアス「alias」を作成します。アプリケーションはこのエイリアスを使用するため、手動でインデックス名を変更したり、アプリケーションを再起動したりする必要はありません。
第 3 に、データを再インデックス化する必要がある場合は、それらを別のインデックスに再インデックス化します。たとえば、「articles-B」としましょう。Tire のインデックス作成ツールチェーンのすべてのツールがここでサポートします。
完了したら、エイリアスを新しいインデックスにポイントします。このようにして、ダウンタイムを最小限に抑えるだけでなく (まったくありません)、安全なスナップショットも得られます。新しいインデックスへのインデックス作成を何らかの形で台無しにした場合は、問題が解決するまで古いインデックスに戻すことができます。問題。
別のインデックスを作成し、すべてのデータをそのインデックスに再インデックスしてから、インデックスの再作成が完了したら切り替えますか?