最近在协助客户进行 Elasticsearch 到 Easysearch 的迁移时，发现大家最关心的问题是"当前版本能否直接使用快照迁移"。这个问题看似简单，但不同版本的答案差异较大。本文将基于实际测试经验，梳理各版本的迁移路径和注意事项。

迁移路径速览

根据源 ES 版本，可以直接对照下表选择迁移方案：

源 ES 版本	能否直接快照恢复	推荐方案	实施复杂度
ES 6.x	否	INFINI Gateway 迁移 或 ES 7.10.x 中转	较低
ES 7.0 - 7.11	是	直接快照恢复	较低
ES 7.12 - 7.17	否	INFINI Gateway 迁移	较低
ES 8.x	否	INFINI Gateway 迁移	较低

结论：ES 7.0-7.11 是迁移最顺畅的版本窗口，可直接快照恢复；其他版本也有成熟的迁移方案，只是路径不同。

版本差异的原因

迁移路径的差异主要源于两方面：Lucene 版本兼容性和快照元数据格式变化。

Lucene 兼容性：Easysearch 2.x 底层要求的最低 Lucene 版本对应 ES 7.0.0。ES 6.x 的索引文件使用老版本 Lucene，直接恢复会报错：

The index was created with version [6.8.23] but the minimum compatible version is [7.0.0].

快照元数据格式：ES 7.12 开始在快照中引入 uuid、cluster_id 字段，7.14 增加 writer_uuid，8.x 又引入 transport_version。这些字段与 Easysearch 2.x 的快照解析器不兼容。

因此，ES 7.0-7.11 成为迁移的"黄金窗口"——既满足 Lucene 兼容性要求，快照格式又足够简洁。

ES 7.0-7.11：直接快照恢复

这是测试最充分的迁移路径，已验证版本包括 ES 7.0.1、7.8.1、7.10.2 OSS、7.11.2。

已验证能力：

• 单索引 / 多索引 / 通配符批量恢复
• 常见字段类型与别名
• 自定义 settings、多分片索引
• ILM 托管索引、数据流后备索引、冻结索引

操作步骤：

# 1. 源 ES 创建快照
PUT /_snapshot/my_backup/snapshot_1
{
  "indices": "索引列表",
  "include_global_state": false
}

# 2. Easysearch 注册同一快照仓库
PUT /_snapshot/my_backup
{
  "type": "fs",
  "settings": {
    "location": "/path/to/snapshot/repo",
    "readonly": true
  }
}

# 3. 恢复快照
POST /_snapshot/my_backup/snapshot_1/_restore
{
  "indices": "索引列表",
  "include_global_state": false
}

ES 6.x：Gateway 迁移或中转方案

ES 6.x 无法直接快照恢复到 Easysearch 2.x，有两种迁移方案可选：

方案一：INFINI Gateway 迁移（推荐）

直接使用 Gateway 从 ES 6.x 迁移数据到 Easysearch，无需中转集群。Gateway 已验证支持 ES 6.8.x 的数据迁移。

方案二：ES 7.10.x 中转

ES 6.8 -> 快照 -> ES 7.10.x -> 快照 -> Easysearch 2.x

ES 7.10.x 可以正常恢复 ES 6.x 的快照，恢复完成后再创建快照供 Easysearch 使用。该方案数据完整性有保障，但需要额外的中转存储和迁移窗口。

ES 6.x 特有字段：ES 6.x 的 string 类型在 Easysearch 中需映射为 text 或 keyword（根据实际使用场景选择）。

ES 7.12+ 和 8.x：INFINI Gateway 迁移

这两个版本段的快照格式与 Easysearch 2.x 不兼容，推荐使用 INFINI Gateway 进行迁移。Gateway 是 INFINI Labs 提供的数据迁移工具，专门针对 Elasticsearch 到 Easysearch 的迁移场景进行了优化。

架构示意

