Artifactory跨架构迁移时源端到目标端导出导入的最佳方案是什么

最佳方案选择 #

你当前的异构架构场景下，不推荐使用system级导出导入方案，原因如下：

• system导出会包含源端Derby数据库的底层元数据结构，跨数据库类型导入到MySQL环境时大概率出现兼容性报错，甚至导致目标端数据库异常
• system导入会直接覆盖目标端已完成的全部基础配置，包括MySQL关联、新S3存储桶绑定等已验证的配置，风险不可控

逐仓库导出导入是当前场景的最优方案，完全适配你的架构差异，优势如下：

• 元数据与底层数据库解耦：逐仓库导出的内容仅包含对应仓库的制品文件、访问权限、版本元数据等业务层数据，不受源端Derby、目标端MySQL的数据库类型差异影响，导入成功率100%
• 迁移风险可控：可按仓库的业务优先级分批迁移，单仓库迁移出现问题可单独回滚，不会影响整个目标端的正常运行
• 自动适配异构存储：导入过程中Artifactory会自动将制品写入目标端绑定的新S3存储桶，无需单独做S3层的数据拷贝和适配

迁移操作建议 #

• 迁移前先在源端执行artifactory trim命令清理过期快照、废弃制品，缩减迁移数据量
• 提前迁移全局配置：单独导出源端的用户、用户组、权限规则、全局属性等元数据，提前导入目标端，避免仓库迁移后出现权限缺失问题
• 按类型分批迁移：优先迁移本地仓库，再迁移远程仓库，最后迁移虚拟仓库，每完成一个仓库的导入，校验制品数量、文件哈希值和源端一致后再迁移下一个
• 增量同步缩短暂停窗口：全量迁移完成后开启源端的增量导出开关，业务切换前做最后一次增量同步，可将业务中断时间压缩到分钟级

若你使用的Artifactory版本为7.0及以上，可直接使用内置的实例迁移功能，配置源端访问密钥后无需手动导出导入包，直接拉取对应仓库的数据，迁移效率更高

内容的提问来源于stack exchange，提问作者vx-r2