计算
弹性云服务器 ECS
Flexus云服务
裸金属服务器 BMS
弹性伸缩 AS
镜像服务 IMS
专属主机 DeH
函数工作流 FunctionGraph
云手机服务器 CPH
Huawei Cloud EulerOS
网络
虚拟私有云 VPC
弹性公网IP EIP
虚拟专用网络 VPN
弹性负载均衡 ELB
NAT网关 NAT
云专线 DC
VPC终端节点 VPCEP
云连接 CC
企业路由器 ER
企业交换机 ESW
全球加速 GA
安全与合规
安全技术与应用
Web应用防火墙 WAF
企业主机安全 HSS
云防火墙 CFW
安全云脑 SecMaster
DDoS防护 AAD
数据加密服务 DEW
数据库安全服务 DBSS
云堡垒机 CBH
数据安全中心 DSC
云证书管理服务 CCM
边缘安全 EdgeSec
威胁检测服务 MTD
CDN与智能边缘
内容分发网络 CDN
CloudPond云服务
智能边缘云 IEC
迁移
主机迁移服务 SMS
对象存储迁移服务 OMS
云数据迁移 CDM
迁移中心 MGC
大数据
MapReduce服务 MRS
数据湖探索 DLI
表格存储服务 CloudTable
云搜索服务 CSS
数据接入服务 DIS
数据仓库服务 GaussDB(DWS)
数据治理中心 DataArts Studio
数据可视化 DLV
数据湖工厂 DLF
湖仓构建 LakeFormation
企业应用
云桌面 Workspace
应用与数据集成平台 ROMA Connect
云解析服务 DNS
专属云
专属计算集群 DCC
IoT物联网
IoT物联网
设备接入 IoTDA
智能边缘平台 IEF
用户服务
账号中心
费用中心
成本中心
资源中心
企业管理
工单管理
国际站常见问题
ICP备案
我的凭证
支持计划
客户运营能力
合作伙伴支持计划
专业服务
区块链
区块链服务 BCS
Web3节点引擎服务 NES
解决方案
SAP
高性能计算 HPC
视频
视频直播 Live
视频点播 VOD
媒体处理 MPC
实时音视频 SparkRTC
数字内容生产线 MetaStudio
存储
对象存储服务 OBS
云硬盘 EVS
云备份 CBR
存储容灾服务 SDRS
高性能弹性文件服务 SFS Turbo
弹性文件服务 SFS
云硬盘备份 VBS
云服务器备份 CSBS
数据快递服务 DES
专属分布式存储服务 DSS
容器
云容器引擎 CCE
容器镜像服务 SWR
应用服务网格 ASM
华为云UCS
云容器实例 CCI
管理与监管
云监控服务 CES
统一身份认证服务 IAM
资源编排服务 RFS
云审计服务 CTS
标签管理服务 TMS
云日志服务 LTS
配置审计 Config
资源访问管理 RAM
消息通知服务 SMN
应用运维管理 AOM
应用性能管理 APM
组织 Organizations
优化顾问 OA
IAM 身份中心
云运维中心 COC
资源治理中心 RGC
应用身份管理服务 OneAccess
数据库
云数据库 RDS
文档数据库服务 DDS
数据管理服务 DAS
数据复制服务 DRS
云数据库 GeminiDB
云数据库 GaussDB
分布式数据库中间件 DDM
数据库和应用迁移 UGO
云数据库 TaurusDB
人工智能
人脸识别服务 FRS
图引擎服务 GES
图像识别 Image
内容审核 Moderation
文字识别 OCR
AI开发平台ModelArts
图像搜索 ImageSearch
对话机器人服务 CBS
华为HiLens
视频智能分析服务 VIAS
语音交互服务 SIS
应用中间件
分布式缓存服务 DCS
API网关 APIG
微服务引擎 CSE
分布式消息服务Kafka版
分布式消息服务RabbitMQ版
分布式消息服务RocketMQ版
多活高可用服务 MAS
事件网格 EG
企业协同
华为云会议 Meeting
云通信
消息&短信 MSGSMS
云生态
合作伙伴中心
云商店
开发者工具
SDK开发指南
API签名指南
Terraform
华为云命令行工具服务 KooCLI
其他
产品价格详情
系统权限
管理控制台
客户关联华为云合作伙伴须知
消息中心
公共问题
开发与运维
应用管理与运维平台 ServiceStage
软件开发生产线 CodeArts
需求管理 CodeArts Req
部署 CodeArts Deploy
性能测试 CodeArts PerfTest
编译构建 CodeArts Build
流水线 CodeArts Pipeline
制品仓库 CodeArts Artifact
测试计划 CodeArts TestPlan
代码检查 CodeArts Check
代码托管 CodeArts Repo
云应用引擎 CAE
开天aPaaS
云消息服务 KooMessage
云手机服务 KooPhone
云空间服务 KooDrive
本文导读
文档首页/ 云搜索服务 CSS/ 故障排除/ 集群不可用/ 分片未正常分配导致集群不可用