┌─────────────────┐      ┌─────────────────┐      ┌─────────────────┐
│  Elasticsearch  │ ──── │ INFINI Gateway  │ ──── │  Easysearch     │
│  （源集群）       │      │  （迁移工具）     │      │  （目标集群）     │
└─────────────────┘      └─────────────────┘      └─────────────────┘

Gateway 内部通过 Scroll API 从源集群分批拉取数据，再通过 Bulk API 写入目标集群，整个过程对业务透明。

主要优势

• 配置简单：只需配置源集群和目标集群地址、索引名称即可
• 断点续传：支持从断点恢复，避免网络抖动导致重头再来
• 进度可视：实时显示迁移进度和速率
• 多索引并行：支持同时迁移多个索引

基本步骤

1. 在目标集群创建索引的 mapping 和 setting
2. 准备 Gateway 配置文件，填写源集群和目标集群连接信息
3. 运行 Gateway 执行迁移
4. 迁移完成后进行数据校验

详细的配置说明和操作示例，可参考 ES 数据迁移之 INFINI Gateway。

备选方案

如果需要更灵活的控制，也可以自行编写脚本，通过 Scroll API 读取源数据、Bulk API 写入目标。这种方式适合有定制化需求的场景，但需要自行处理断点续传、错误重试等逻辑。

字段类型兼容性

直接兼容类型：text、keyword、long、double、boolean、date、object、nested、geo_point、geo_shape、ip、completion、wildcard、flattened、alias、join、rank_feature、rank_features、integer_range、long_range、date_range、match_only_text 等。

ES 7.x / 8.x 需替换类型：

ES 类型	Easysearch 替代方案	数据保留	说明
dense_vector	knn_dense_float_vector	是	需安装 knn 插件，向量数据格式兼容
knn_vector	knn_dense_float_vector	是	需安装 knn 插件
sparse_vector	knn_sparse_bool_vector	是	需安装 knn 插件
constant_keyword	keyword	是	需手动维护常量值
runtime	移除或转为普通字段	是	Easysearch 不支持运行时字段
histogram	object	是	聚合 histogram 功能丢失
aggregate_metric_double	object	是	需手动计算聚合
unsigned_long	long 或 keyword	是	注意数值范围
semantic	暂不支持	-	ES 专有 AI 功能

向量迁移要点：ES 的 dense_vector 数据可直接迁移到 Easysearch 的 knn_dense_float_vector，数据格式 [0.1, 0.2, ...] 完全兼容。需预先在目标索引创建正确的 mapping。

建议迁移前先用小索引测试，确认 mapping 无问题后再全量迁移。

常见问题与避坑指南

1. include_global_state 参数设置

该参数控制是否恢复集群级配置（模板、ILM 策略等）。不同版本的情况：

ES 版本	发行版	global_state	说明
7.0-7.7	任意	兼容	无 _index_template API
7.8-7.10	OSS	兼容	无内置 _index_template
7.8-7.10	default	可能不兼容	取决于是否使用 _index_template
7.11+	任意	不兼容	有 9 个内置 _index_template

建议：迁移时统一使用 include_global_state=false，先恢复数据再重建配置。

2. ILM 和 data stream 迁移

• ILM：索引的 lifecycle 设置保留，但 policy 需在 Easysearch 中重建
• 数据流 (data stream)：后备索引 (backing index) 数据完整恢复，语义需在目标侧重建
• 冻结索引 (frozen index)：自动恢复为普通可访问状态

3. 迁移验收标准

建议至少完成三项验证：

• 文档量一致
• 关键查询结果一致
• 核心业务链路压测通过

4. 迁移窗口规划

• 快照方案通常需要短停机窗口完成切换
• Gateway 迁移可实现近实时同步，仅在切换连接时短暂停服

快照格式变化参考

字段	ES 7.0-7.11	ES 7.12-7.17	ES 8.x	Easysearch 2.x
min_version	7.9.0 或无	7.12.0	7.12.0	支持
uuid（仓库级）	无	有	有	不支持
cluster_id	无	有	有	不支持
writer_uuid	无	有（7.14+）	有	不支持
transport_version	无	无	有	不支持

