# 记一次 Gitlab 为排错而进行的服务迁移 起因： 老Gitlab不能在Web端新建文件，不能新建Tag，总是会莫名原因超时然后报500错误（不是Runner报500错误，也不是操作完立即报500错误，而是硬生生等到gitaly超时（最短十几秒，最长57秒）才报500错误，这段时间网页是无响应的） 尝试了更新版本，reconfigure，跟着网上各种博客在命令行里操作，完全无用。最后迫不得已考虑迁移到一个崭新的Gitlab里。迁移又有好几种方案，按破坏性升序排序有：保留所有数据和配置项、使用Gitlab自带的系统级的配置导出导入、使用Gitlab自带的仓库导出导入（系统配置不保留）。我优先尝试了第一种，没想到直接成功了，所有数据和配置项得以保留。 **所以此文也可以当作Gitlab服务器本体和/或Gitlab数据要迁移时的步骤指导**，毕竟有错的Gitlab都可以保留数据迁移后变得无错，本来没错的自然也不会错。 解决步骤： 1. 关闭老Gitlab，然后新建一套干净的Gitlab环境（版本最好和老的不要差太多，如果误升级了最好还原到老版本，Gitlab的升级必须是阶梯式的，详见官方文档，所以如果用docker的话版本标签绝对不能指定latest，我使用的是`gitlab/gitlab-ce:14.9.3-ce.0`），记得要把数据目录`/var/opt/gitlab`、配置目录`/etc/gitlab`、日志目录`/var/log/gitlab`等映射出来，并且和老Gitlab不共用。 2. 将老gitlab中`gitlab.rb`与新gitlab中的进行**逐行比对**，把需要的配置写入新gitlab的`gitlab.rb`中。一般来讲用新不用老，除了一些固定的端口、SSL配置、邮件服务器等。 3. 给新Gitlab执行`gitlab-ctl reconfigure`。一旦新Gitlab创建好，尝试使用一下。不知道root密码的话用[这个方法](https://blog.51cto.com/gosenkle/4847963)重置一下，然后登录进root用户，简单测试一下功能是否正常（Runner不用��）。如果功能正常，即可进行迁移。下面的步骤是迁移步骤： 4. 关闭新gitlab，现在新老应该都处于关闭状态 5. 将老gitlab中与`gitlab.rb`同级的一个叫`gitlab-secrets.json`的文件直接拷贝覆盖掉新gitlab的同名文件。这个文件不对的话Runner系统会彻底完蛋。按我的个人经验，只要gitlab已经有runner注册，已经有仓库在使用runner，那么不管迁移多少次，必须用老的`gitlab-secrets.json`，用到老死。 6. 将新gitlab的数据目录做备份，注意目录权限不要丢，比如我mv到了`data.bak`里。将老gitlab的数据目录替换到新gitlab原来的位置上，也注意目录权限不要丢（比如使用`copy -ra`），来一招偷天换日。 8. 启动新Gitlab，可能会比较久。启动后用户账号密码什么的已经是老的了，可以完全当成老的来用。可以测一测原来有问题的功能是否已经正常了。对我来讲Web端创建文件、打标签等功能都正常了，仓库数据、CICD和Runner等都没有丢 9. （非必须）亲测，如果是Docker环境的话，新老两个同版本的Docker本身其实并无差别，所以现在如果老Gitlab映射出来的所有目录都被拷贝替换成新的，或者直接重建容器把volume映射到新位置，那么老Gitlab也变得一切正常了。不得不说还是比较神奇。