130TB级Elasticsearch集群无停机迁移实战：从2.x到5.x的平滑升级

前言

在大型分布式系统中，数据存储的升级迁移一直是个极具挑战性的任务。本文将深入剖析一个真实案例：如何将130TB规模、包含1000亿文档的Elasticsearch集群从2.x版本平滑升级到5.x版本，整个过程仅耗时20小时且实现了零停机。这个案例来自一个名为"Blackhole"的生产集群，它承载着企业核心业务数据。

集群概况

基础设施配置

Blackhole集群由77个节点组成，具体配置如下：

• 存储总量：200TB
• 内存总量：4.8TB（其中2.4TB分配给JVM）
• CPU核心：924个
• 节点组成：3个master节点、6个ingest节点、68个data节点

数据规模

• 索引数量：1137个
• 主分片数量：13613个（每个索引配置1个副本）
• 文档总量：2010亿
• 写入吞吐：约7000文档/秒
• 查询吞吐：约800次搜索/秒（全数据集）

架构设计

集群采用双数据中心部署，通过rack awareness（机架感知）确保每个数据中心都保存100%的数据副本，实现高可用性。ingest节点同样采用机架感知，使查询优先在同一机架内执行，最大限度降低延迟。

迁移策略评估

在Elasticsearch大版本升级时，通常有几种迁移策略可选：

1. 集群重启策略

原理：关闭所有索引→升级软件→重启节点→重新打开索引 优点：操作简单直接 缺点：需要停机维护，且保留2.x格式的索引会阻碍后续升级到6.x

2. Reindex API策略

原理：使用Elasticsearch内置的reindex API重建索引 优点：官方推荐方式 缺点：

• 错误处理不够完善
• 性能较低（依赖scroll API）
• 存在数据一致性问题（源集群更新可能导致竞态条件）

3. Logstash策略

原理：通过Logstash管道进行数据迁移 优点：比reindex API更快 缺点：

• 可靠性问题
• 错误排查困难
• 同样存在数据一致性问题

4. 创新方案：集群分裂+硬件扩容

核心思想：通过临时扩容硬件资源，将原集群"分裂"为两个独立集群，实现无缝迁移 优势：

• 真正零停机
• 随时可回滚
• 可更换老旧硬件 代价：需要临时增加硬件资源

迁移实施详解

第一阶段：集群扩容

首先将集群规模扩大一倍，新增90台服务器：

• 配置：6核Xeon E5-1650v3 CPU/64GB RAM/2*1.2TB NVMe(RAID0)
• 部署：Debian Stretch + Elasticsearch 2.3
• 网络：使用专用IP段，避免与现有集群冲突

扩容后关键参数调整：

# 将副本数从1增加到3
curl -XPUT "localhost:9200/*/_settings" -H 'Content-Type: application/json' -d '{
    "index" : {
        "number_of_replicas" : 3
    }
}'

第二阶段：性能调优

为加速数据迁移，优化集群参数：

cluster:
  routing:
    allocation:
      disk:
        watermark.low : "98%"
        watermark.high : "99%"
    rebalance.enable: "none"

indices:
  recovery:
    max_bytes_per_sec: "4096mb"
    concurrent_streams: 50

第三阶段：应对性能瓶颈

在迁移130TB数据时遇到CPU负载飙升至40，iowait达60%的情况。解决方案是创建专用zone处理当日数据：

# 1. 暂停分配
curl -XPUT "localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d '{
    "transient" : {
        "cluster.routing.allocation.enable" : "none"
    }
}'

# 2. 将非当日数据移出fresh zone
curl -XPUT "localhost:9200/*/_settings" -H 'Content-Type: application/json' -d '{
    "index.routing.allocation.exclude.zone" : "fresh"
}'

# 3. 将当日数据限定在fresh zone
curl -XPUT "localhot:9200/latest/_settings" -H 'Content-Type: application/json' -d '{
    "index.routing.allocation.exclude.zone" : "",
    "index.routing.allocation.include.zone" : "fresh"
}'

第四阶段：集群分裂

1. 全局禁用分片分配
2. 关闭Barack和Chirack机架节点及一个master节点
3. 将副本数降回1
4. 将被移除的master节点重新配置为新集群
5. 升级新集群Elasticsearch版本至5.x
6. 关闭所有索引
7. 启动新集群master节点完成版本升级
8. 启动data节点并重新启用分配

第五阶段：数据同步

通过记录Kafka offset，新增消费组将数据同时写入新旧集群，确保数据一致性。

经验总结

1. 硬件资源：临时扩容虽然增加成本，但提供了安全网和测试环境
2. 分区策略：通过zone划分实现热点隔离，保证核心业务不受迁移影响
3. 回滚机制：完整保留旧集群直到验证完成，最大程度降低风险
4. 性能监控：实时关注CPU、IO等指标，及时调整参数
5. 数据一致性：通过消息队列offset确保无数据丢失

这次迁移不仅完成了版本升级，还实现了硬件更新，为后续的性能优化和功能扩展奠定了基础。整个过程充分体现了"通过硬件换稳定性"的运维哲学，在关键业务系统中，这种投入往往是值得的。