OpenSearch 集群生产运维、分片治理与数据恢复

OpenSearch 集群的稳定性核心是分片。索引过多、分片过小、热点写入、磁盘水位、Heap 压力和错误的恢复操作，都会让集群从黄色迅速变成红色。本文专注 OpenSearch 集群本身，覆盖架构、容量、分片、性能、快照、升级和数据恢复，不重复日志采集平台内容。

allocate_stale_primary、allocate_empty_primary、强制 reroute 和直接删除索引都可能造成永久数据丢失。执行前必须确认快照、可用副本和业务影响，并优先使用 dry_run 与 explain。

一、理解节点与集群状态

常见节点角色：

  • Cluster Manager：维护集群状态和分片分配；
  • Data：存放分片并处理查询和写入；
  • Ingest：执行 Pipeline；
  • Coordinating：接收请求、分发并汇总；
  • Search/ML等专用角色。

小集群可混合角色，大规模生产建议将集群管理、数据和入口职责拆开，避免大查询或GC拖慢选举。

二、集群健康不只看颜色

curl -s http://localhost:9200/_cluster/health?pretty
curl -s http://localhost:9200/_cat/nodes?v
curl -s http://localhost:9200/_cat/indices?v
curl -s http://localhost:9200/_cat/shards?v
  • Green：主分片与副本都已分配；
  • Yellow：主分片可用，但至少一个副本未分配；
  • Red：至少一个主分片不可用，部分数据无法访问。

还应检查 pending tasks、active shards、relocating、initializing、unassigned、节点数量和最近选举。

三、分片容量模型

分片太多会增加 Heap、文件句柄、集群状态和恢复开销；分片太大则迁移、恢复和查询并行受限。没有适合所有场景的固定分片大小。

评估：

  • 每日写入量；
  • 保留周期；
  • 单文档大小；
  • 查询并发和时间范围；
  • 节点磁盘和网络；
  • 恢复时间目标；
  • 副本数量；
  • Segment 数量。

用 Index Template、ISM、Rollover 和 Data Stream 控制生命周期，避免每天无论数据量大小都创建固定数量分片。

四、主分片数量不可随意修改

索引创建后的主分片数不能直接修改，只能通过 reindex、split 或 shrink 等方式重构。上线前应按增长和恢复目标设计，并为未来 rollover 留出调整空间。

副本数可动态调整，但增加副本会占用磁盘和恢复带宽。单节点集群配置副本必然长期 Yellow。

五、分片未分配排查

curl -s -X GET http://localhost:9200/_cluster/allocation/explain?pretty \
  -H 'Content-Type: application/json' \
  -d '{}'

常见 decider：

  • disk_threshold：磁盘水位；
  • awareness：故障域约束；
  • same_shard：同一节点已有副本；
  • filter：include/exclude/require；
  • max_retry：重复恢复失败；
  • throttling：恢复并发限制；
  • node_version：版本不兼容；
  • snapshot_in_progress：快照阻止移动。

先解释为什么不分配，再处理根因。不要看到 Yellow 就反复 reroute。

六、磁盘水位

OpenSearch 根据 low、high、flood stage 水位控制分片分配和索引写入。达到 flood stage 时索引可能被设置只读保护。

curl -s http://localhost:9200/_cluster/settings?include_defaults=true&pretty
curl -s http://localhost:9200/_cat/allocation?v

处理顺序：

  1. 停止异常写入和大规模重试；
  2. 找到增长最快索引；
  3. 清理过期数据应通过索引生命周期和API；
  4. 扩容或迁移分片；
  5. 容量恢复后解除只读；
  6. 调整保留和告警。

不要直接删除节点数据目录释放空间。

七、Heap、GC与系统内存

Heap 主要承担集群状态、缓存、聚合和请求对象；Lucene 文件依赖操作系统页缓存。把全部内存分给 JVM 反而会降低性能。

监控：

  • Heap 使用和GC停顿；
  • Old Gen增长；
  • Circuit Breaker；
  • JVM线程；
  • Page Cache；
  • Swap；
  • 节点 OOM。

生产通常关闭 Swap 或严格控制交换。Heap 大小遵循官方和实际工作负载建议，不能简单随物理内存无限增大。

八、写入性能

影响写入的因素：

  • Bulk 大小和并发；
  • Refresh Interval；
  • 副本数；
  • Pipeline处理；
  • Mapping复杂度；
  • 动态字段爆炸；
  • Segment Merge；
  • 磁盘延迟；
  • 热点 Routing。

Bulk 不是越大越好。应按响应大小、队列、Heap和P99确定批次，并对 429 采用退避。

九、Mapping与字段治理

动态字段失控会扩大 Cluster State 和 Heap。应：

  • 使用显式模板；
  • 控制 total_fields.limit；
  • 区分 keyword 与 text；
  • 避免把唯一ID作为聚合字段；
  • 控制 nested 对象；
  • 对未知字段使用 flattened 等合适类型；
  • 版本化 Mapping；
  • 变更前验证兼容性。

字段类型不能原地随意更改，通常需要新索引和 Reindex。

十、查询与聚合排障

