GitLab重配置时出现rails_migration数据库迁移报错如何解决

该报错是GitLab重配置时数据库迁移步骤触发的通用失败提示，默认敏感资源保护会隐藏真实错误日志，按以下步骤获取根因：

• 临时关闭日志屏蔽：编辑配置文件/etc/gitlab/gitlab.rb，添加配置项gitlab_rails['sensitive_migration_logs'] = false，保存后执行gitlab-ctl reconfigure，此时重跑流程会直接输出迁移环节的完整标准输出、错误日志，可直接看到具体报错点。
• 手动执行迁移命令拿原始报错：如果不想修改全局配置，直接在终端执行以下命令，绕开chef的日志拦截：

  # 先停掉会占用数据库连接的相关服务
  gitlab-ctl stop puma sidekiq
  # 先检查当前迁移状态
  su - git -c "cd /opt/gitlab/embedded/service/gitlab-rails && bundle exec rake db:migrate:status RAILS_ENV=production"
  # 手动执行迁移，终端直接输出真实错误
  su - git -c "cd /opt/gitlab/embedded/service/gitlab-rails && bundle exec rake db:migrate RAILS_ENV=production"
  

根据手动执行拿到的报错，对应以下常见场景处理：

• 数据库连接/权限异常：如果报错提示连接拒绝、权限不足，先确认数据库服务状态：内置PostgreSQL执行gitlab-ctl status postgresql确认服务正常运行，外置数据库检查网络连通性、账号密码配置、GitLab数据库账号是否拥有建表、改表、建索引的完整权限。
• 磁盘空间不足：执行df -h检查/var/opt/gitlab所在分区使用率，若使用率超过90%，清理过期备份、旧日志文件释放至少20%空闲空间后重试。
• 迁移锁残留：如果之前迁移中途异常退出，会残留数据库迁移锁，进入PostgreSQL控制台删除schema_migrations表中状态异常的版本记录、释放数据库咨询锁后重跑迁移即可。
• 升级跨度过大：如果是跨多个大版本升级GitLab（比如从13.x直接升级到16.x），必须严格按照官方指定的升级路径逐版本递进升级，跨度过大会导致迁移脚本依赖缺失，无法正常执行。
• 第三方插件冲突：如果安装过非官方的GitLab扩展插件，先移走插件目录禁用所有第三方扩展，等迁移完成后再逐个放回排查兼容性问题。

故障修复完成后，如果之前临时修改了敏感日志配置，可以将gitlab.rb中添加的gitlab_rails['sensitive_migration_logs']配置项删除，重新执行gitlab-ctl reconfigure恢复默认的日志保护机制即可。

内容的提问来源于stack exchange，提问作者VIP-Commuter