Elasticsearch 线上实战问题及解决方案探讨

1、reindex相关问题

1.1 问题描述

我有 1tb 的一个大索引若干，要迁移到另外一个新集群去，有没有好办法？reindex好像会中断......

reindex 是不是就算设置了频率也会莫名的中断，而且没地方查到错误？1000多万的数据，大概80G 用reindex有时候都会莫名的断。

有时候是全的，有时候不全。

https://t.zsxq.com/14pVGxDdv

1.2 问题认知

对于大型索引的迁移问题，迁移 1TB 大小的索引，尤其是在保持服务不中断的情况下，是一项挑战。

Reindex 操作本质上是 Elasticsearch 提供的高级复制，它会从源索引读取文档并写入目标索引。对于大型索引，这可能成为一个瓶颈，因为它需要大量的IO和网络带宽。

反馈和问到最多的问题就是：Reindex 支不支持断点续传？

其实，Reindex确实不提供原生的断点续传功能。如果过程中断，则需要重新开始或者手动管理已经完成的部分。

1.3 解决方案

1.3.1 数据规模和数据量不大，推荐使用 reindex。

注意事项如下：

1、集群足够健康。确保集群健康状况良好，没有过载或者资源争夺情况。
2、用好 slice，提高并行效能。

使用_reindex API时，通过设置 scroll 和 batch_size 参数来管理内存使用和单批次的文档数量。使用 slice 功能来并行化reindex任务。

3、避免中断策略

在Elasticsearch配置中调整连接和超时设置，例如

reindex.remote.connect_timeout
reindex.remote.read_timeout

4、自己维护校验机制。

迁移完成后，使用校验和或者文档计数来确认数据完整性。

之前实战项目中，可以定时脚本统计一下写入新索引的数据量，以校验源和目的端数据的一致性。

1.3.2 数据规模和数据量巨大，推荐使用快照或者 logstash 等工具。

1、快照和恢复机制创建一个源索引的快照，并将其恢复到新集群。这通常比 reindex 操作更加可靠。
2、logstash 同步支持两种类似断点续传机制，一是：基于自增ID同步，另一是：基于自增时间同步。
3、canal 同步如果源头是 MySQL、Oracle 等关系型数据库，推荐使用阿里开源的 canal 工具同步。

https://github.com/alibaba/canal

2、如何记录es的所有请求日志？

https://t.zsxq.com/14ccO0rEr

2.1 问题认知

这是经常被问到的问题，默认情况下 Elasticsearch 输出核心是 error 日志，以方便我们窥探集群哪里出了问题。

但，有些业务场景，需要全量日志，包含但不限于检索日志细节等。

这时候，默认机制便不再生效。

2.2 问题解决

打开 slowlog，便可以查看全量日志。

PUT packets-2022-12-14/_settings
{
"index.indexing.slowlog.threshold.index.debug": "0s",
"index.search.slowlog.threshold.fetch.debug": "0s",
"index.search.slowlog.threshold.query.debug": "0s"
}

更多推荐：Elasticsearch 日志能否把全部请求打印出来？

3、脚本的使用问题

3.1 问题描述

我想请问下我用kibana中的无痛脚本编写创建新的字段时想要创建一个list数据表，输入下面这段代码，但是平台却显示无法识别new ArrayList是什么原因呢?

List(String)mylist= new ArrayList<>()

https://t.zsxq.com/142Q4X8mp

https://t.zsxq.com/14rq91spR

https://t.zsxq.com/14c0vh6ND

3.2 问题认知

Elasticsearch painless 脚本功能的确非常强大，但非必要不要使用。原因在于后期的性能问题。

3.3 问题解决

1、首先，写入的时候充分建模。

能前置写入的时候处理的话，尽量前置处理。借助写入语言：Java、Python 等处理完毕后再写入。

2、其次，写入前借助 Ingest pipeline 预处理。

Ingest pipeline 是写入前预处理的锋利的“瑞士军刀”，功能也非常强大，5.X版本就已经推出，可以大胆的用起来。

写入的时候处理，可能会写入变慢，总比：检索响应慢更容易让客户接受。

与之并驾齐驱的还可以借助：logstash filter 环节实现预处理过滤功能。

3、再次，检索的时候使用：runtime_field 动态字段实现。

这是迫不得已的下策，需要结合场景选用。

此方案也比自己写脚本来得更为实际。

4、集群相关问题

4.1 问题描述

请问大佬，集群扩容，新加入的节点需要把原集群机器中的data目录拷贝到新加入的节点中吗？还是新节点直接空data目录加入即可？再就是，linux和windows 的 ES可以互相加入彼此的集群中吗？谢谢

https://t.zsxq.com/14EuMm1Q7

4.2 问题认知

凡是涉及到直接拷贝data目录的多半都是官方不推荐的冒险方案，非特殊情况都不建议这么做。

4.3 解决方案

其一：了解副本的原理、路由机制原理，可以知道，新写入的数据会根据路由落到某个节点的某个分片，然后，复制到其他的副本分片中去。这样手动迁移data的必要性和可能性都不存在了。

其二：当然可以，windows 和 linux 本就是平台的不同，但都可以作为节点的宿主机。Elasticsearch 本来就是 java 开发的，支持跨平台。

5、自定义词典问题

5.1 问题描述

中文分词字段，如何实现不同字段使用不同的自定义词典？

https://t.zsxq.com/14QYEGCu7

5.2 问题认知

这是一种小众业务场景问题。

一般咱们企业级应用更多的是一类业务敲定一个分词器，往往在分词器的细粒度等问题做文章。比如：如何动态扩展词库？如何丰富已有词库？

5.3 解决方案

如果非要不同字段不同字典，其实最直接方案，可以导入多个分词插件。

比如：引入 IK 分词插件同时引入结巴分词插件。这样就可以很好得解决。

但，我验证了一下，仅 IK 扩展支持两套分词词典，貌似不改变源码不具备可行性。

推荐一个支持多词库的源码修改过的 IK 解决方案。

“改造前，所有索引使用一个词库，没办法针对不同索引添加不同词库，改造后，词库的加载由索引中自定义的analyzer配置时，设置的词库而决定从而实现了，不同业务的索引使用不同的词库。”

https://github.com/PeterMen/elasticsearch-analysis-ik