记一次ElasticSearch重启之后shard未分配问题的解决

记一次ElasticSearch重启之后shard未分配问题的解决

环境

  • ElasticSearch6.3.2,三节点集群
  • Ubuntu16.04
  • 一个名为user的索引,索引配置为:3 primary shard,每个primary shard 2个replica

正常情况下,各个分片的分布如下:

可见,user 索引的三个分片平均分布在各台机器上,可以完全容忍一台机器宕机,而不丢失任何数据。

由于一次故障(修改了一个分词插件,但是这个插件未能正确加载),导致 node-151 节点宕机了。修复问题后,执行./bin/elasticsearch -d正常启动,但是发现集群中存在三个未分配的shards。本以为这些未分配的shards在node-151正常启动后能够自动分配,但是却发现它一直没有自动分配。

解决方法

首先:GET user/_recovery?active_only=true 发现集群并没有进行副本恢复。

执行GET _cluster/allocation/explain?pretty发现:

"explanation": "shard has exceeded the maximum number of retries [5] on failed allocation attempts - manually call [/_cluster/reroute?retry_failed=true] to retry, [unassigned_info[[reason=ALLOCATION_FAILED], at[2018-09-29T08:02:03.794Z], failed_attempts[5], delayed=false, details[failed shard on node [mKkj4112T7aLeC2oNouOrg]: failed to update mapping for index, failure MapperParsingException[Failed to parse mapping [profile]: analyzer [hanlp_standard] not found for field [details]]; nested: MapperParsingException[analyzer [hanlp_standard] not found for field [details]]; ]

原来是分词插件错误导致。再仔细看日志,有一行:

allocation_status: "no_attempt"

原因是:shard 自动分配 已经达到最大重试次数5次,仍然失败了,所以导致"shard的分配状态已经是:no_attempt"。这时在Kibana Dev Tools,执行命令:POST /_cluster/reroute?retry_failed=true即可。由index.allocation.max_retries参数来控制最大重试次数。

The cluster will attempt to allocate a shard a maximum of index.allocation.max_retries times in a row (defaults to 5), before giving up and leaving the shard unallocated.

当执行reroute命令对分片重新路由后,ElasticSearch会自动进行负载均衡,负载均衡参数cluster.routing.rebalance.enable默认为true。

It is important to note that after processing any reroute commands Elasticsearch will perform rebalancing as normal (respecting the values of settings such as cluster.routing.rebalance.enable) in order to remain in a balanced state.

过一段时间后:执行 GET /_cat/shards?index=user 可查看 user 索引中所有的分片分配情况已经正常了。

user 1 p STARTED 13610428 2.6gb node-248

user 1 r STARTED 13610428 2.5gb node-151

user 1 r STARTED 13610428 2.8gb node-140

user 2 p STARTED 13606674 2.8gb node-248

user 2 r STARTED 13606674 2.7gb node-151

user 2 r STARTED 13606684 3.8gb node-140

user 0 p STARTED 13603429 2.6gb node-248

user 0 r STARTED 13603429 2.6gb node-151

user 0 r STARTED 13603429 2.7gb node-140

第一列:索引名称;第二列标识 shard 是primary(p) 还是 replica(r);第三列 shard的状态;第四列:该shard上的文档数量;最后一列 节点名称。

总结

一般来说,ElasticSearch会自动分配 那些 unassigned shards,当发现某些shards长期未分配时,首先看下是否是因为:为索引指定了过多的primary shard 和 replica 数量,然后集群中机器数量又不够。另一个原因就是本文中提到的:由于故障,shard自动分配达到了最大重试次数了,这时执行 reroute 就可以了。

参考资料

/_cat/shards 命令:https://www.elastic.co/guide/en/elasticsearch/reference/current/cat-shards.html

2018.9.30

原文:https://www.cnblogs.com/hapjin/p/9726469.html

原文地址:https://www.cnblogs.com/hapjin/p/9726469.html

时间: 2024-07-31 13:42:26

记一次ElasticSearch重启之后shard未分配问题的解决的相关文章

Ubuntu连接以太网时显示“设备未托管”的解决办法

Ubuntu连接以太网时显示"设备未托管"的解决办法 故障分析: 电脑之前可能设置过PPOE(有线宽带虚拟拨号),常见为连接校园拨号宽带. 解决办法: 第一步:打开终端 第二步:切换到root用户 第三步:切换到 /etc/network 目录下:cd /etc/network/ 第四步:键入vim interface进入编辑interfaces文件模式.最后一行内容的意思是说eth0需要手动配置连接,但是当前局域网是DHCP网络,也就是接入网络的电脑需要"自动获取IP地址&

