Question

我们正在处理大量的分片（+ 70k），这使得我们的ES（v 1.6.0，每个索引的副本1,5个分片）不那么可靠。我们正在删除索引，但是我们注意到每次删除后刷新映射任务都会出现峰值（如果重要的话，这些删除操作都是通过REST api执行的）。这可能是一个问题，因为后续DELETE请求将与刷新映射任务交错，最终它们将超时。

例如，这是删除索引时_cat/pending_tasks的输出。

3733244    1m URGENT delete-index [test.class_jump.2015-07-16]
3733245 210ms HIGH   refresh-mapping [business.bear_case1validation.2015-09-19][[bear_case1Validation]]
3733246 183ms HIGH   refresh-mapping [business.bear_case1validation.2015-09-15][[bear_case1Validation]]
3733247 156ms HIGH   refresh-mapping [search.cube_scan.2015-09-24][[cube_scan]]
3733248 143ms HIGH   refresh-mapping [business.bear_case1validation.2015-09-17][[bear_case1Validation]]
3733249 117ms HIGH   refresh-mapping [business.bear_case1validation.2015-09-22][[bear_case1Validation]]
3733250  85ms HIGH   refresh-mapping [search.santino.2015-09-25][[santino]]
3733251  27ms HIGH   refresh-mapping [search.santino.2015-09-25][[santino]]
3733252   9ms HIGH   refresh-mapping [business.output_request_finalized.2015-09-22][[output_request_finalized]]
3733253   2ms HIGH   refresh-mapping [business.bear_case1validation.2015-08-19][[bear_case1Validation]]

有两件事我们不明白：

为什么要触发refresh_mappings？也许它们总是被触发，但现在可见，因为它们排在紧急状态后面任务。是这种情况吗？
为什么它们会在不再改变的“旧”指数上触发？（刷新的指数是一到两周。被删除的指数也是两周大）

这可能是由节点之间的负载重新平衡引起的吗？这似乎很奇怪，但没有其他任何想法。此外，似乎那里的文档很少（见下文），因此负载重新平衡似乎是一个极端的长期。

_cat/shards for test.class_jump.2015-07-16

index                                                 state      docs    store 
test.class_jump.2015-07-16                        2 r STARTED       0     144b 192.168.9.240 st-12 
test.class_jump.2015-07-16                        2 p STARTED       0     108b 192.168.9.252 st-16 
test.class_jump.2015-07-16                        0 p STARTED       0     144b 192.168.9.237 st-10 
test.class_jump.2015-07-16                        0 r STARTED       0     108b 192.168.7.49  st-01 
test.class_jump.2015-07-16                        3 p STARTED       1   15.5kb 192.168.7.51  st-03 
test.class_jump.2015-07-16                        3 r STARTED       1   15.5kb 192.168.10.11 st-18 
test.class_jump.2015-07-16                        1 r STARTED       0     144b 192.168.9.107 st-08 
test.class_jump.2015-07-16                        1 p STARTED       0     144b 192.168.7.48  st-00 
test.class_jump.2015-07-16                        4 r STARTED       1   15.6kb 192.168.10.65 st-19 
test.class_jump.2015-07-16                        4 p STARTED       1   15.6kb 192.168.9.106 st-07

有没有办法可以抑制这些？更重要的是，还有什么方法可以加速索引删除？

Answer 1

看起来您遇到的问题与issue #10318中报告的问题相同，这是由于群集试图在主节点和数据节点之间保持映射同步。比较在映射的序列化版本上运行，而fielddata部分是正在序列化的Java Map。

由于Map不保证任何排序，序列化每次都会产生语法上不同的映射，因此ES认为主节点和数据节点之间的映射是不同的，因此它尝试刷新遍及整个映射的映射。一直放置。

在迁移到2.0之前，似乎“修复”是在所有节点上的indices.cluster.send_refresh_mapping: false中设置elasticsearch.yml并重新启动它们。

删除索引

1 个答案: