问题描述
大约两年前,我开始在x86 Debian VM本地运行GitLab CE,去年,我决定将GitLab CE实例迁移到专用的Intel NUC服务器。一切似乎都顺利进行,并且我的GitLab CE实例到今天为止都是最新的(运行13.4.2)。
但是我最近发现,一些已移动的存储库给出了“无存储库”!在访问其项目页面时出现错误,并且如果他们有任何发行板,合并请求等,这些也都消失了。但是您不会怀疑,因为损坏的存储库与我一直使用的工作存储库一起出现在存储库列表中。
如果我不得不为这些损坏的存储库辩解,那可能是他们有一年多的最后活动,或者除了最初的推动之外没有对他们进行任何推动,或者如果进行了更改,则产生了问题,或合并创建的请求,实际上是一年多以前。
这些破碎的回购协议中有一些很大,有很多历史,而另一些则非常小(从字面上看只是跟踪对shell脚本的更改),所以我认为回购规模本身与它没有任何关系。 / p>
如果我运行GitLab诊断检查sudo gitlab-rake gitlab:check
,则除了“哈希存储”外,其他一切看起来都不错:
All projects are in hashed storage? ... no
Try fixing it:
Please migrate all projects to hashed storage
但是随后运行sudo gitlab-rake gitlab:storage:migrate_to_hashed
似乎没有完成(仪表盘中有六个失败的作业),再次运行“ gitlab:check”仍然表明此“哈希存储”问题。我也尝试过运行sudo gitlab-rake gitlab:git:fsck
和sudo gitlab-rake cache:clear
,但是这些命令似乎没有什么作用。
幸运的是,我的机器上拥有所有丢失的存储库的最新版本,实际上,我仍然具有运行GitLab CE 12.8.5的原始VM(存储库的副本有些过时了。)
所以我的问题是:
- 是否可以“修复”当前实例上损坏的存储库?我怀疑我可以将这些存储库的本地副本“重新推送”回我的服务器,但是我真的不想丢失任何元数据,例如问题/合并请求等。
- 有什么方法可以解决“并非所有项目都在哈希存储中”的问题? (再次执行
migrate_to_hashed
任务失败。) - 我能够执行“备份”,“检查/调整备份”,“还原备份”之类的事情来修复损坏的存储库,或者至少修复元数据吗?
谢谢。
解决方法
好的,所以我想我知道发生了什么事。
我在this thread上找到了GitLab User Forums。
显然,这里的场景是:
- 有一个GitLab实例,该实例的仓库在“哈希存储”中没有
- 备份您的存储库
- 还原您的存储库(到同一台服务器或迁移到另一台服务器)
- 自动或手动尝试将您的存储库更新为“哈希存储”
- 您现在会发现,带有“ ciRunner”(连续集成运行器)的任何回购现在都将被列为“无库存!”。并且完全不可用,因为“哈希存储”迁移过程将失败
解决方法是:
- 重置GitLab文档中this article中列出的跑步者注册令牌
- 重新运行
sudo gitlab-rake gitlab:storage:migrate_to_hashed
进程 - 完成后台作业后,运行
sudo gitlab-rake gitlab:check
以确保输出包含以下消息:
All projects are in hashed storage? ... yes
如果成功,则说明“无存储!”的项目。现在应该完全恢复了。
要知道是否需要运行此过程的关键是您是否:
- 以管理员身份登录到您的GitLab CE实例
- 转到管理区域
- 查看监控->后台作业->死
- 然后看到一个名字为 的工作
hashed_storage:hashed_storage_project_migrate
有错误
OpenSSL::Cipher::CipherError: