我目前正在尝试将我们的ElasticSearch数据迁移到2.0兼容（即：字段名称中没有点），为从1.x升级到2.x做准备。
我已经编写了一个程序，该程序运行位于单节点集群中的数据（批量），并重命名字段，使用Bulk API重新索引文档。
在某些时候，这一切都出了问题，从我的查询返回的文档总数（要“升级”）没有改变，即使它应该倒计时。
最初我以为它不工作。当我选择一个文档并查询它以查看它是否正在更改时，我可以看到它正在工作。
但是，当我查询文档中的特定字段时，我得到了两个具有相同ID的结果。其中一个结果具有升级的字段，而另一个没有。
在进一步的检查中，我可以看到它们来自不同的碎片：

{
  "took" : 2,
  "timed_out" : false,
  "_shards" : {
    "total" : 5,
    "successful" : 5,
    "failed" : 0
  },
  "hits" : {
    "total" : 2,
    "max_score" : 19.059433,
    "hits" : [ {
      "_shard" : 0,
      "_node" : "FxbpjCyQRzKfA9QvBbSsmA",
      "_index" : "status",
      "_type" : "status",
      "_id" : "http://static.photosite.com/80018335.jpg",
      "_version" : 2,
      "_score" : 19.059433,
      "_source":{"url":"http://static.photosite.com/80018335.jpg","metadata":{"url.path":["http://www.photosite.com/80018335"],"source":["http://www.photosite.com/80018335"],"longitude":["104.507755"],"latitude":["21.601669"]}},
      ...
    }, {
      "_shard" : 3,
      "_node" : "FxbpjCyQRzKfA9QvBbSsmA",
      "_index" : "status",
      "_type" : "status",
      "_id" : "http://static.photosite.com/80018335.jpg",
      "_version" : 27,
      "_score" : 17.607681,
      "_source":{"url":"http://static.photosite.com/80018335.jpg","metadata":{"url_path":["http://www.photosite.com/80018335"],"source":["http://www.photosite.com/80018335"],"longitude":["104.507755"],"latitude":["21.601669"]}},
      ...      
  }
}

如何防止这种情况发生？

**ElasticSearch版本：**1.7.3
查询：

{
  "bool" : {
    "must" : {
      "wildcard" : {
        "metadata.url.path" : "*"
      }
    },
    "must_not" : {
      "wildcard" : {
        "metadata.url_path" : "*"
      }
    }
  }
}

编写文档的代码：

BulkRequestBuilder bulkRequest = destinationConnection.getClient().prepareBulk();
        for(Map<String, Object> doc : batch.getDocs()){
            XContentBuilder builder;
            try {
                builder = XContentFactory.jsonBuilder().startObject();
                for(Map.Entry<String, Object> mapEntry : doc.entrySet()){
                    if(!mapEntry.getKey().equals("id")){
                        builder.field(mapEntry.getKey(), mapEntry.getValue());
                    }
                }
                builder.endObject();
            } catch (IOException e) {
                throw new DocumentBuilderException("Error building request to move items to new parent!", e);
            }

            bulkRequest.add(destinationConnection.getClient().prepareIndex(destinationIndex, destinationType, (String) doc.get("id")).setSource(builder).request());

        }
        // Tried with and without setRefresh
        BulkResponse response = bulkRequest.setRefresh(true).execute().actionGet();
        for(BulkItemResponse itemResponse : response.getItems()){
            if(itemResponse.isFailed()){
                LOG.error("Updating item: {} failed: {}", itemResponse.getFailure().getId(), itemResponse.getFailureMessage());
            }
        }

更新

是否是刷新/查询速度？
该程序被设置为处理5000个文档批处理，并且没有使用滚动查询，因此我希望每次迭代从该查询返回的结果总数减少5000。
实际上，这并没有发生，每次迭代从总结果集中删除的文档数量不断减少，直到最终每次迭代都是相同的：

10:43:42.220  INFO : Fetching another batch
10:43:51.701  INFO : Found 9260992 matching documents. Processing 5000...
10:43:51.794  INFO : Total remaining: 9260992
10:43:51.813  INFO : Writing batch of 5000 items
10:43:57.261  INFO : Fetching another batch
10:44:06.136  INFO : Found 9258661 matching documents. Processing 5000...
10:44:06.154  INFO : Total remaining: 9258661
10:44:06.158  INFO : Writing batch of 5000 items
10:44:11.369  INFO : Fetching another batch
10:44:19.790  INFO : Found 9256813 matching documents. Processing 5000...
10:44:19.804  INFO : Total remaining: 9256813
10:44:19.807  INFO : Writing batch of 5000 items
10:44:22.684  INFO : Fetching another batch
10:44:31.182  INFO : Found 9255697 matching documents. Processing 5000...
10:44:31.193  INFO : Total remaining: 9255697
10:44:31.196  INFO : Writing batch of 5000 items
10:44:33.852  INFO : Fetching another batch
10:44:42.394  INFO : Found 9255115 matching documents. Processing 5000...
10:44:42.406  INFO : Total remaining: 9255115
10:44:42.409  INFO : Writing batch of 5000 items
10:44:45.152  INFO : Fetching another batch
10:44:51.473  INFO : Found 9254744 matching documents. Processing 5000...
10:44:51.483  INFO : Total remaining: 9254744
10:44:51.486  INFO : Writing batch of 5000 items
10:44:53.853  INFO : Fetching another batch
10:44:59.966  INFO : Found 9254551 matching documents. Processing 5000...
10:44:59.978  INFO : Total remaining: 9254551
10:44:59.981  INFO : Writing batch of 5000 items
10:45:02.446  INFO : Fetching another batch
10:45:07.773  INFO : Found 9254445 matching documents. Processing 5000...
10:45:07.787  INFO : Total remaining: 9254445
10:45:07.791  INFO : Writing batch of 5000 items
10:45:10.237  INFO : Fetching another batch
10:45:15.679  INFO : Found 9254384 matching documents. Processing 5000...
10:45:15.703  INFO : Total remaining: 9254384
10:45:15.712  INFO : Writing batch of 5000 items
10:45:18.078  INFO : Fetching another batch
10:45:23.660  INFO : Found 9254359 matching documents. Processing 5000...
10:45:23.712  INFO : Total remaining: 9254359
10:45:23.725  INFO : Writing batch of 5000 items
10:45:26.520  INFO : Fetching another batch
10:45:31.895  INFO : Found 9254343 matching documents. Processing 5000...
10:45:31.905  INFO : Total remaining: 9254343
10:45:31.908  INFO : Writing batch of 5000 items
10:45:34.279  INFO : Fetching another batch
10:45:40.121  INFO : Found 9254333 matching documents. Processing 5000...
10:45:40.136  INFO : Total remaining: 9254333
10:45:40.139  INFO : Writing batch of 5000 items
10:45:42.381  INFO : Fetching another batch
10:45:47.798  INFO : Found 9254325 matching documents. Processing 5000...
10:45:47.823  INFO : Total remaining: 9254325
10:45:47.833  INFO : Writing batch of 5000 items
10:45:50.370  INFO : Fetching another batch
10:45:57.105  INFO : Found 9254321 matching documents. Processing 5000...
10:45:57.117  INFO : Total remaining: 9254321
10:45:57.121  INFO : Writing batch of 5000 items
10:45:59.459  INFO : Fetching another batch

看起来文件复制从一开始就很普遍。
我刚刚尝试了一个双节点群集，其群集运行状况为：绿色，同样的事情也会发生。
接下来，我将尝试不进行复制的单节点。

更新：

以下是批量处理器监听程序数据之前/之后的示例：
之前：

Item( id=http://static.photosite.com/20160123_093502.jpg, index=status, type=status, op_type=INDEX, version=-3, parent=null, routing=null )

之后（BulkResponse指示没有失败）：

Item( id=http://static.photosite.com/20160123_093502.jpg, index=status, type=status, op_type=index, version=22)

注意事项：
1.无父级
1.无路由
1.文档版本大幅跳转
此代码段还未明确说明的是，beforeBulk请求中的每个项目在afterBulk请求详细信息中表示为成功的IndexRequest（即：一个都没有丢失）。

更新2

我认为最初的负面版本可能与此有关：https://discuss.elastic.co/t/negative-version-number-on-snapshot-restore-from-s3-bucket/56642

更新3

我刚刚发现，当我使用curl查询文档时，版本是正的，即：
1.恢复快照。
1.使用curl查询文档，版本为2
1.使用java API查询文档，版本为-1
1.对文档重新建立索引会导致版本为1的副本（具有相同ID的新文档写入不同的碎片）。
这是怎么回事？

2条答案

按热度按时间

xcitsw881#

执行摘要：

我是个白痴。

详细数据：

今天我从学习how elasticsearch routes documents to shards开始。
结果表明，它使用了以下公式：routing
默认情况下，routing是文档的_id，除非您在编制索引时将其覆盖。
每个人都提到我在做路由，但我坚持认为我没有。这就是问题所在！！
我已经还原了数据的快照。我试图升级的索引中的数据最初是由一个名为stormcrawler的程序编写的。
stormcrawler确实使用路由来索引这些文档，但是因为我没有使用路由来重新索引它们，所以它在不同的碎片上创建了明显的重复。
再说一次，ElasticSearch规则和我吸。
对不起，我浪费了大家的时间，我现在要躺在一个黑暗的房间里哭泣。

赞(0）回复(0）举报 2022-11-02

qlvxas9a2#

我在继承elasticsearch-1.2.1示例时遇到了这个问题。复制/var/lib/elasticsearch文件是不够的。为了解决多个记录具有相同ID的问题，我做了以下操作

使用elasticdump导出所有记录

--输出=您的索引. json

删除索引中的所有记录（不要删除索引本身，因为您不想重建元数据，这一点很重要）

curl -XDELETE本地主机：9200/您的索引/查询？q ='*'

使用elasticdump导入所有记录

这为我删除了重复项，并解决了分片问题
此外，您还可以通过向搜索中添加首选参数并将其限制为特定碎片来确定是否存在碎片问题。

elasticsearch允许具有不同正文数据的重复ID

2条答案

相关问题

热门标签

最新问答