ES分片数超限或未分配，导致写入请求被拒绝

Question

ES集群中，当分片数超限（如超出`cluster.max_shards_per_node`限制）或存在未分配分片（UNASSIGNED）时，写入请求常被拒绝并返回`429 Too Many Requests`或`503 Service Unavailable`。典型诱因包括：索引创建时指定过多主分片（如单节点集群设10个主分片）、节点下线导致副本分片无法分配、磁盘水位触发分片分配阻塞（`disk.watermark.high`）、或`cluster.routing.allocation.enable`被禁用。此时即使文档合法、集群健康状态为yellow，写入仍失败——因ES在路由阶段即校验目标分片是否可写，而UNASSIGNED分片无有效主分片承载写入。运维中易误判为业务流量激增，实则需优先检查`_cat/shards?v&s=state`和`_cluster/allocation/explain`定位卡点。根本解决需结合索引生命周期管理（ILM）、合理分片规划（建议单分片≤50GB）及动态调优分配策略。

Answer 1

```html

一、现象层：写入失败的表征与误判陷阱

当 Elasticsearch 集群返回 429 Too Many Requests 或 503 Service Unavailable 时，一线工程师常第一反应是“流量突增”或“下游超时”，但真实根因往往与分片分配状态强相关。即使 _cat/health?v 显示 yellow（副本缺失但主分片在线），只要存在 UNASSIGNED 主分片，对应索引的写入即被路由层直接拒绝——ES 在文档路由阶段即校验目标分片是否处于 STARTED 状态，而非等到实际写入执行。该机制保障了数据一致性，却也放大了配置失当的连锁影响。

二、诊断层：精准定位 UNASSIGNED 分片的黄金组合命令

• GET /_cat/shards?v&s=state&h=index,shard,prirep,state,unassigned.reason,node —— 快速识别所有未分配分片及其原因（如 CLUSTER_RECOVERED、ALLOCATION_FAILED）
• GET /_cluster/allocation/explain?pretty —— 深度解析单个 UNASSIGNED 分片无法分配的具体约束（节点过滤、磁盘水位、分片限额、禁用分配等）
• GET /_nodes/stats/fs&filter_path=nodes.*.fs.disk* —— 实时获取各节点磁盘使用率，验证是否触发 disk.watermark.high（默认 90%）阻塞

三、根因层：四大典型诱因与底层机制映射

诱因类型	配置/事件示例	ES 内部响应机制	关联错误码
分片数超限	cluster.max_shards_per_node: 1000，单节点承载 1024 个分片	集群状态更新失败 → 路由表无法收敛 → 写入请求被协调节点拒绝	429
节点离线	副本分片所在节点宕机，且无其他可用节点满足 allocation.required	主分片虽存活，但副本无法重建 → cluster.routing.allocation.enable=primaries 时仍可写，但若设为 none 则全阻断	503

四、治理层：从应急恢复到架构性预防

短期应急：

1. 临时提升限额：PUT /_cluster/settings { "persistent": { "cluster.max_shards_per_node": 2000 } }
2. 强制重分配：POST /_cluster/reroute?retry_failed=true
3. 释放磁盘：DELETE 过期索引或调高 disk.watermark.flood_stage

长期架构治理：

• 实施 ILM（Index Lifecycle Management）：自动滚动、收缩（shrink）、冻结（freeze）冷数据索引
• 分片容量守恒原则：单分片物理大小 ≤ 50GB（SSD）/ ≤ 20GB（HDD），避免查询延迟与恢复风暴
• 动态分配策略：PUT /_cluster/settings 启用 awareness.attributes 实现跨可用区容灾

五、可视化决策流：分片故障处置路径图

graph TD
  A[写入失败：429/503] --> B{检查 _cat/shards?v&s=state}
  B -->|存在 UNASSIGNED| C[_cluster/allocation/explain]
  B -->|全 STARTED| D[检查 bulk queue & thread pool]
  C --> E[磁盘水位过高？]
  C --> F[节点下线？]
  C --> G[分片限额超？]
  C --> H[allocation.enable=none？]
  E --> I[清理磁盘或调参]
  F --> J[恢复节点或 reroute]
  G --> K[删除冗余索引或扩容]
  H --> L[启用分配：PUT _cluster/settings {\"transient\":{\"cluster.routing.allocation.enable\":\"all\"}}]

六、反模式警示：高频踩坑场景清单

• ❌ 单节点开发集群创建 10 主分片索引（应设为 1）
• ❌ 使用 index.number_of_replicas: 2 但在 2 节点集群中部署（需 ≥3 节点）
• ❌ 未配置 ILM，日志索引无限增长导致分片数线性爆炸
• ❌ 将 disk.watermark.low 设为 85%，但 high 仍为默认 90%，造成分配窗口过窄
• ❌ 在滚动更新期间禁用 allocation，升级后忘记恢复

七、进阶实践：基于 Rollover + Shrink 的弹性分片调控

对时序类索引（如 logs-2024.06.01），推荐以下生产级流程：

1. 定义 ILM 策略，设定 max_age: 7d 和 max_size: 50gb
2. 当日志索引达到阈值，自动 rollover 为 logs-2024.06.01-000002
3. 冷数据索引执行 POST /logs-2024.05.01/_shrink/logs-2024.05.01-shrunk，将 20 分片收缩为 5
4. 收缩后设置 "settings": {"number_of_replicas": 0} 节省资源

该模式使分片总数稳定可控，规避 cluster.max_shards_per_node 触顶风险。

```