数据传输技术为物联网带来了希望
|
同时，也在 warm phase 阶段，设置索引 shrink，把索引的分片数缩成 5 个，因为老的索引已经不执行写入了，所以也可以执行 force merge, 强制把 segment 文件合并为 1 个，可以获得更好的查询性能。 另外，设置了 ILM 策略后，可以在索引模板里增加 index.lifecycle.name 配置，使得所有新创建的索引都可以和新添加的 ILM 策略关联，从而使得 ILM 能够正常运行。 客户使用的 ES 版本是 6.8.2， 在运行 ILM 的过程中， 也发现一些问题：
在 warm phase, 把创建时间超过 360 小时的索引从 hot 节点迁移到 warm 节点上，保持索引的副本数量为 1。之所以使用 360 小时作为条件，而不是 15 天作为条件，是因为客户的索引是按小时创建的，如果以 15 天作为迁移条件，则在每天凌晨都会同时触发 15 天前的 24 个索引一共 24*120=2880 个分片同时开始迁移索引，容易引发前文介绍的由于迁移分片数量过多导致创建索引被阻塞的问题。所以以 360 小时作为条件，则在每个小时只会执行一个索引的迁移，这样把 24 个索引的迁移任务打平，避免其它任务被阻塞的情况发生。 看到集群 master 节点的配置是 16 核 32GB 内存，JVM 实际只分配了 16GB 内存，此时只好通过对 master 节点原地增加内存到 64GB(虚拟机，使用的腾讯云 CVM， 可以调整机器规格，需要重启)，master 节点机器重启之后，修改了 es 目录 jvm.options 文件，调整了堆内存大小，重新启动了 es 进程。 3 个 master 节点都恢复正常了，但是分片还需要进行恢复，通过 GET _cluster/health 看到集群当前有超过 10w 个分片，而这些分片恢复还需要一段时间，通过调大"cluster.routing.allocation.node_concurrent_recoveries"， 增大分片恢复的并发数量。实际上 5w 个主分片恢复得是比较快的了，但是副本分片的恢复就相对慢很多，因为部分副本分片需要从主分片上同步数据才能恢复。此时可以采取的方式是把部分旧的索引副本数量调为 0， 让大量副本分片恢复的任务尽快结束，保证新索引能够正常创建，从而使得集群能够正常写入。 总结这次故障的根本原因是：集群的索引和分片数量太多，集群元数据占用了大量的堆内存，而 master 节点本身的 JVM 内存只有 16GB(数据节点有 32GB)， master 节点频繁 full gc 导致 master 节点异常，从而最终导致整个集群异常。所以要解决这个问题，还是得从根本上解决集群的分片数量过多的问题。 目前日志索引是按照小时创建，60 分片 1 副本，每天有 24*60*2=2880 个分片，每个月就产生 86400 个分片，这么多的分片可能会带来严重的问题。有以下几种方式解决分片数量过多的问题：
和客户沟通过后，客户表示可以接受方式 1 和方式 2，但是方式 3 和 4 不能接受，因为考虑到存在磁盘故障的可能性，必须保留一个副本来保证数据的可靠性;另外还必须保证所有数据都是随时可查询的，不能关闭。 场景 6：有点坑的 ILM 在上文中，虽然通过临时给 master 节点增加内存，抗住了 10w 分片，但是不能从根本上解决问题。客户的数据是计划保留一年的，如果不进行优化，集群必然扛不住数十万个分片。所以接下来需要着重解决集群整体分片数量过多的问题。前文也提到了，客户可以接受开启 shrink 以及降低索引创建粒度(经过调整后，每两个小时创建一个索引)，这在一定程度上减少了分片的数量，能够使集群暂时稳定一阵。
辅助客户在 kibana 上配置了如下的 ILM 策略： （编辑：常州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