总结

本文梳理了 Easysearch 2.x 对 ES 6/7/8 的迁移路径：

• ES 7.0-7.11：直接快照恢复，路径最短
• ES 6.x：INFINI Gateway 迁移 或 ES 7.10.x 中转
• ES 7.12+ / 8.x：使用 INFINI Gateway 迁移

建议在正式迁移前，先选择非核心索引进行小规模验证，确认数据完整性和业务兼容性后再扩大迁移范围。

如有迁移相关问题，欢迎联系我们。

背景

1.有个向量搜索相关需求，选择使用ES8版本，并且在k8s环境中容器化部署； 2.考虑核心程度以及成本问题，不需要准备多数据中心的备份集群，为了保证数据可靠性，预期使用snapshot备份能力；

选型

ES支持将snapshot存储到各种存储产品，例如 fs(本地)、S3（或者ceph）、hdfs等。 1.OSS，考虑到已经和阿里云OSS有合作，且支持S3接口 -----> 测试 2.ceph，私有云部署，不好控制容量，成本偏高 --------> 暂不考虑 3.hdfs，私有云部署，不好控制容量，成本偏高，需要安装插件 -----> 暂不考虑 4.fs，本地，由于团队还在做juicefs产品，可以juicefs挂载到本地目录，ES snapshot 存到本地目录即可完成上传到公有云OSS ------> 测试

snapshot直接从ES传到OSS

1.创建账号、bucket，获取ak/sk；

略

2.ES容器实例如何加载密钥库

通过官方文档可知需要执行如下命令：将密钥设置到ES密钥库 https://www.elastic.co/guide/en/elasticsearch/reference/current/repository-s3.html

bin/elasticsearch-keystore add s3.client.default.access_key
bin/elasticsearch-keystore add s3.client.default.secret_key

考虑到容器环境不允许直接进入pod执行命令，secret也不允许直接写死到镜像中，则需要在entrypoint.sh中设置完成该命令。 最终方案如下：

1.在k8s环境中创建secret，记录ak/sk信息 2.pod创建时候mount到指定目录 3.container（ES）启动的时候读取指定目录信息，并执行elasticsearch-keystore命令

3.具体操作

0.安装 repository-s3 插件 略（ES8版本内置了该插件，无需安装）

1.创建secret

kubectl apply -f secret.yml

# cat secret.yml
apiVersion: v1
kind: Secret
metadata:
  namespace: uat-es
  name: es-snapshot-oss-secret
type: Opaque
data:
  access_key: xxx(注意base64编码)
  secret_key: xxx(注意base64编码)

2.修改crd的yaml，将该secret mount到指定目录

# 定义secret
  volumes:  
  - name: "oss-secret"
    secret: 
      secretName: "es-snapshot-oss-secret"

# 指定容器挂载选项
containers:
    ...
  volumeMounts:
  - mountPath: "/mnt/secret/oss"
    name: "oss-secret"
    readOnly: true

3.镜像修改 注：Dockerfile中最后是通过docker-entrypoint.sh完成ES实例的启动 ENTRYPOINT ["/usr/local/bin/docker-entrypoint.sh"]

# docker-entrypoint.sh 增加如下内容
/usr/share/elasticsearch/bin/elasticsearch-keystore create
chown root:root /usr/share/elasticsearch/config/elasticsearch.keystore
echo "$(</mnt/secret/oss/access_key)" | /usr/share/elasticsearch/bin/elasticsearch-keystore add --stdin s3.client.default.access_key
echo "$(</mnt/secret/oss/secret_key)" | /usr/share/elasticsearch/bin/elasticsearch-keystore add --stdin s3.client.default.secret_key
chown elasticsearch:elasticsearch /usr/share/elasticsearch/config/elasticsearch.keystore