分片未正常分配导致集群不可用

更新时间:2024-08-27 GMT+08:00

问题现象

“集群状态”“不可用”

在Kibana的“Dev Tools”页面,执行命令GET _cluster/health查看集群健康状态,结果中“status”“red”“unassigned_shards”不为0。或者在“Cerebro”可视化页面,单击“overview”查看索引分片在各数据节点的分配情况,可见集群状态为红色和“unassigned shards”不为0,表示集群存在无法分配的索引分片。
图1 集群健康状态
图2 cerebro可视化界面

原因分析

集群出现不可用状态的原因是集群有索引分片未正常分配。

处理步骤

步骤一:确认集群不可用原因
  1. 通过Kibana接入故障集群,在Kibana的“Dev Tools”页面,执行命令GET /_recovery?active_only=true查看集群是否在进行副本恢复:
    • 返回“{"index_name":{"shards":[{"id":25,"type":"...”,代表集群存在正在进行副本恢复的索引。等待副本恢复完毕,如果集群状态仍为“不可用”,则执行下一步。
    • 返回“{ }”:代表集群未进行副本恢复,则执行下一步。
  2. 执行命令GET _cluster/allocation/explain?pretty查看索引分片未分配的原因,根据返回信息进行筛选。
    表1 参数说明

    参数

    描述

    index

    索引名称

    shard

    分片标号

    current_state

    分片当前状态

    allocate_explanation

    分片分配解释

    explanation

    解释说明

    表2 不同故障说明

    现象

    原因

    处理步骤

    “explanation”中存在“no allocations are allowed due to cluster setting [cluster.routing.allocation.enable=none]”

    集群当前设置的allocation策略禁止所有分片分配。

    参考“shard allocation策略配置错误”之▪cluster.routing.allocat...

    “explanation”中存在“too many shards [3] allocated to this node for index [write08]index setting [index.routing.allocation.total_shards_per_node=3]”

    集群当前设置的单个索引的分片允许分配给每个数据节点的分片数值过小,不满足索引分片的分配要求。

    参考“shard allocation策略配置错误”之▪index.routing.allocatio...

    “explanation”中存在“too many shards [31] allocated to this node, cluster setting [cluster.routing.allocation.total_shards_per_node=30]”

    集群当前设置的集群所有索引分片允许分配给每个数据节点的分片数值太小。

    参考“shard allocation策略配置错误”之▪cluster.routing.allocat...

    “explanation”中存在“node does not match index setting [index.routing. allocation. include] filters [box_type:"hot"]”

    索引分片需要下发到标记为“hot”的数据节点,而集群中所有数据节点都没有打这个标记时,分片无法下发。

    参考“shard allocation策略配置错误”之▪index.routing.allocatio...

    “explanation”中存在“node does not match index setting [index.routing. allocation. require] filters [box_type:"xl"]”

    索引分片需要下发到特定标记的数据节点,而集群中所有节点都没有打这个标记时,分片便无法下发。

    参考“shard allocation策略配置错误”之▪index.routing.allocatio...

    “explanation”中存在“[failed to obtain in-memory shard lock]”

    这种情况一般出现在有节点短暂离开集群,然后马上重新加入,并且有线程正在对某个shard做bulk或者scroll等长时间的写入操作,等节点重新加入集群的时候,由于shard lock没有释放,master无法allocate这个shard。

    参考•shardlock错误

    “explanation”中存在“node does not match index setting [index.routing.allocation.include] filters [_tier_preference:"data_hot OR data_warm OR data_cold"]”

    集群的某个索引设置的参数与版本不匹配。

    参考•索引参数版本不匹配

    “explanation”中存在“cannot allocate because all found copies of the shard are either stale or corrupt”

    集群的索引分片数据被损坏。

    参考“主分片数据损坏”•主分片数据损坏

    “explanation”中存在“the node is above the high watermark cluster setting [cluster.routing. allocation. disk.watermark.high=90%], using more disk space than the maximum allowed [90.0%], actual free: [6.976380997419324%]”

    节点的磁盘使用率已超过磁盘空间允许的最大值。

    参考“磁盘使用率过高”•磁盘使用率过高

步骤二:根据不同的问题现象处理故障

  • shard allocation策略配置错误
    • cluster.routing.allocation.enable参数
      1. 返回结果中“explanation”如下,表示集群当前设置的allocation策略禁止所有分片分配导致。
        图3 allocation.enable参数配置错误
      2. 在Kibana的“Dev Tools”页面,执行命令将“enable”设置为“all”,允许所有分片进行分配。
        PUT _cluster/settings
        {
          "persistent": {
            "cluster": {
              "routing": {
                "allocation.enable": "all"
              }
            }
          }
        }
        说明:

        index级别会覆盖cluster级别配置,参数设置含义如下:

        • all - (默认) 所有类型均允许allocation。
        • primaries - 只允许allocation主分片。
        • new_primaries - 只允许allocation新创建index的主分片。
        • none - 所有的分片都不允许allocation。
      3. 再执行命令POST _cluster/reroute?retry_failed=true手动进行分片分配,等待索引分片分配完成,集群状态变为可用。
    • index.routing.allocation.total_shards_per_node参数。
      1. 返回结果中“explanation”如下,表示设置的“index.routing.allocation.total_shards_per_node”值过小,不满足索引的分片分配要求。
        图4 index total_shards_per_node设置错误
      2. 在Kibana的“Dev Tools”页面,执行命令修改索引在每个节点允许分配的分片数。
        PUT index_name/_settings
        {
          "index": {
            "routing": {
              "allocation.total_shards_per_node": 3
            }
          }
        }
        说明:

        “index.routing.allocation.total_shards_per_node”的值 = index_name索引分片数 / (数据节点个数 - 1)

        参数值应设置稍微大一些,假设集群有10个节点,其中5个数据节点,2个client节点,3个master节点,有个索引的分片数为30,如果将total_shards_per_node值设为4,能分配的shard总数只有4*5=20,分片无法完全分配。5个数据节点,需要分配30个分片,每个节点应最少分配6个分片,防止某数据节点故障脱离,那最少应设置每个节点允许分配8个分片。

      3. 再执行命令POST _cluster/reroute?retry_failed=true手动进行分片分配,等待索引分片分配完成,集群状态变为可用。
    • cluster.routing.allocation.total_shards_per_node参数。
      1. 返回结果中“explanation”如下,表示集群允许分配给每个数据节点的分片数设置太小。
        图5 cluster total_shards_per_node设置错误
      2. “cluster.routing.allocation.total_shards_per_node”参数为限制集群每个数据节点可分配的分片数量,此参数默认设置为“1000”,在Kibana的“Dev Tools”页面执行如下命令设置“cluster.routing.allocation.total_shards_per_node”参数。
        PUT _cluster/settings
        {
          "persistent": {
            "cluster": {
              "routing": {
                "allocation.total_shards_per_node": 1000
              }
            }
          }
        }
      3. 出现此场景大多数是参数使用错误,误将“index.routing.allocation.total_shards_per_node”参数设置为“cluster.routing.allocation.total_shards_per_node”参数。执行如下命令可以设置“index.routing.allocation.total_shards_per_node”参数:
        PUT index_name/_settings
        {
          "index": {
            "routing": {
              "allocation.total_shards_per_node": 30
            }
          }
        }
        说明:
        两个参数都是限制单个数据节点所能分配的最大分片数。
        • “cluster.routing.allocation.total_shards_per_node”集群级别的分片限制。
        • “index.routing.allocation.total_shards_per_node”索引级别的分片限制。
      4. 再执行命令POST _cluster/reroute?retry_failed=true手动进行分片分配,等待索引分片分配完成,集群状态变为可用。
    • index.routing.allocation.include参数。
      1. 返回结果中“explanation”如下,表示是将索引分片下发到标记为“hot”的数据节点,而集群中所有数据节点都没有打这个标记时,分片无法下发。
        图6 include参数配置错误
      2. 在Kibana的“Dev Tools”页面执行命令取消该配置:
        PUT index_name/_settings
        {
          "index.routing.allocation.include.box_type": null
        }
      3. 再执行命令POST _cluster/reroute?retry_failed=true手动进行分片分配,等待索引分片分配完成,集群状态变为可用。
    • index.routing.allocation.require参数。
      1. 返回结果中“explanation”如下,表示是将分片下发到特定标记的数据节点,而集群中所有节点都没有打这个标记时,分片便无法下发。
        图7 require参数配置错误
      2. 在Kibana的“Dev Tools”页面执行命令取消该配置:
        PUT index_name/_settings
        {
          "index.routing.allocation.require.box_type": null
        }
      3. 再执行命令POST _cluster/reroute?retry_failed=true手动进行分片分配,等待索引分片分配完成,集群状态变为可用。
  • shard lock错误
    1. 返回结果中“explanation”存在“[failed to obtain in-memory shard lock]”,这种情况一般出现在有节点短暂离开集群,然后马上重新加入,并且有线程正在对某个shard做bulk或者scroll等长时间的写入操作,等节点重新加入集群的时候,由于shard lock没有释放,master无法allocate这个shard。
    2. 此现象不会造成分片数据丢失,只需要重新触发一下分配即可。在Kibana的“Dev Tools”页面执行命令POST /_cluster/reroute?retry_failed=true手动对未分配分片进行分配,等待索引分片分配完成,集群状态变为可用。
  • 索引参数版本不匹配
    1. 返回信息中的索引名称“index”和索引未分配解释“explanation ”: “node does not match index setting [index.routing.allocation.include] filters [_tier_preference:"data_hot OR data_warm OR data_cold"]”,表示集群的某个索引设置的参数与节点不匹配。
      图8 索引参数不匹配
    2. 执行命令 GET index_name/_settings查看索引配置,返回结果中是否存在不符合自身版本的索引特性。
      图9 索引设置

      以index.routing.allocation.include._tier_preference特性为例,当前集群是7.9.3版本,这个索引特性是在7.10版本之后才支持的,低版本集群使用该特性将无法分配索引的分片,导致集群不可用。

    3. 确定集群是否必须使用该不匹配的特性。
      • 是,创建与所需索引特性相匹配的版本集群,然后将老集群的数据通过备份恢复至新集群。
      • 否,执行下一步。
    4. 执行命令去除索引中不符合集群版本的特性。
      PUT /index_name/_settings
      {
        "index.routing.allocation.include._tier_preference": null
      }
    5. 执行命令POST /_cluster/reroute?retry_failed=true手动对未分配分片进行分配,等待索引分片分配完成,集群状态变为可用。
  • 主分片数据损坏
    1. 返回信息中的索引名称"index"、分片标号"shard"、分配解释"allocate_explanation" 和"store_exception":"type":"corrupt index exception",表示集群的某个索引的某个分片数据被损坏。
      图10 索引数据损坏
    2. 当索引数据被损坏或者某个分片的主副本都丢失时,为了能使集群恢复green状态,解决方法是划分一个空shard,执行以下命令划分空分片并指定分配的节点。
      POST /_cluster/reroute
      {
          "commands" : [
                  {
                  "allocate_empty_primary" : {
                      "index" : "index_name", 
                      "shard" : 2,
                      "node" : "node_name",
                      "accept_data_loss":true
                  }
              }
          ]
      }
      须知:

      一定要谨慎该操作,会导致对应分片的数据完全清空。

    3. 索引分片重新分配后,集群状态恢复可用。
  • 磁盘使用率过高
    1. 返回结果如下,其中“allocate_explanation”表示该索引的分片无法分配给任何数据节点,“explanation”表示节点磁盘使用率已超过磁盘空间允许的最大值。
      图11 explain查询结果
      说明:
      • 磁盘使用率超过85%:会导致新的分片无法分配。
      • 磁盘使用率超过90%:集群会尝试将对应节点中的分片迁移到其他磁盘使用率比较低的数据节点中。无法迁移时系统会对集群每个索引强制设置“read_only_allow_delete”属性,此时索引将无法写入数据,只能读取和删除对应索引。
      • 磁盘使用率过高时可能会发生节点脱离,后续节点自动恢复后也可能会因为集群压力过大,监控调ES接口查询集群状态时无响应,无法及时更新集群状态导致集群状态为不可用。
    2. 增加集群可用磁盘容量。
      • 在Kibana的“Dev Tools”页面,执行命令DELETE index_name清理集群的无效数据释放磁盘空间。
      • 临时降低索引副本数,待扩容磁盘容量或扩容节点完成后改回索引副本数。
        1. 在Kibana的“Dev Tools”页面,执行命令临时降低索引副本数。
          PUT index_name/_settings
          {
            "number_of_replicas": 1
          }
          如果返回结果如下:
          图12 索引read-only-allow-delete状态

          则是因为磁盘使用率已超过磁盘空间允许的最大值,集群所有索引被强制设置“read_only_allow_delete”属性,先执行命令将该属性值置为“null”,再执行2.a的命令降低索引副本数。

          PUT /_settings
          {
            "index.blocks.read_only_allow_delete": null
          }
        2. 参考扩容对集群进行节点数量或节点存储容量进行扩容。
        3. 待扩容完成后再执行2.a改回索引副本数,待索引分片完全分配后,集群状态变为可用。

我们使用cookie来确保您的高速浏览体验。继续浏览本站,即表示您同意我们使用cookie。 详情

文档反馈

文档反馈

意见反馈

0/500

标记内容

同时提交标记内容