记一次老版本perforce的迁移历程

当前现状：项目组的代码与资源是用perforce管理，已经有7年历史了，用的是perforce2015版本，仓库有2.4T，perforce所在物理机只有3T空间，journal文件当前470G，每天增长3-4G。

最大的问题：7年前的旧机器，导致p4服务器性能很差，更要命的是硬盘空间，按照当前进度，最多5个月硬盘耗尽:

迁移工作已经迫在眉睫，必须马上开始。

方案1：

做checkpoint，然后导出到新机器上，然后恢复出来，这也是官方推荐的方案。因为本机已经没有多余的空间，所以需要挂载一个新硬盘或者网络分区。空间解决之后，那就是时间的问题，根据其他项目组迁移的经历，190多G的journal文件，迁移了9-10小时，同比例来算的话，我们的470G需要25小时左右，这仅仅是做checkpoint的时间，加上2.4t的仓库文件的迁移时间（之前做过一次备份，rsync同网段，需要24小时左右），还需要再加上checkpoint恢复db的时间，同样还按24小时来算，那么需要整整3天时间。这期间需要停止perforce服务，这在当前节点无法接受，因为项目组的开发安排无法留出这么长的空档期，即使是3天假期也无法操作，因为在国庆前的开发任务都很紧张，下一个具备这样长档期的节点是国庆，当时算一下到国庆还有4个月时间，到那时硬盘空间已经耗尽了。

方案2：

死马当作活马医，直接拷贝所有数据到新机器上，重新做license。启发我这么做的源头是mysql的迁移。既然mysql都可以直接拷贝数据到新机器上，然后修改ip和data_dir就可以拉起服务，那perforce也是指定ip:port和data_dir启动，应该适用同样的机制。时间耗费也只有整个仓库拷贝的时间，也就是24小时左右。

方案也只能选择第二种，说干就干，先做可行性测试。新申请了一台6T的高配机，安装了最新的perforce2022（注意这里是个坑），然后做license，本身服务可以启动，可是将之前的备份数据迁移过来作为新的p4root时，服务就起不来了，后来看官方文档，说是最好用一样的版本。没办法只能再找一下2.15版，居然发现官网已经不提供下载了，因为版本太老，真是好事多磨。最后又是凭经验，想到是不是可以把老机器上的p4d拷过来，先ldd看一下，发现p4也不依赖什么第三方库，算是松口气吧。最后把p4d拷到新机器上，做license，启动，ok，数据是认的，用p4client连接测试，也可以拉取到数据，证明方案可行。

接下来就是正式操作，步骤如下：

1.周五19点停止perforce服务

2.rsync所有p4root目录下的数据到新机器上，耗时23小时

3.新机器上停止perforce服务，重新配置p4root目录路径，拉起p4d

4.将p4服务的域名解析到新机器的ip上

5.pc上的p4v不做任何改动，直接通过域名连接p4服务，测试拉取history，拉新，checkout完全正常

好了，到这里整个迁移工作完成，总耗时24小时，客户端都无感，在周一所有同事上班时，正常使用p4。

这里我总结最重要的一点就是，在官方方案有时候并不是最优解，要综合考虑，触类旁通，总有有些普世原则可以适用。