尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

保姆级教程:手把手修复GitLab 14.x升级中的‘后台迁移暂停’错误(附完整命令)

保姆级教程:手把手修复GitLab 14.x升级中的‘后台迁移暂停’错误(附完整命令) 保姆级教程手把手修复GitLab 14.x升级中的‘后台迁移暂停’错误附完整命令当你正在执行GitLab版本升级时突然遇到gitlab-ctl reconfigure报错提示后台迁移任务处于暂停状态导致整个升级流程卡住。这种情况在升级到14.x版本时尤为常见特别是涉及大表结构变更的场景。本文将带你一步步排查问题根源并提供完整的解决方案确保你的GitLab顺利升级。1. 错误现象与原因分析执行gitlab-ctl reconfigure时你可能会看到类似如下的错误信息rake aborted! StandardError: An error has occurred, all later migrations canceled: Expected batched background migration for the given configuration to be marked as finished, but it is paused: {:job_class_nameCopyColumnUsingBackgroundMigrationJob, :table_nameci_builds_metadata, :column_nameid, :job_arguments[[id], [id_convert_to_bigint]]}核心问题在于GitLab使用后台批处理迁移来处理大表结构变更如整型字段升级为bigint这种设计是为了避免在迁移过程中锁表时间过长影响服务可用性。但当这些后台迁移任务被意外暂停时会阻止后续所有迁移执行。常见触发原因包括服务器资源不足导致迁移任务中断数据库连接不稳定手动终止了迁移进程GitLab服务在迁移过程中重启2. 完整修复流程2.1 检查数据库连接状态首先确认数据库服务是否正常运行sudo gitlab-ctl status postgresql如果数据库未运行启动它sudo gitlab-ctl start postgresql然后检查迁移状态sudo gitlab-rake db:migrate:status2.2 执行后台迁移完成命令根据错误信息中的参数执行对应的finalize命令。注意参数中的转义字符sudo gitlab-rake gitlab:background_migrations:finalize[CopyColumnUsingBackgroundMigrationJob,ci_builds_metadata,id,[[id], [id_convert_to_bigint]]]提示命令参数必须与错误日志中显示的内容完全一致包括方括号和引号的格式。2.3 处理Redis连接问题执行完上述命令后重新配置时可能会遇到Redis连接错误Redis::CannotConnectError: Error connecting to Redis on /var/opt/gitlab/redis/redis.socket (Errno::ENOENT)即使Redis服务显示正常运行也可能需要完全重启GitLab组件sudo gitlab-ctl restart sudo gitlab-ctl reconfigure2.4 验证并完成迁移如果仍有其他表的后台迁移被暂停重复执行finalize命令。例如sudo gitlab-rake gitlab:background_migrations:finalize[CopyColumnUsingBackgroundMigrationJob,taggings,id,[[id, taggable_id], [id_convert_to_bigint, taggable_id_convert_to_bigint]]]最后执行完整数据库迁移sudo gitlab-rake db:migrate sudo gitlab-ctl reconfigure3. 常见问题与解决方案3.1 参数格式错误执行finalize命令时最常见的错误是参数格式不正确。注意表名和列名必须与错误信息完全一致JSON数组格式必须保留包括内部引号和逗号特殊字符需要正确转义3.2 多个暂停的迁移任务有时会有多个表的后台迁移被暂停。需要为每个暂停的任务单独执行finalize命令。可以通过以下命令检查所有后台迁移状态sudo gitlab-rails runner -e production puts Gitlab::Database::BackgroundMigration::BatchedMigration.where(status: 3).to_json3.3 迁移执行时间过长对于特别大的表finalize过程可能需要较长时间。可以通过以下命令监控进度watch -n 10 sudo gitlab-rails runner -e production puts Gitlab::Database::BackgroundMigration::BatchedMigration.find_each { |m| puts \#{m.id}: #{m.status}\ }4. 预防措施与最佳实践为了避免升级过程中遇到类似问题建议升级前准备确保服务器有足够的内存和磁盘空间备份数据库和配置文件在非高峰期执行升级升级过程监控保持SSH会话活跃使用screen或tmux实时查看日志sudo gitlab-ctl tail资源优化临时增加后台迁移的批处理大小在/etc/gitlab/gitlab.rb中添加gitlab_rails[background_migration_batch_size] 10000完成后记得改回默认值并重新配置版本升级路径严格遵循官方升级路径不要跳过中间版本每个版本升级后确认服务完全正常通过这套完整的解决方案你应该能够顺利解决GitLab升级过程中的后台迁移暂停问题。如果遇到其他变体错误同样的排查思路也适用——先定位具体的迁移任务然后手动完成它最后验证整体状态。
返回列表