Dify滚动更新需保障数据不丢失：确保有状态服务独立运行并挂载持久化存储，数据库迁移兼容旧版本读写，控制每次仅更新1个副本，更新后校验对话数、文档哈希及配置完整性。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
在Dify系统升级过程中保障用户数据、应用配置、知识库文档及对话历史不被清空或覆盖，是生产环境持续交付的前提。滚动更新通过分批替换服务实例，在新旧版本并存期间维持数据写入一致性，避免单点故障导致的数据丢失。
前置检查：确认数据持久化已正确分离
滚动更新生效的前提是Dify的有状态组件（如PostgreSQL、Redis、MinIO）完全独立于应用容器运行，且挂载了持久化存储卷。
执行 docker ps -a | grep -E "(postgres|redis|minio)"，确认这些服务容器处于运行状态且未使用 --rm 参数启动。
检查Dify应用容器是否禁用了本地文件写入：进入容器执行 ls -l /app/storage，若显示为 Permission denied 或返回空，说明已正确指向外部MinIO/S3；若列出大量 knowledge/ 或 conversations/ 目录，则【必须立即停止滚动更新，先迁移本地数据至对象存储】。
数据库迁移：确保schema变更兼容旧版本读取
滚动更新期间，旧版Dify实例仍在处理请求，可能持续向数据库写入数据。因此，任何破坏性迁移（如DROP COLUMN、重命名表）都不可直接执行。
方法一：添加新字段+双写迁移
例如需新增 app.is_public 字段，先用 ALTER TABLE apps ADD COLUMN is_public BOOLEAN DEFAULT false; 添加，再部署支持该字段的新版本；旧版本忽略该字段，不影响运行。
方法二：通过视图兼容旧查询
若必须调整底层表结构（如拆分 users 表），先创建兼容视图 CREATE VIEW users_legacy AS SELECT id, name, email FROM users_v2;，并将旧版Dify的数据库连接指向该视图，待全部实例升级完成后再删除视图。
执行滚动更新：控制最大不可用副本数
第一步：修改Dify部署配置中的更新策略
在 docker-compose.yml 的 dify-api 服务下添加或修改如下字段：
deploy:
update_config:
parallelism: 1
delay: 30s
failure_action: rollback
rollback_config:
parallelism: 1
delay: 5s
第二步：触发更新
执行 docker-compose up -d --no-deps --force-recreate dify-api，Docker将逐个停止旧容器、拉取新镜像、启动新容器，每次仅影响1个副本。
第三步：验证新实例健康状态
等待30秒后，执行 curl -sf http://localhost:5001/healthz，返回 {"status":"ok"} 即表示该实例已就绪；若超时或返回错误，【Docker会自动回滚至上一版本，无需人工干预】。
验证数据连续性：比对关键状态指标
在滚动更新完成、所有新实例就绪后，立即执行三项校验：
① 对话计数一致性：调用旧版与新版API分别请求 GET /v1/conversations?limit=1，对比响应头中 X-Total-Count 值是否相同。
② 知识库文档哈希校验：从任意一个新实例中执行 SELECT md5(content) FROM documents WHERE id = 'doc_abc123';，与升级前从旧库中查出的同一文档md5值比对。
③ 应用配置未被覆盖：访问Dify控制台 → 【设置】→【系统设置】，确认SMTP密码、JWT密钥等敏感字段仍为掩码显示（而非明文重置），证明配置表未被初始化脚本误刷。
