用 gitlab 很长一段时间了，从 2013 年开始，一直到现在，在每一个团队中都在推广使用 gitlab-ce 做版本管理和项目管理。本来一切好好的，一直到今天。

今天我要做备份的时候。

sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production

命令不灵了。

Dumping database … Dumping MySQL database gitlabhq_production … [FAILED] Backup failed

谷歌了解决办法，无非下面几个情况：

  1. 没有装 mysql client library。
  • 解决办法：安装一个 mysql client library 就好。
  1. git 用户没有写入 config/gitlab.yml 中设定的备份目录的权限
  • 解决办法：修改备份目录所有者为 git 用户就好。
  1. 官网上有 issue 是关于 PostgreSQL 的，没有结论，参考价值不大

我挨个排查了一下，上面几种情况都排除了。

首先，我的 gitlab 站点完全正常访问， 所以第一种情况可以排除。

其次，tmp/backups/db/ 目录下还有一个空文件 database.sql，我删除之后再试，它还能生成，证明备份 DB 的效果是有的，就是不知道为什么，没有取到 DB 里面的内容，备份成空文件了。顺便检查了下备份目录的磁盘空间，完全充足，用下面的命令证明 git 写入文件到备份目录是完全没有问题的。

sudo -u git -H cat VERSION > tmp/backups/db/test_VERSION

最后，运行 check 命令检查了 gitlab 的环境，一点儿问题都没有。

sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production

很奇怪对吧？仔细看了遍文档，没有答案。很明显几乎没人会遇到这种问题，因为大家提的 issue 就上面那几个，不是已经被证明与我遇到的情况不符，就是与我的实际情况无关。

然后，开动大脑，仔细想。。。

sudo -u git -H echo `which mysqldump`

/usr/bin/which: no mysqldump in (blabla…)

不知道对不对，试了下这个。

ln -s /usr/local/mysql/bin/mysqldump /usr/bin/mysqldump

OK了！

我就特别不喜欢那种假设各种工具都可以不需要指定路径直接调用的产品。特别是 gitlab 你都要我在配置文件里面指定 git 的全路径了，会用到 mysqldump 你也不说一声，悄悄咪咪地调用，出错也不直接出提示，只说『FAILED』。我去！

后记：

  • 一开始还仔细检查了 mysql 的账号权限，才确信排除了数据库的问题；
  • 对 mysqldump 的设置一开始是通过修改 .bashrc + 添加 PATH 到 visudo 的 env_keep 变量的方法来实现，最终确认问题的根源。建立软链接的方式从安全性上不太可取，不过实现成本最低，性价比高；
  • 假如还不行，十多分钟后，我就准备开始读源码了。大约四五年前读过 Ruby 的代码，感觉不来电，倒是也不至于折磨人就是了。