GitLab数据恢复时的问题对应和常见技巧

爱被打了一巴掌 2022-11-26 07:44 1051阅读 0赞

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdW1pYW9jbg_size_16_color_FFFFFF_t_70_pic_center]

这篇文章整理一下GitLab数据恢复时的一些常见问题对应方法。

# 环境与版本 #

> 容器化方式部署、运行在Kubernetes中  
> 版本：GitLab-CE 12.10.5

# 数据卷挂载 #

gitlab的数据文件分成如下三类，使用容器化方式，一般会做成本地卷，则对此卷进行归档操作（比如tar命令）即可进行备份。

<table> 
 <thead> 
  <tr> 
   <th>备份目录</th> 
   <th>说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>/var/log/gitlab</td> 
   <td>日志文件</td> 
  </tr> 
  <tr> 
   <td>/etc/gitlab</td> 
   <td>设定文件</td> 
  </tr> 
  <tr> 
   <td>/var/opt/gitlab</td> 
   <td>数据文件</td> 
  </tr> 
 </tbody> 
</table>

# 恢复方式 #

## 恢复方式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时解决。

## 问题示例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

但在之前出现了如下的错误信息

[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

*  解决方式  
    使用恢复方式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][https_blog.csdn.net_liumiaocn_article_details_74529908]

新版本下使用旧版的gitlab-ctl进行备份和恢复的使用方式可参看：

*  [https://liumiaocn.blog.csdn.net/article/details/107950120][https_liumiaocn.blog.csdn.net_article_details_107950120]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdW1pYW9jbg_size_16_color_FFFFFF_t_70_pic_center]: /images/20221124/ae09803ffaf64555a8f63ceddd64e7f9.png
[https_blog.csdn.net_liumiaocn_article_details_74529908]: https://blog.csdn.net/liumiaocn/article/details/74529908
[https_liumiaocn.blog.csdn.net_article_details_107950120]: https://liumiaocn.blog.csdn.net/article/details/107950120