将 Elasticsearch 从 1.4.4 升级到 2.3.4 时，我遇到的变化不只在服务端，还包括 JDK、运行账户、发现配置、插件与 Java 客户端。一次升级涉及这些层次，就需要把它们作为同一条兼容链路验证。
为旧版本组合准备独立环境
当时从 OpenJDK 7 调整到 JDK 8，并为 Elasticsearch 单独配置 Java 运行环境，避免影响机器上的其他服务。运行参数应通过发行包支持的配置入口设置，不随意修改随升级被覆盖的启动脚本。
服务使用专用账户，确认数据、日志和配置目录权限。不使用绕过 root 限制的方法代替正确的运行用户配置。
配置文件必须符合版本语法
下面是 2.3.4 环境中的配置形式，不适用于后续更改发现机制的版本：
cluster.name: demo-search
node.name: node-1
network.host: 192.0.2.10
discovery.zen.ping.unicast.hosts: ["192.0.2.11", "192.0.2.12"]
示例地址需要替换。顶级键不要求统一加前导空格；冒号后保留空格，嵌套结构则按 YAML 规则缩进。同一集群名称一致，节点名称区分开，并确认成员可以相互通信。
客户端和插件也要一起验证
我遇到过传输协议相关异常，处理过程中需要检查仍在连接旧环境的 Java 客户端。错误本身不只对应一种原因，先确认端口、服务端与客户端版本以及实际加载的依赖，再判断是否为版本错配。
代码中的 ImmutableSettings、查询构造器等 API 发生变化时，应按目标版本编译并做查询回归。2.x 将 delete-by-query 作为插件提供，也不意味着所有其他删除方式都消失了；危险删除操作应先确认范围，不能靠反复重试插件安装解决不兼容。
迁移路径与回退提前确定
升级前先验证索引兼容、快照恢复和所需插件。选择目标版本支持的升级方式，不能随意把新旧节点加入同一集群；回退也不等于让旧二进制直接读取已升级的数据目录。
用有代表性的数据验证索引、查询、聚合、排序和删除，检查耗时、错误率及结果差异。只有应用和运维链路一起通过，升级才算结束。