这篇文章整理一下GitLab数据恢复时的一些常见问题对应方法。
环境与版本
容器化方式部署、运行在Kubernetes中
版本:GitLab-CE 12.10.5
数据卷挂载
gitlab的数据文件分成如下三类,使用容器化方式,一般会做成本地卷,则对此卷进行归档操作(比如tar命令)即可进行备份。
备份目录 说明
/var/log/gitlab 日志文件
/etc/gitlab 设定文件
/var/opt/gitlab 数据文件
恢复方式
恢复方式1:全卷使用
上述三个卷全部使用,重做GitLab容器,重启服务,理论上来说应该跟之前完全一致,在重启不能解决问题的时候,首先应该使用此种方式。
风险:如果有手动在容器中修改内容,但是此部分内容有未使用持久化的方式挂载出来的情况,则会存在风险,建议事前备份,容器启动不起来时,还是有些操作可以绕行的。更建议的是 基础框架即代码的方式,不要手工修改,所有操作应该以代码或者数据的方式存在,后续恢复自然简单地多。
恢复方式2: 不使用日志卷
GitLab容器启动之后,使用ps -ef 或者gitlab-ctl status就会知道,其实它启动了很多的进程,日志卷中保存此部分应用相关的数据和中间状态(出错的时候很多可能参照性却不强),如果方式1不能重启,首先考虑不使用日志卷进行恢复,此部分内容基本上不会对持久化数据产生影响
风险:同样存在手动在容器修改产生的问题,同时需要考虑到如果是否用整体的监控在使用GitLab的相关日志,此部分内容需要进行评估。
恢复方式3: 使用reconfigure
使用方式1或者方式2仍然不能恢复的情况之下,考虑使用gitlab-ctl reconfigure命令重新恢复设定,相当于基于配置卷的内容进行恢复出厂设定,然后再使用gitlab-ctl restart重启服务,并通过gitlab-ctl status确认状态。
风险:此种方式也是具有一定风险,需要事先评估,尽可能的事前先将/etc/gitlab设定卷下的文件以及数据卷的内容进行保存,尤其是gitlab.rb,很多手工设定可能都在此文件之中,请注意这个过程中可能会更新/var/opt/gitlab下的各组件的设定内容,如果此部分有手工设定也会存在问题。同样存在手动在容器修改产生的问题,同时需要考虑到如果是否用整体的监控在使用GitLab的相关日志,此部分内容需要进行评估。
恢复方式4: 仅使用数据卷
前面的方式反复执行均不可恢复的情况下,可继续尝试仅使用数据卷进行启动,基本上的数据是能够得到保证的,具体可以使用如下具体步骤:
步骤1: 进入容器之中
容器不能直接启动,但是还是有很多方式可以进入,比如启动时替换相应的命令等。
步骤2: 执行reconfigure
执行命令:gitlab-ctl reconfigure
注:此部容易出现错误执行不下去的情况,因为多少此GitLab的Chef脚本考虑到了一定的幂等性,可以多试几次,结合对于其下的数据进行删除,比如相关的prometheus或者redis的目录,在没有其他办法的情况下,在备份的基础上,可进行删除重试,因为reconfigure会重构这些文件。
步骤3: 重启gitlab服务
执行命令:gitlab-ctl restart
步骤4: 确认进程状态
执行命令:gitlab-ctl status
风险:此种方式也是具有一定风险,设定卷中很多内容尽可能的事前先将/etc/gitlab设定卷下的文件进行保存,尤其是gitlab.rb,很多手工设定可能都在此文件之中。同样存在手动在容器修改产生的问题,同时需要考虑到如果是否用整体的监控在使用GitLab的相关日志,此部分内容需要进行评估。
常见问题
问题的现象虽然相同,但是实际的原因和对应方式可能不同,这里列出一些曾经出现过的问题和相应的解决方式予以参考。
问题示例1
部分日志和现象描述
There was an error running gitlab-ctl reconfigure:
runit_service[redis] (redis::enable line 66) had an error: Mixlib::ShellOut::ShellCommandFailed: ruby_block[restart_log_service] (/opt/gitlab/embedded/cookbooks/cache/cookbooks/runit/libraries/provider_runit_service.rb line 69) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received ‘1’
---- Begin output of /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/redis/log ----
STDOUT: timeout: down: /opt/gitlab/service/redis/log: 0s, normally up, want up
STDERR:
---- End output of /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/redis/log ----
Ran /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/redis/log returned 1
— Begin output of /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/redis/log ----
STDOUT: timeout: down: /opt/gitlab/service/redis/log: 1s, normally up, want up
STDERR:
---- End output of /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/redis/log ----
Ran /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/redis/log returned 1
Running handlers complete
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
解决方式
恢复方式1未能解决,使用到恢复方式2时解决。
问题示例2
部分日志和现象描述
最终出错的地方显示如下信息:
There was an error running gitlab-ctl reconfigure:
runit_service[prometheus] (monitoring::prometheus line 86) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received ‘1’
---- Begin output of /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/prometheus ----
STDOUT: timeout: run: /opt/gitlab/service/prometheus: (pid 710) 60s, got TERM
STDERR:
---- End output of /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/prometheus ----
Ran /opt/gitlab/embedded/bin/sv restart /opt/gitlab/service/prometheus returned 1
Running handlers complete
1
2
3
4
5
6
7
8
9
10
但在之前出现了如下的错误信息
[0m * postgresql_user[gitlab] action create
* execute[create gitlab postgresql user] action run
[execute] psql: FATAL: the database system is starting up
[execute] psql: FATAL: the database system is starting up
[execute] psql: FATAL: the database system is starting up
1
2
3
4
5
解决方式
使用恢复方式4,手动删除prometheus和redis的目录,反复reconfigure和restart,最终成功
问题示例3
部分日志和现象描述
status显示redis的进程为 got TERM
gitlab-ctl status
run: alertmanager: (pid 30284) 52s; run: log: (pid 494) 10376s
run: gitaly: (pid 30298) 51s; run: log: (pid 492) 10376s
run: gitlab-monitor: (pid 30312) 51s; run: log: (pid 485) 10376s
run: gitlab-workhorse: (pid 30329) 50s; run: log: (pid 490) 10376s
run: logrotate: (pid 30344) 50s; run: log: (pid 486) 10376s
run: nginx: (pid 30350) 49s; run: log: (pid 487) 10376s
run: node-exporter: (pid 30358) 49s; run: log: (pid 483) 10376s
run: postgres-exporter: (pid 30440) 49s; run: log: (pid 479) 10376s
run: postgresql: (pid 30458) 48s; run: log: (pid 481) 10376s
run: prometheus: (pid 30470) 47s; run: log: (pid 477) 10376s
run: redis: (pid 18699) 3054s, got TERM; run: log: (pid 420) 10378s
run: redis-exporter: (pid 30582) 17s; run: log: (pid 489) 10376s
run: sidekiq: (pid 30662) 1s; run: log: (pid 491) 10376s
run: sshd: (pid 30598) 16s; run: log: (pid 36) 10388s
run: unicorn: (pid 30608) 15s; run: log: (pid 488) 10376s
解决方式
原因是目前版本下,GitLab的gitlab-ctl stop或者restart等命令似乎有时无法正常停止一些服务,比如此处为redis的进程没有停止的情况下又执行了restart产生的。此时可以结合ps -ef确认一下,确保相应的进程在停止的状态下再启动,一般此问题即可得到解决。
备份与恢复
可参看如下内容,虽然版本为GitLab 8,相关的操作基本未变化,在GitLab 12.1之前热备的命令gitlab-rake 也是一直是建议使用的,后续版本一般也是前向支持的。
https://blog.csdn.net/liumiaocn/article/details/74529908
新版本下使用旧版的gitlab-ctl进行备份和恢复的使用方式可参看:
https://liumiaocn.blog.csdn.net/article/details/107950120