Elasticsearch滚动升级实战手记：一次零停机升级背后的27个关键决策点
去年冬天，我们为支撑某头部电商平台大促日志分析的ES集群做了7.17→8.13滚动升级。整个过程持续了43小时，覆盖127个数据节点、3.2PB索引数据、日均写入480亿文档——没有一次5xx错误，没有一个告警被抑制，Kibana仪表盘始终绿色在线。
这背后不是靠运气，而是27个被反复验证、踩过坑、改过三版脚本的真实决策点。今天不讲“应该怎么做”，只说“当时为什么这么选”。
从第一个curl命令开始：滚动升级的本质是状态协商，不是进程替换
很多人以为滚动升级就是“停一个、换一个、起一个”。但当你在生产环境执行第一条curl -X PUT /_cluster/settings时，真正的挑战才刚开始。
Elasticsearch的滚动升级，本质上是一场集群状态机与节点生命周期的精密协奏。它不像单体应用重启那样简单粗暴，而更像一支交响乐团：主节点是指挥，数据节点是乐手，分片是音符，而你的allocation.exclude._name命令，只是递给某位小提琴手一张临时休止符。
关键在于：ES不会等你准备好才行动。一旦你禁用某个节点的分片分配，集群立刻开始重算全局路由表；一旦你停止那个节点，master会在1秒内发起新的主分片选举；而当你重启它，新版本节点会带着全新的协调协议握手包加入——如果配置稍有偏差，它可能被直接拒之门外，变成一个“幽灵节点”：活着，但不被承认。
所以真正的起点，不是systemctl stop，而是这条命令：
curl -s "localhost:9200/_cat/nodes?v&h=name,ip,version,role,heap.percent" | grep -E "(data|master)"你要亲手确认：
✅ 所有master-eligible节点角色标识正确（mlmasterdata不能混用）
✅ JVM堆使用率全部低于65%（高于70%时，8.x的G1GC会频繁触发mixed GC，拖慢迁移）
✅ 没有节点IP显示为127.0.0.1（这是本地回环，说明network.host未正确绑定，升级后将无法加入集群）
这不是检查清单，这是你和集群建立信任的第一步。
兼容性不是“能跑就行”，而是“每个字节都得对上”
官方文档里那句“仅支持相邻主版本”听起来很安全，但现实要残酷得多。
我们在预检阶段发现一个致命细节：7.17.9创建的索引，在8.13中能打开，但无法执行_update_by_query。报错信息极其隐蔽：
{"error":{"root_cause":[{"type":"illegal_argument_exception","reason":"cannot upgrade index [logs-2023-12] from version [7.17.9] to [8.13.4] because it contains legacy field mappings"}]}
