Confluence数据迁移踩坑实录：从物理机到K8s集群，我是如何无损迁移200G知识库的？
Confluence企业级数据迁移实战：从物理架构到Kubernetes的无缝过渡
当企业知识库规模突破200GB时，迁移不再是简单的备份还原操作。去年我们团队将一个运行7年的Confluence实例从老旧物理服务器迁移到Kubernetes集群，期间经历了数据库崩溃、文件权限错乱、索引重建耗时等一系列"惊险时刻"。本文将分享如何设计零数据丢失的迁移方案，以及那些只有实战才会遇到的深层问题。
1. 迁移前的关键评估与准备
迁移大型Confluence实例就像给飞行中的飞机换引擎，必须精确计算每个操作的时间窗口。我们首先用du -sh /var/atlassian/application-data/confluence/命令统计出附件目录占用了187GB空间，而数据库dump文件达到23GB。这意味着：
- 停机时间预估：通过测试环境模拟，发现仅数据库导出导入就需要2小时（启用
--single-transaction参数的情况下） - 网络带宽需求：千兆内网传输200GB数据理论上需要27分钟，但实际受磁盘IO限制需要预留1.5小时
- 版本兼容矩阵：
| 组件 | 源环境版本 | 目标环境版本 | 兼容性风险 |
|---|---|---|---|
| Confluence | 7.13.6 | 8.5.1 | 需要重建索引 |
| PostgreSQL | 9.6 | 13.4 | 需pg_dump特定参数 |
| 操作系统 | CentOS 6 | Container | 文件权限需转换 |
关键提示：永远在测试环境先完成全流程演练，我们第一次尝试就因PostgreSQL大版本升级导致collation冲突
2. 双阶段迁移方案设计
为最小化停机时间，我们采用全量备份+增量同步的混合策略：
预热阶段（服务在线）：
# 数据库全量dump（不锁表） pg_dump -U postgres -Fc confluence > confluence_full.dump # 附件目录首次同步 rsync -azP --delete /var/atlassian/application-data/confluence/ root@k8s-nfs:/confluence-data/切换阶段（停机窗口）：
- 停止Confluence服务
- 执行最终增量同步（约15分钟）
- 导入数据库到新集群
- 启动Kubernetes Pods
性能优化技巧：
- 在PostgreSQL dump时添加
-j 8参数启用并行导出 - 使用
rsync --checksum替代默认的修改时间比对 - 提前在目标集群预创建PVC并做磁盘预分配
3. Kubernetes环境的特殊适配
容器化部署带来了新的挑战清单：
文件权限问题：容器内默认以confluence用户（UID 2002）运行，但物理机备份文件属于root
# 在NFS Server上批量修正权限 chown -R 2002:2002 /confluence-data find /confluence-data -type d -exec chmod 750 {} \;资源配置公式：
内存需求 = 基础2GB + (每1GB附件需要50MB JVM堆) 我们的配置：8GB请求/12GB限制（含1GB文件系统缓存）健康检查策略：
livenessProbe: httpGet: path: /status port: 8090 initialDelaySeconds: 300 # 大型实例启动缓慢 periodSeconds: 60
4. 那些官方文档没提到的坑
索引重建的隐藏成本：当我们在测试环境执行重建索引时，发现：
- 200GB数据量下，默认配置需要18小时
- 通过调整
confluence.cfg.xml中的indexing.queue.max.delay参数后降至6小时 - 最终方案：在旧系统预先生成索引快照，新环境直接导入
附件存储的雪崩效应：迁移后用户反映附件下载变慢，排查发现：
- Kubernetes的emptyDir默认使用节点磁盘
- 多个Pod同时访问导致IOPS争抢
- 解决方案：改用ReadWriteMany的NFS存储，并添加如下缓存配置：
# confluence.cfg.xml <property name="hibernate.cache.use_second_level_cache">true</property> <property name="hibernate.cache.region.factory_class">net.sf.ehcache.hibernate.EhCacheRegionFactory</property>
5. 验证与回滚的标准化流程
我们设计了三级检查清单：
基础功能验证：
- 随机抽查50个页面的历史版本
- 测试包含宏的复杂页面渲染
- 验证第三方插件兼容性
性能基准测试：
# 模拟并发访问 ab -n 1000 -c 50 http://new-confluence/popular-page回滚熔断机制：
- 保留旧系统快照7天
- 配置DNS的TTL为5分钟
- 准备数据库回滚脚本（测试时平均耗时47分钟）
迁移后第三周，某个依赖Confluence API的定制插件突然报错。由于我们保留了完整的请求日志，最终定位到是URL编码方式的差异导致。这提醒我们：即使所有检查项通过，也要监控迁移后首个完整业务周期的所有接口调用。