我问是因为在解决问题时我们的搜索处于不断变化的状态,但是每次我们更改索引(更改标记器或过滤器,或分片/副本的数量)时,我们都必须删除整个索引,将我们所有的Rails模型重新索引回Elasticsearch … …这意味着我们必须考虑停机时间来重新索引所有记录。
有一种我不知道的聪明方法吗?
我认为@karmi正确。但是,让我解释一下更简单。我偶尔需要使用一些新属性或分析设置来升级生产模式。我最近开始使用下面描述的方案进行实时,恒定负载,零停机时间的索引迁移。您可以远程进行。
步骤如下:
real1
real_write
real_read
_source
real2使用您选择的新映射和设置创建索引。
real2
使用以下批量查询开关写入别名。
curl -XPOST 'http://esserver:9200/_aliases' -d ' { "actions" : [ { "remove" : { "index" : "real1", "alias" : "real_write" } }, { "add" : { "index" : "real2", "alias" : "real_write" } } ] }'
这是原子操作。从此时开始real2,所有节点上都将填充新客户端的数据。读者仍然使用旧的real1via real_read。这是最终的一致性。
数据必须从迁移real1到real2,但是其中的新文档real2不能被旧条目覆盖。迁移脚本应将bulkAPI与create操作一起使用(不是index或update)。我使用简单的Ruby脚本es- reindex,它具有不错的ETA状态:
bulk
create
index
update
$ ruby es-reindex.rb http://esserver:9200/real1 http://esserver:9200/real2
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群集中备份和删除索引。
做完了!