我报名参加金石计划1期挑战——瓜分10万奖池，这是我的第 2 篇文章，点击查看活动详情”
有风也有波的，未必是春江水暖，还有可能是运维故障！
-- 程序员张三
1.事件背景
JFrog Artifactory 制品仓库的对象存储空间，已占用近 200TB，对整个存储资源池造成较高负载，而现有存储资源池建设成本偏高，不便进行继续扩容。所以 Artifactory 后端存储迁移，已势在必行。咨询官方技术支持，很快给出了实施方案，事后才明白，什么叫 “快即是慢”。
2.迁移方案一
- 存储层做文件全量迁移，此时生产环境仍然使用旧存储 S3 资源池；由于文件数量巨大，这个过程耗时一个多月；
- 生产环境切换到新存储 S3 资源池；
- 测试环境切换到旧存储 S3 资源池；
- 测试环境向生产环境做 Replication 副本同步；
出于对官方技术的信任，没多考虑就实施上述迁移步骤。结果部分开发人员反馈 500 文件丢失异常(最新版 v7.41.7版本报错 404 文件丢失异常)，导致构建任务无法继续，保障人数随着时间推移而逐渐增多。原来 Postgresql 数据库中记录的信息是最新的，而新存储 S3 中的文件有部分缺失。
针对保障的制品文件，临时人工处理，使用对象存储客户端，手动拷贝文件。同时编写 Python 代码，通过 API 全量检查差异制品，自动调用同步脚本。理想是丰满的，代码也是没问题的，脚本运行时发现，几百万个文件需要扫描。临时改代码，使用异步 IO 编程加速网络请求。
异步 IO 并发 200，aws 命令行同步进程 350 个，这样修复了一个晚上，结果第二天仍然有大量异常反馈；最后只能😖 狠心回滚 😖。
原因分析：
- 对象存储层全量同步的一个月里，仍有大量文件被修改；
- Replication 同步不具有可观测性，运维人员无从得知哪些仓库还未同步；
运维要有敬畏之心，始终对他人的方案持怀疑态度，哪怕他是付费的乙方！
-- 程序员张三
3.迁移方案二
该方案要求 Artifactory 版本大于
v7.31.10
- 生产环境同时连接新旧存储资源池，旧资源池配置为
只读，新资源池配置为读写。 - 从旧资源池向新资源池做全量同步。
由于旧存储池已配置为只读，不再有新制品上传或修改，只需底层通过 rsync 全量同步即可。本想给大家提供配置，因涉于保密，大家只好参考官方文档 12
所有你觉得复杂的东西，都因为你没有想清楚，弄明白了也不过如此 ！
-- 程序员张三
4. 总结
作为甲方，能用钱解决的问题都不是问题，但在技术问题上，往往甲乙双方是调换位置的。正因如此，甲方时常对乙方的技术人支持天然地信任，毕竟甲方是拿钱让人叫爸爸的。事实上，我们要时刻警惕这种思维误区，每当掉以轻心之时，也是掉坑里的时候。
看到这里的兄弟，请分享给你的朋友，躲坑避雷让更多运维早点下班，家庭幸福!!
