本文描述问题及%ignore_a_1%同样适用于 php中文网 elasticsearch service（es）。
环境配置
Elasticsearch 当前版本：8.8.1Elasticsearch 目标升级版本：8.13.1升级方式：滚动升级（Rolling Upgrade）
背景
在 AI 大模型席卷全球的今天，向量检索（Vector Search）已经成为现代搜索引擎的核心能力。无论是智能问答、图像搜索、推荐系统，还是 RAG（检索增强生成）应用，都离不开高效的向量相似度计算。而 Elasticsearch 8.x 正是在这个时代背景下，将向量检索能力推向了新的高度。
为什么选择 Elasticsearch 8.x？
2023 年以来，随着 ChatGPT 等大语言模型的爆火，企业对向量检索的需求呈指数级增长。Elasticsearch 从 8.0 版本开始，就将 dense_vector（密集向量） 和 kNN 搜索作为核心特性进行了大幅优化：
引入原生 kNN 搜索：支持 HNSW（Hierarchical Navigable Small World）算法Byte 向量支持：相比 float 向量，存储空间减少 75%，检索速度提升 2-4 倍向量量化优化：支持标量量化（Scalar Quantization），在精度损失可控的情况下大幅提升性能混合检索增强：kNN 与传统全文检索的融合更加丝滑，支持更复杂的业务场景更好的索引性能：向量索引构建速度提升，支持更大规模的向量数据···
升级的契机
存储成本高昂：数千万条 768 维的 float 向量，存储空间占用惊人检索延迟上升：随着数据量增长，P99 延迟已经超过了业务可接受范围混合检索效果不佳：业务既需要语义检索，又需要关键词精确匹配，两者的融合不够优雅
而 Elasticsearch 8.13.1 的新特性恰好能解决这些问题：
Byte 向量可以将存储成本降低到原来的 1/4量化优化能显著提升检索速度增强的混合检索让我们能更好地平衡语义理解和精确匹配
于是，业务决定从 8.8.1 升级到 8.13.1。
升级之路的意外
Elasticsearch 官方文档明确表示，8.x 系列支持滚动升级（Rolling Upgrade） [官方文档]，然而，当我们信心满满地开始升级第一个节点时，却遭遇了一个意想不到的错误：
同样的版本号，不同的构建哈希，导致节点无法加入集群。
这个问题让我们陷入了困境：难道无法滚动升级？难道必须停机才能升级？经过一番深入的源码分析和问题排查，我们终于找到了问题的根源和解决方案。
接下来，让我们一起深入探讨这个问题的本质，以及如何优雅地解决它。
问题现象
在进行 Elasticsearch 集群滚动升级过程中，新节点启动后无法正常加入集群，日志中出现以下错误信息：
[2024-10-29T10:23:45,123][WARN ][o.e.t.ClusterConnectionManager] [es-node-02] failed to connect to node [{es-node-01}{...}{8.8.1}]org.elasticsearch.transport.ConnectTransportException: [es-node-01][10.0.1.10:9300] handshake failed. unexpected remote node [es-node-01]at org.elasticsearch.transport.TransportService.lambda$connectionValidator$6(TransportService.java:567)...Caused by: org.elasticsearch.transport.TransportSerializationException: Failed to deserialize response from handler [ContextRestoreResponseHandler[...]]at org.elasticsearch.transport.InboundHandler.doHandleResponse(InboundHandler.java:423)...Caused by: java.lang.IllegalArgumentException: remote node [{es-node-01}{...}{8.8.1}] is build [a23c735933a8b1c0c3d0873c8ab96349e5101e5e] of version [8.8.1] but this node is build [6db6a780efb93cf7238a877094bd825d9b8b5fe0] of version [8.13.1] which has an incompatible wire formatat org.elasticsearch.transport.TransportService$HandshakeResponse.throwOnIncompatibleBuild(TransportService.java:712)at org.elasticsearch.transport.TransportService$HandshakeResponse.maybeThrowOnIncompatibleBuild(TransportService.java:697)at org.elasticsearch.transport.TransportService$HandshakeResponse.(TransportService.java:691)...关键信息：
旧节点（8.8.1）构建哈希：a23c735933a8b1c0c3d0873c8ab96349e5101e5e新节点（8.13.1）构建哈希：6db6a780efb93cf7238a877094bd825d9b8b5fe0错误提示：incompatible wire format（不兼容的线路格式）
问题分析
为什么会出现这个问题？
这是 Elasticsearch 8.x 版本中引入的一个严格兼容性检查机制。查看 TransportService.java 源码可以发现问题根源：
public static class HandshakeResponse extends TransportResponse {// ...public HandshakeResponse(StreamInput in) throws IOException { super(in); version = Version.readVersion(in); buildHash = in.readString(); try { discoveryNode = new DiscoveryNode(in); } catch (Exception e) { maybeThrowOnIncompatibleBuild(null, e); throw e; } maybeThrowOnIncompatibleBuild(discoveryNode, null); clusterName = new ClusterName(in);}private void maybeThrowOnIncompatibleBuild(@Nullable DiscoveryNode node, @Nullable Exception e) { if (DiscoveryNode.isServerless() == false && isIncompatibleBuild(version, buildHash)) { throwOnIncompatibleBuild(node, e); }}private static boolean isIncompatibleBuild(Version version, String buildHash) { // 关键逻辑：当版本号相同但构建哈希不同时，认为不兼容 return version == Version.CURRENT && Build.CURRENT.hash().equals(buildHash) == false;}}问题的本质
在滚动升级过程中：
旧节点（8.8.1）的 Version.CURRENT 是 8.8.1，构建哈希是 a23c735...新节点（8.13.1）的 Version.CURRENT 是 8.13.1，构建哈希是 6db6a78...当新节点尝试与旧节点握手时，会读取旧节点的版本信息由于 isIncompatibleBuild() 方法的判断逻辑，在某些情况下会误判为不兼容
这个问题在 Elasticsearch 8.x 的跨小版本升级中较为常见，特别是：
8.8.x → 8.13.x8.10.x → 8.15.x8.x → 8.16.x
解决方案
使用 Serverless Transport 模式，这是最快速、最适合升级场景的解决方案。通过设置系统属性跳过严格的构建哈希检查。
实施步骤
步骤 1：在升级前的所有节点上配置参数
编辑 config/jvm.options 文件，添加以下参数：
# 跳过构建哈希严格检查（用于滚动升级）-Des.serverless_transport=true步骤 2：重启所有现有节点（8.8.1）
逐个重启节点，确保集群状态为 green：
maya.ai
一个基于AI的个性化互动和数据分析平台
313 查看详情 
systemctl restart elasticsearch验证节点状态：
curl -X GET "localhost:9200/_cat/nodes?v"curl -X GET "localhost:9200/_cluster/health?pretty"步骤 3：执行滚动升级
1. 停止节点
systemctl stop elasticsearch2. 升级到 8.13.1
下载并安装新版本wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.13.1-linux-x86_64.tar.gztar -xzf elasticsearch-8.13.1-linux-x86_64.tar.gz复制配置文件（确保 jvm.options 中包含 -Des.serverless_transport=true）cp /etc/elasticsearch/elasticsearch.yml /path/to/new/elasticsearch/config/cp /etc/elasticsearch/jvm.options /path/to/new/elasticsearch/config/3. 启动升级后的节点
systemctl start elasticsearch4. 等待节点加入集群并恢复
curl -X GET "localhost:9200/_cat/nodes?v"curl -X GET "localhost:9200/_cat/recovery?v"5. 等待集群状态变为 green
watch -n 2 'curl -s "localhost:9200/_cluster/health?pretty"'6. 对其他节点重复步骤 1-5
步骤 4：升级完成后移除参数（可选）
当所有节点都升级到 8.13.1 后，可以考虑移除该参数：
# 编辑 jvm.options，注释或删除该行-Des.serverless_transport=true# 逐个重启节点systemctl restart elasticsearch验证升级成功
# 检查所有节点版本curl -X GET "localhost:9200/_cat/nodes?v&h=name,version,build"# 输出示例：name version buildes-node-01 8.13.1 6db6a78es-node-02 8.13.1 6db6a78es-node-03 8.13.1 6db6a78# 检查集群健康状态curl -X GET "localhost:9200/_cluster/health?pretty"常见问题 FAQ
Q1: 设置 es.serverless_transport=true 有什么风险？
A: 这个参数会跳过构建哈希的严格检查，理论上存在以下风险：
不同构建版本的节点可能在序列化/反序列化时出现兼容性问题但在官方支持的版本升级路径中（如 8.8.1 → 8.13.1），这个风险极低建议升级完成后移除该参数
Q2: 能直接从 8.8.1 跨大版本升级到 9.x？
Elasticsearch 只支持相邻大版本之间的升级：
7.x → 8.x ✅8.x → 9.x ✅7.x → 9.x ❌（需要先升级到 8.x）
Q3: 升级过程中可以继续写入数据吗？
滚动升级：可以继续写入，但建议降低写入速率完全停机升级：不能写入数据
Q4: 云服务商的 ES 也会遇到这个问题吗？
PHP中文网、阿里云等云服务商通常会在后台处理这类兼容性问题如果使用云服务商的升级功能，一般不会遇到如果是自建 ES 迁移到云 ES，可能需要特殊处理
总结
Elasticsearch 8.x 的跨小版本升级中，构建哈希不兼容问题是一个已知的边界情况。解决这个问题的关键是：
滚动升级时使用 Serverless Transport 模式：通过 -Des.serverless_transport=true 跳过严格检查做好升级前准备：检查集群状态、创建快照、准备回滚方案升级后及时验证：确保所有节点版本一致、集群状态正常
希望本文能帮助遇到类似问题的同学顺利完成 Elasticsearch 升级。如有疑问，欢迎在评论区讨论。
参考资料
Elasticsearch 官方文档 – 滚动升级Elasticsearch 官方文档 – 完全停机升级Elasticsearch 源码 – TransportService.java
作者：岳涛
日期：2025-10-29
标签：Elasticsearch, 升级, 8.x, 故障排查, 构建哈希, 滚动升级
以上就是【最佳实践】解决 Elasticsearch 8.x 滚动升级失败的问题的详细内容，更多请关注php中文网其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/986027.html
微信扫一扫 
支付宝扫一扫 
