冷热分层的elasticsearch架构下，分片无法分配到warm节点

Posted 2023-03-31 baalchina

问题现象

昨天给es集群新增了warm节点，在elasticsearch.yml中配置如下node.roles: [data, data_warm]

但是今天发现集群yellow，有个分片无法分配，通过GET /_cluster/allocation/explain可以看到报错如下：

问题分析

ps，实际上每个节点都有这个报错，我截取的是warm节点的内容。折腾半天，才发现具体原因。

首先是因为我之前测试冷热分层的时候，使用的是腾讯云的文档腾讯云的文档，文档里的做法是：

• 给节点增加一个属性，比如node.attr.temperature: warm
• 再给索引增加一个参数，比如

PUT hot_data_index/_settings

    "index.routing.allocation.require.temperature": "warm"

也就是说，这个索引会分配到tempertaure为warm的节点上。

而我在设置冷热节点的时候，参考的别人的文章，节点的属性是node.attr.key: warm，也就是key这个值是warm。
看出问题来了没？我设置的是key，而腾讯云文档设置的是tempertaure。索引要去找的是tempertaure，显然就找不到了。

解决办法

解决办法很简单，将这个节点的key值给清理掉

PUT /index-name/_settings

"settings": 
"index.routing.allocation.require.temperature": null

然后回到es，立刻就会看到提示1 initializing shards。过会就变成绿色了。

另外，需要注意的是，在es7.16文档里，冷热节点的标准设置方法并不是腾讯文档里的那种做法，而是直接在elasticsearch.yml里设置node.roles: [data, data_warm ]即可。

不规范文档害死人啊。。。

elasticsearch7.16版本数据冷热分层迁移失败总结

背景介绍：最近将某产品服务日志由本地服务器存储全部迁移到ELK，使用索引生命周期进行管理，由于日志量较大，每天的日志量为500G，考虑到成本问题，采用es的冷热数据分层，将不常查询的数据放到温层普通硬盘，保留近2个月，经常读写查询的日志在hot层保留近3天日志，2Tssd硬盘，配置好各个节点的角色后（关于配置比较简单，这里不再多说，新版本省去了很多步骤，主要是在node.roles定义角色即可），然后观察迁移结果，发生在warm层一直处于migrate状态，数据无法迁移到warm节点。

通过kibana界面或API命令（GET 索引名/_ilm/explain）可以看到索引在温热数据层迁移的状态成功与否，失败的话会有如下提示

失败提示1：

Waiting for [1] shards to be allocated to nodes matching the given filters

失败提示2:

lifecycle action [migrate] waiting for [2] shards to be moved to the [data_warm] tier (tier migration preference configuration is [data_warm,data_hot])”

可以通过API查看当前索引迁移状态：

GET  /_cluster/allocation/explain  #主要介绍这个排错方法，非常好用

 "index": "logstash-xxx”,#索引名字

 "shard": 4,#索引的某个具体的分片

 "primary": true

查看返回的结果，主要是explanation字段的值，描述了迁移失败的原因，一般都对应的解决办法：

错误原因1（节点匹配错误）:

node does not match index setting [index.routing.allocation.require] filters [box_type:“cold”,_id:“so1n_id_3”]

错误原因2（node_concurrent_incoming_recoveries设置过小）:

"reached the limit of incoming shard recoveries [6], cluster setting [cluster.routing.allocation.node_concurrent_incoming_recoveries=6] (can also be set via [cluster.routing.allocation.node_concurrent_recoveries])”

成功提示：

rebalance_explanation：cannot rebalance as no target node exists that can both allocate this shard and improve the cluster balance。

总结：

由于个人原因，未能在测试阶段进行充分验证，差点造成大错，还好过期数据已经按计划进行了迁移。