curl -s http://localhost:9200/_nodes/hot_threads
curl -s http://localhost:9200/_tasks?detailed=true&actions=*search

高风险查询：

  • 深分页；
  • 高基数字段聚合；
  • 前导通配符和复杂正则；
  • Script；
  • 大范围无时间过滤；
  • 大量 nested；
  • 返回超大 _source。

使用 Search After、Point in Time、Source Filtering 和聚合限制。不要依赖提高超时掩盖慢查询。

十一、热点分片

热点可能由单一 Routing、写入时间集中、分片不均或单个大客户造成。

检查：

curl -s http://localhost:9200/_cat/shards?v&s=store:desc
curl -s http://localhost:9200/_nodes/stats?pretty

治理可包括重新设计 Routing、增加合理主分片、Rollover、迁移热点、限制租户和拆分索引。新增节点不会自动解决不合理 Routing。

十二、Segment与Merge

写入先形成 Segment，后台 Merge 合并。大量小 Segment 会增加搜索和文件句柄；Merge 会消耗磁盘吞吐。

关注：

  • Segment 数量和内存；
  • Merge 时间与节流；
  • 磁盘吞吐；
  • Refresh频率；
  • Force Merge风险。

Force Merge 适合只读冷索引，不应在持续写入索引和高峰期随意执行。

十三、线程池与拒绝

curl -s http://localhost:9200/_cat/thread_pool?v

Search、Write、Get 等线程池出现 rejected 说明节点来不及处理。先治理请求、查询和容量，不要直接无限增大队列；大队列会把快速失败变成长时间超时，并增加内存压力。

十四、快照与恢复

快照是可靠备份方式，直接复制节点数据目录不是一致备份。

curl -X PUT http://localhost:9200/_snapshot/repository_name \
  -H 'Content-Type: application/json' -d '{...}'
curl -X PUT http://localhost:9200/_snapshot/repository_name/snapshot_name?wait_for_completion=false

快照为增量共享数据，删除必须使用 Snapshot API，不能直接删除存储后端文件。

恢复演练：

  1. 新建隔离集群；
  2. 注册只读仓库；
  3. 恢复指定索引；
  4. 验证文档量、时间范围、Mapping和查询；
  5. 记录恢复速度；
  6. 验证安全配置和别名。

十五、红色集群恢复

  1. 保存 health、allocation explain、节点与分片信息；
  2. 确认缺失主分片的数据副本；
  3. 检查节点是否临时离线、磁盘满或版本不兼容；
  4. 优先让含有效分片的原节点恢复；
  5. 若有快照，评估从快照恢复；
  6. 只有不存在有效副本和快照时才评估接受数据丢失的强制分配。

allocate_empty_primary 会创建空主分片，旧数据可能被覆盖，应作为最后手段并经过业务批准。

十六、滚动升级

升级前：

  • 阅读版本兼容和弃用；
  • 完成快照并验证；
  • 集群 Green；
  • 预留磁盘和恢复带宽；
  • 插件与客户端兼容；
  • 先升级非Cluster Manager节点；
  • 每个节点回归后等待稳定。

可延迟分片分配避免短暂重启触发大规模恢复，但升级后必须恢复设置。混合版本只应存在于升级窗口。

十七、安全治理

  • TLS保护节点间与客户端通信；
  • 管理账号和应用账号分离；
  • 索引、文档和字段级权限按需启用；
  • Dashboard不暴露公网；
  • 审计日志脱敏；
  • 快照仓库凭据最小权限；
  • 禁止应用访问危险集群API；
  • 定期轮换证书和密钥。

十八、监控清单

  • 集群状态、节点和选举；
  • 主/副分片、Unassigned和Relocation；
  • 磁盘水位和增长；
  • Heap、GC、Circuit Breaker和OOM；
  • 写入/查询速率、P95/P99和拒绝；
  • Bulk失败和429；
  • Segment、Merge、Refresh和Flush；
  • 快照成功、时长和仓库容量；
  • Thread Pool、Pending Task和Hot Thread；
  • 每租户用量与热点。

十九、上线检查清单

  • [ ] Cluster Manager节点和故障域合理；
  • [ ] 索引模板、Rollover和保留策略已定义；
  • [ ] 分片大小、数量和副本经过容量验证；
  • [ ] Mapping受控，防止字段爆炸；
  • [ ] Bulk、查询和租户有并发与限流；
  • [ ] 磁盘水位、Heap、拒绝和分片异常有告警；
  • [ ] 快照仓库独立并通过恢复演练；
  • [ ] 滚动升级和插件兼容经过验证；
  • [ ] 危险API被权限控制和审计；
  • [ ] Red、节点丢失、磁盘满和热点场景已演练。

二十、结语

OpenSearch 运维的核心是让分片数量、磁盘空间、Heap和查询成本保持在可恢复边界内。出现异常时先解释分片为什么不能分配，再修复根因；真正的数据保护依靠快照和恢复演练，而不是复制数据目录或依赖副本永远存在。

参考资料

Copyright © yan-jian.com 2023 - 2026 · Powered by GitBook更新时间： 2026-10-29 20:20:34

results matching ""

    No results matching ""