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配置中调整连接和超时设置，例如
代码语言：javascript复制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，便可以查看全量日志。
代码语言：javascript复制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是什么原因呢?
代码语言：javascript复制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
