【最佳实践】解决 Elasticsearch 8.x 滚动升级失败的问题-人工智能-PHP中文网

【最佳实践】解决 Elasticsearch 8.x 滚动升级失败的问题

雪夜

发布： 2025-11-26 14:35:02

原创

503人浏览过

本文描述问题及解决方法同样适用于 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 集群滚动升级过程中，新节点启动后无法正常加入集群，日志中出现以下错误信息：

<code class="txt">[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.<init>(TransportService.java:691)...</code>

登录后复制

关键信息：

旧节点（8.8.1）构建哈希：a23c735933a8b1c0c3d0873c8ab96349e5101e5e新节点（8.13.1）构建哈希：6db6a780efb93cf7238a877094bd825d9b8b5fe0错误提示：incompatible wire format（不兼容的线路格式）

问题分析

为什么会出现这个问题？

这是 Elasticsearch 8.x 版本中引入的一个严格兼容性检查机制。查看 TransportService.java 源码可以发现问题根源：

<code class="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;}}</code>

登录后复制

问题的本质

在滚动升级过程中：

旧节点（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 文件，添加以下参数：

<code class="bash"># 跳过构建哈希严格检查（用于滚动升级）-Des.serverless_transport=true</code>

登录后复制

步骤 2：重启所有现有节点（8.8.1）

逐个重启节点，确保集群状态为 green：

新CG儿

数字视觉分享平台 | AE模板_视频素材

412

查看详情

<code class="bash">systemctl restart elasticsearch</code>

登录后复制

验证节点状态：

<code class="bash">curl -X GET "localhost:9200/_cat/nodes?v"curl -X GET "localhost:9200/_cluster/health?pretty"</code>

登录后复制

步骤 3：执行滚动升级

1. 停止节点

<code class="bash">systemctl stop elasticsearch</code>

登录后复制

2. 升级到 8.13.1

<code class="bash">下载并安装新版本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/</code>

登录后复制

3. 启动升级后的节点

<code class="bash">systemctl start elasticsearch</code>

登录后复制

4. 等待节点加入集群并恢复

<code class="bash">curl -X GET "localhost:9200/_cat/nodes?v"curl -X GET "localhost:9200/_cat/recovery?v"</code>

登录后复制

5. 等待集群状态变为 green

<code class="bash">watch -n 2 'curl -s "localhost:9200/_cluster/health?pretty"'</code>

登录后复制

6. 对其他节点重复步骤 1-5

步骤 4：升级完成后移除参数（可选）

当所有节点都升级到 8.13.1 后，可以考虑移除该参数：

<code class="bash"># 编辑 jvm.options，注释或删除该行-Des.serverless_transport=true# 逐个重启节点systemctl restart elasticsearch</code>

登录后复制

验证升级成功

<code class="bash"># 检查所有节点版本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"</code>

登录后复制