Gitlab 数据迁移和升级降级

一、数据迁移

1、准备工作

    从 a 服务器迁移到 b 服务器，由于 Gitlab 自身兼容性问题，高版本的 Gitlab 无法恢复低版本备份的数据，需要注意在 b 服务器部署和 a 服务器一样版本的 Gitlab，部署好环境后开始备份和数据迁移；
    查看 Gitlab 版本的命令：
    gitlab-rake gitlab:env:info

2、备份原服务器上的数据

gitlab-rake gitlab:backup:create RAILS_ENV=production

备份后的文件一般是位于：/var/opt/gitlab/backups/
自动生成的文件名：1574299748_2019_11_21_10.4.2_gitlab_backup.tar

3、把步骤2生成的 tar 文件拷贝到新服务器相应的 backups 目录下

可以利用 scp 进行直接拷贝
在新服务器上面输入：（对应原服务器用户名和原服务器对应 ip）

scp root@192.168.5.254:/var/opt/gitlab/backups/1574299748_2019_11_21_10.4.2_gitlab_backup.tar /var/opt/gitlab/backups/

4、在新服务器上面恢复数据

# BACKUP 后面的数字，必须与备份后的文件名一致
gitlab-rake gitlab:backup:restore RAILS_ENV=production BACKUP=1574299748_2019_11_21_10.4.2

5、问题记录

（1）当提示权限不够时

chmod 644 /var/opt/gitlab/backups/1574299748_2019_11_21_10.4.2_gitlab_backup.tar

（2）数据迁移后检查登录 Gitlab ，有时会跳出 500 报错（Something went wrong on our end），以及无法正常新建用户

查看日志：tail -f /var/log/gitlab/redis/current
can’t save in background:fork:cannot allocate memory
解决方案：

修改：/etc/sysctl.conf
加上 vm.overcommit_memory=1，Linux 内核会根据参数
vm.overcommit_memory 参数的设置决定是否放行。 修改完执行 sysctl -p
vm.overcommit_memory=1 # 直接放行
vm.overcommit_memory=0 # 比较此次请求分配的虚拟内存大小和系统当前空闲的物理内存加上 swap，决定是否放行 vm.overcommit_memory=2 # 比较进程所有已经分配的虚拟内存加上此次请求分配的虚拟内存

二、升级降级

# 最好先备份数据 
gitlab-ctl restart gitlab-rake gitlab:backup:create RAILS_ENV=production


# 查看版本号
cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

# 停止所有服务
gitlab-ctl stop

# 删除当前版本
gitlab-ctl uninstall
rpm -qa | grep gitlab
rpm -e --nodeps gitlab-ce-12.3.0-ce.0.el7.x86_64
#gitlab-ctl cleanse  # 保留数据不执行该命令
#rm -rf /opt/gitlab # 保留数据不执行该命令

# 选取需要的版本下载
wget https://mirrors.tuna.tsinghua.edu.cn/gitlab-ce/yum/el7/gitlab-ce-12.3.5-ce.0.el7.x86_64.rpm

# rpm 包安装
rpm -ivh gitlab-ce-12.3.5-ce.0.el7.x86_64.rpm

gitlab-ctl reconfigure
gitlab-ctl start