Advanced Installer 打包后,安装包在WIN10下重启后再次运行安装的解决办法

原文:Advanced Installer 打包后,安装包在WIN10下重启后再次运行安装的解决办法 前几个月使用Advanced Installer 打包了一堆安装包,其中有使用默认主题的,也有根据UI设计更改过一些功能的,当时在Windows7下测试没有任何问题,就直接上线给用户使用了. 这两天在禅道上发现指派了一个BUG过来,描述的内容是在Windows10下安装包会出现重启后再次自动运行的问题,见鬼了,没有写过自启动注册表啊,马上打开工程查看,发现了一个很奇怪的现象,下面来介绍. 1.当

使用虚拟机克隆CentOS 6.9系统重启网卡报错问题的解决

使用虚拟机克隆CentOS6.9系统重启网卡报错问题的解决 1.错误信息 Bringing up interface eth0:  Device eth0 does not seem to be present,delaying initialization.                    [FAILED] 2.解决方法 (1)配置IP地址,重启网卡,出现如下报错 (2)这是因为克隆后的系统和原系统MAC地址和UUID一样,删除UUID和MAC地址 (3)删除网卡相关信息的文件 (4)重

maven工程运行maven test提示JAVA_HOME 未配置的解决

maven工程运行maven test提示JAVA_HOME 未配置的解决: ----- 以下内容转自http://blog.sina.com.cn/s/blog_9ba71d0b01014bux.html JDK (Java Development Kit) Java开发工具包,很直白的说就是为开发人员准备的SDK. SDK (Software Development Kit)软件开发包.所以我们解压JDK 会发现在安装位置 有一个JDK有一个JRE(Java Runtime Envirome

表空间正在热备份时关闭实例重启报错的重现和解决

最近一个客户的库在OPEN时报错需要恢复,发现原因为当时一个表空间正在热备份-->ALTER TABLESPACE TEST1 BEGIN BACKUP;  然后实例异常关闭(可能为ABORT或KILL SMON等进程,这里据说为存储直接关闭导致),然后重启时遇到此错误. 在ORACLE 10.2.0.1及11.2.0.4版本中重现了此错误,在这两个版本中同样的情况但是报错信息不太一样,具体情况如下: 10.2.0.1.0 版本表空间正在热备份时关闭实例重启报错的重现和解决: SQL> sel

LinuxMint/Ubuntu 关机重启等待 90 秒问题的解决办法

LinuxMint/Ubuntu 关机重启等待 90 秒问题的解决办法(其他发行版也可行):1.安装 watchdogsudo apt install watchdog 2.开启 watchdog 服务sudo systemctl enable watchdog.service 3.马上启用 watchdog 服务sudo systemctl start watchdog.service 只需上述三步,关机等待 90 秒就消失了.

记一次Elasticsearch OOM的优化过程——基于segments force merge 和 store type 转为 niofs

首选,说明笔者的机器环境(不结合环境谈解决方案都是耍流氓): cpu 32核,内存128G,非固态硬盘: RAID0 (4T * 6),单节点,数据量在700G到1800G,索引15亿~21亿.敖丙大人,在蘑菇街,集群分片,固态硬盘比不起. 转载请注明出处:https://www.cnblogs.com/NaughtyCat/p/elasticsearch-OOM-optimize-story.html  业务场景: 保存7天索引,每天有400G.发现ES时不时的OOM,和重启.当索引超过500

记一次Laravel 定时任务schedul:run未执行的处理

关于Laravel的任务调度(定时任务)的配置在此不做赘述,跟着官方文档一步一步的操作是不会导致定时任务不能正常工作的. 为保证能及时捕获定时任务执行出现异常的原因,只需在配置系统crontab时指定日志文件即可.在执行中出现的任何问题都将会记录在你指定(任意区域,需注意权限)的日志当中.这对于寻找问题原因来说,是极为方便的. * * * * * cd /path-to-your-project && php artisan schedule:run >> 你的日志文件位置.l

elasticsearch aggregation 过程(未完)

在查询过程中,ES是将整个查询分成几个阶段的,大体如下: QueryPhase rescorePhase suggestPhase aggregationPhase FetchPhase 对于全文检索,可能还有DFSPhase.从源代码QueryPhase 类可以看出 @Override     public void execute(SearchContext searchContext) throws QueryPhaseExecutionException {          //创建A