elasticsearch 后集群状态下聚合时类型转换错误原因及分析_org.elasticsearch.search.aggregations.bucket.terms-优快云博客

本文探讨了在Elasticsearch 1.6及1.7版本中遇到的聚类查询错误，特别是在集群环境下启动多个节点时出现的问题。通过对不同配置场景的测试，分析了可能导致此错误的原因，并提出了相应的解决办法。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

先来看下错误

前端错误

两层聚类时，外面一层返回的key是乱码，这个乱码并不是编码问题，而是根本没有对第二层的聚类分类。第一层里面的数据全部都是一样的。
直接报错，500或者503，类型转换错误或者解析异常。

后台错误：

[2015-11-30 11:06:56,105][DEBUG][action.search.type       ] [local] failed to reduce search
org.elasticsearch.action.search.ReduceSearchPhaseException: Failed to execute phase [fetch], [reduce] 
        at org.elasticsearch.action.search.type.TransportSearchQueryThenFetchAction$AsyncAction$2.onFailure(TransportSearchQueryThenFetchAction.java:159)
        at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:41)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
        at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.ClassCastException: org.elasticsearch.search.aggregations.bucket.terms.LongTerms$Bucket cannot be cast to org.elasticsearch.search.aggregations.bucket.terms.StringTerms$Bucket
        at org.elasticsearch.search.aggregations.bucket.terms.StringTerms$Bucket.compareTerm(StringTerms.java:85)
        at org.elasticsearch.search.aggregations.bucket.terms.InternalOrder$4.compare(InternalOrder.java:87)
        at org.elasticsearch.search.aggregations.bucket.terms.InternalOrder$4.compare(InternalOrder.java:83)
        at org.elasticsearch.search.aggregations.bucket.terms.InternalOrder$CompoundOrder$CompoundOrderComparator.compare(InternalOrder.java:284)
        at org.elasticsearch.search.aggregations.bucket.terms.InternalOrder$CompoundOrder$CompoundOrderComparator.compare(InternalOrder.java:270)
        at org.elasticsearch.search.aggregations.bucket.terms.support.BucketPriorityQueue.lessThan(BucketPriorityQueue.java:37)
        at org.elasticsearch.search.aggregations.bucket.terms.support.BucketPriorityQueue.lessThan(BucketPriorityQueue.java:26)
        at org.apache.lucene.util.PriorityQueue.insertWithOverflow(PriorityQueue.java:151)
        at org.elasticsearch.search.aggregations.bucket.terms.InternalTerms.reduce(InternalTerms.java:195)
        at org.elasticsearch.search.aggregations.InternalAggregations.reduce(InternalAggregations.java:140)
        at org.elasticsearch.search.aggregations.bucket.InternalSingleBucketAggregation.reduce(InternalSingleBucketAggregation.java:79)
        at org.elasticsearch.search.aggregations.InternalAggregations.reduce(InternalAggregations.java:140)
        at org.elasticsearch.search.controller.SearchPhaseController.merge(SearchPhaseController.java:407)
        at org.elasticsearch.action.search.type.TransportSearchQueryThenFetchAction$AsyncAction$2.doRun(TransportSearchQueryThenFetchAction.java:147)
        at org.elasticsearch.common.util.concurrent.AbstractRunnable.run(AbstractRunnable.java:36)
        ... 3 more
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

测试分析

以下测试集群中两个机器都单独存储数据

测试

在Elasticsearch1.6版本下，尝试多次后发现，当集群一开始只有一个时，即另一个并没有启动（两个机器的node.master都是默认值，也就是true）。插入数据，并进行聚类运算是正常的。当启动集群中另一个机器时，由于es会自动复制数据，复制完数据后，再进行聚类查询，结果错误。
在Elasticsearch1.6版本下，集群中的两台机器均启动，此时集群中没有数据。创建mapping并插入数据。再次进行查询，结果正确。
在Elasticsearch1.6版本下，集群中一台机器设置node.master: true，另一个设置为 false，先对master机器进行数据插入后，再启动slave机器进行自动数据复制。再次进行查询，结果错误。
在Elasticsearch1.7版本下，进行了同样的测试，每一次结果都和1.6版本相同。

分析

由于会出现类型转换错误，但是普通查询并没有出错。猜测是由于elasticsearch在集群中两台机器都可以是master的情况下导致mapping同步问题。而数据本身没错。

解决方法

如果要两个都是master，则需要在集群正常的情况下进行mapping的创建，数据的插入等等，避免出错。

回想

我觉得可能也和我的数据有原因吧，但是就算是数据有问题，索引本身，mapping也不应该出错。这里应该是Elasticsearch有一些问题导致。一下子我并不能从核心来解决这个问题。只能是在集群中，一定要正确使用。

另

还有一种查询方式，用脚本查询

{
  "size": 0,
  "aggregations": {
    "counts": {
      "filter": {
        "bool": {
          "must": [],
          "must_not": [] }
      },
      "aggregations": {
        "testId": {
          "terms": { "script": "doc['test_id'].value" },
          "aggregations": { "userId": { "terms": { "script": "doc['user_id'].value" } } } }
      }
    }
  }
}
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27