1.可以看到先执行了 bin/elasticsearch-keystore create 命令，因为发行版的ES中config目录并没有elasticsearch.keystore文件，需要通过 bin/elasticsearch-keystore create 命令生成密钥库（即 config/elasticsearch.keystore 文件）；

注：如果不create，可以发现pod中最后也会生成密钥库，并且含有一个 seed 的密钥信息。该部分是ES启动时创建的，所以在启动之前必须create，否则执行bin/elasticsearch-keystore add 会触发一个密钥库不存在的异常； 2.可以看到先通过 chown root:root xxx 命令将config/elasticsearch.keystore文件的用户和group都设置成了root，执行完成命令后将其改回elasticsearch，因为bin/elasticsearch-keystore命令执行时对密钥库的权限有要求，pod启动是root用户，所以必须将该文件改成root权限，后续改成elasticsearch用户是为了保证container（ES）启动时的权限，ES的启动是使用elasticsearch用户； 注：该方式是在ES启动之前先将密钥加载到密钥库，ES提供另一个方式，允许在ES启动后执行 elasticsearch-keystore add 命令后再 reload，也能生效，这里不讨论。

4.测试创建repository、snapshot命令

# 创建repository
# 注：对象存储OSS不允许出现对象name中带 “/” ，所以 base_path 中 “-” 表示层级
PUT _snapshot/zmc_test_oss_repository
{
  "type": "s3",
  "settings": {
    "bucket": "es-snapshot",
    "endpoint": "http://dataplatform.xxxx.com",
    "base_path":"user-elasticsearch-uat-1067"
  }
}

# 创建snapshot
PUT /_snapshot/zmc_test_oss_repository/snapshot_1?wait_for_completion=true
{
  "indices": "zmc",
  "ignore_unavailable": true,
  "include_global_state": false,
  "metadata": {
    "taken_by": "zmc",
    "taken_because": "backup test"
  }
}
# 该命令异常：
amazon_s3_exception: Aws MultiChunkedEncoding is not supported. (Service: Amazon S3; Status Code: 400; Error Code: NotImplemented; Request ID: xxxxx; S3 Extended Request ID: es-snapshot.dataplatform.xxx.com

5.测试结果

很不幸，OSS暂时不支持MultiChunkedEncoding；（和OSS同学沟通后发现是 主集群暂时不支持，海外小集群已经支持该接口，后续会推到主集群） 这条路无法走通，继续测试其他方案；

snapshot存本地后通过juicefs上传OSS

juicefs是一个分布式文件系统，简言之就是通过juicefs程序可以将远程对象存储与本地目录关联，将文件写入本地即可上传到对象存储。该产品对ES而言比较适合作为snapshot的存储以及ES冷热分离架构中的冷数据存储。 juicefs有一定的维护成本，这里仅提供一种snapshot备份设计的新思路。对ES8而言更简要的方案可以考虑hdfs、ceph以及亚马逊的s3对象存储，弊端主要在成本和容量规划，体量较小或者公司支持较好则可以忽略。

预期架构如下：

可以看到从使用层面看ES只需将snapshot存在本地目录即可完成上公有云操作； juicefs部分只需从运维层面考虑，将进程打到镜像中、或者通过CSI、静态PVC的方式均可实现。图中元数据引擎是juicefs架构中的一环，从ES使用的角度看可以忽略； 此处juicefs可以替换成任何分布式共享存储。 ----------------------------end---------------------------------

1. Elasticsearch 如何做到快速检索 - 倒排索引的秘密 https://mp.weixin.qq.com/s/Mq7wPOUmF35LhyaLqWew3Q 2. filebeat 收集 syslog 并自动归类 https://www.jianshu.com/p/de7c2e0d5767 3. Elasticsearch 快照仓库的内部结构 https://mp.weixin.qq.com/s/fDFy-i7dHQ08NhPYDMwoQw   编辑：kin122 归档：https://ela.st/cn-daily-all 订阅：https://ela.st/cn-daily-sub 沙龙：https://ela.st/cn-meetup