最近很多朋友 #升级Dify 后，遇到了 #知识库报错 的问题，故特制了一期教程。

[!warning] 重大更新
新的 weaviate-client v4 与低于 1.27.0 的 Weaviate 服务器版本不向下兼容。如果您正在运行版本为 1.19.0 或更早版本的自托管 Weaviate 实例，则必须先升级 Weaviate 服务器，然后再升级 Dify。

版本兼容表

Dify版本	Weaviate客户端版本	兼容的 Weaviate 服务器版本
≤ 1.9.1	v3.x	1.19.0 - 1.26.x
≥ 1.9.2	v4.17.0	1.27.0+（已测试至 1.33.1）

前言

你的Dify多久没更新了？

如果你从 v1.9.1 之前的版本，来升级1.9.2之后的版本，这篇教程将对你有所帮助。
因为我是从v1.7.1 --> v1.11.1，发生了 知识库检索报错

Query call with protocol GRPC searchfailed with message extract targetvectors: class
Vector_index_3a85cb7f bd1d 49a6 bbf6b1419b45f5bc_Node does not havenamed vector default configured.Available named vectors map[].

weaviate是什么

Dify知识库的向量存储，默认选用的 “weaviate” 向量数据库。
#vector_index 报错，务必检查 weaviate容器的挂载卷 /docker/volumes/weaviate 下的内容。

weaviate迁移方案

尝试过手动备份等踩雷操作，才找到官方提供的一个解决方案：包含以下内容

• 什么样的用户 需要升级？（Who）
• 升级有哪些好处？（Why）
• 如何升级&迁移？（How）
  

迁移方案有如下两个：

• 方案A：（旧w还在运行）A1.启用备份 + A2.创建备份 + A3.升级+ A4.数据修复 + A5.迁移Schema
• 方案B：（新w已经运行）B1.数据修复 + B2.迁移Schema
  

注：方案A中的备份，不是直接tar压缩的常规备份，而是启用weaviate的bakup模块进行备份。但是bakup数据在步骤A4、A5中并未使用，而且我是在一台新机器上部署新Dify，只需要常规备份&迁移旧Dify的数据。所以本教程是方案A的流程，但和Dify官方的Weaviate迁移指南会有部分出入，如果你也在操作 tar -cvf volumes-$(date +%s).tgz volumes 之后才遇到这个问题，本教程也适用。

本教程的流程：

1. 常规备份 tar
2. Weaviate升级1.27
3. 修复数据
4. 迁移Schema

#Dify迁移指南 #知识库报错修复 #Weaviate升级 #dify数据迁移脚本 #版本兼容性

---

1.常规备份

在旧Dify上，停止服务

cd docker
docker compose down

选一个格式，备份 volumes 数据

# 格式1.Unix时间戳
tar -cvf volumes-$(date +%s).tgz volumes

# 格式2.年月日时分
# tar -cvf volumes-$(date +%Y%m%d%H%M).tgz volumes

备份数据传送到新机器，复制过去，或scp传送

# scp语法：[scp 本地文件 用户名@新服务器ip:路径]
scp volumes-202512221120.tgz gong@192.168.1.12:/path/to/dify/docker

2.升级1.27

在新机器，拉取最新版Dify，备份数据解压缩

cd /path/to/dify/docker
tar -cvf volumes-202512221120.tgz

在docker-compose.yaml中，确认Weaviate镜像 是 1.27.0。并开启映射端口8080和50051。

services:
  weaviate:
    image: semitechnologies/weaviate:1.27.0

!!!先别开启Dify服务，如果开启过，请重新解压缩volumes
!!!先别开启Dify服务，如果开启过，请重新解压缩volumes
!!!先别开启Dify服务，如果开启过，请重新解压缩volumes

3.修复孤立的 LSM 数据

cd到weaviate目录

cd /path/to/dify/docker/volumes/weaviate

默认是有挂载卷的，用下面这份脚本

# 选项 A：从主机（如果卷已挂载）
for dir in vector_index_*_node_*_lsm; do
  [ -d "$dir" ] || continue

  index_id=$(echo "$dir" | sed -n 's/vector_index_\([^_]*_[^_]*_[^_]*_[^_]*_[^_]*\)_node_.*/\1/p')
  shard_id=$(echo "$dir" | sed -n 's/.*_node_\([^_]*\)_lsm/\1/p')

  mkdir -p "vector_index_${index_id}_node/$shard_id/lsm"
  cp -a "$dir/"* "vector_index_${index_id}_node/$shard_id/lsm/"

  echo "✓ Copied $dir"
done

4.迁移 Schema

cd到docker目录，安装python依赖

cd /path/to/dify/docker
pip install weaviate-client requests

下载py迁移脚本

wget https://github.com/langgenius/dify-docs/blob/main/assets/migrate_weaviate_collections.py

运行迁移脚本

python3 migrate_weaviate_collections.py

如果报错 Could not connect to Weaviate ，在脚本中找到 weaviate: ，将 weaviate: 改成 127.0.0.1:

WEAVIATE_ENDPOINT = os.getenv("WEAVIATE_ENDPOINT", "http://127.0.0.1:8080") # 原 weaviate:8080

WEAVIATE_GRPC_ENDPOINT = os.getenv("WEAVIATE_GRPC_ENDPOINT", "grpc://127.0.0.1:50051") # 原 weaviate:50051

再次运行脚本，运行日志如下

可以看到，包括创建新集合、迁移数据、验证迁移、替换旧集合以及清理临时集合等操作。最后一行显示整个迁移过程已完成，共迁移了 335 个集合。

整个过程时间会有点长，我这300+个至少运行了10分钟。

迁移成功

在Dify最新版v1.11.1上，知识库检索成功，历史对话也存在

你是否会有以下问题？

Q1. /docker/volumes/weaviate下还是小写的vector_index_xxx_node，为什么就能正常索引了？
A1. Dify迁移后的weaviate为什么能正常索引？

Q2. 迁移脚本是如何解决Weaviate 数据库 1.19.0 到 1.27.0+ 版本之间架构不兼容问题？
A2. Dify如何解决Weaviate数据库 1.19.0 到 1.27.0+ 版本之间架构不兼容问题（附迁移脚本）

🎯商务合作

如需以下服务，请私信

• a.Dify企业版订购
• b.Dify社区版定制化服务

公众号原文链接 https://mp.weixin.qq.com/s/6L3HfdDuZxgaGSCj_5NskQ
可加Dify交流群