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
推荐阅读
全网首发!从 0 到 1 Elasticsearch 8.X 通关视频
重磅 | 死磕 Elasticsearch 8.X 方法论认知清单
如何系统的学习 Elasticsearch ?
那些 ChatGPT4 也搞不定的 Elasticsearch 问题,请抛给我们!
更短时间更快习得更多干货!
中国50%+Elastic认证专家出自于此!
比同事抢先一步学习进阶干货!