Sidekiq 作业迁移 Rake 任务

Sidekiq 路由规则允许管理员将某些后台作业从其常规队列重新路由到备用队列。默认情况下，GitLab 为每种后台作业类型使用一个队列。GitLab 有超过 400 种后台作业类型，因此相应地有超过 400 个队列。

大多数管理员无需更改此设置。在某些后台作业处理负载特别大的情况下，由于 GitLab 监听的队列数量过多，Redis 性能可能会受到影响。

如果更改了 Sidekiq 路由规则，管理员在迁移时应谨慎，以避免完全丢失作业。基本迁移步骤如下：

1. 同时监听旧队列和新队列。
2. 更新路由规则。
3. 重新配置 GitLab 以使更改生效。
4. 运行用于迁移已排队和未来作业的 Rake 任务。
5. 停止监听旧队列。

迁移已排队和未来作业

步骤 4 涉及重写一些 Sidekiq 作业数据，这些作业已存储在 Redis 中，但计划在未来运行。计划在未来运行的作业分为两类：计划作业和待重试作业。我们为每一类作业提供了单独的 Rake 任务进行迁移：

• gitlab:sidekiq:migrate_jobs:retry：用于迁移待重试作业。
• gitlab:sidekiq:migrate_jobs:schedule：用于迁移计划作业。

尚未运行的已排队作业也可以使用 Rake 任务进行迁移（GitLab 15.6 及更高版本中可用）：

• gitlab:sidekiq:migrate_jobs:queued：用于将要异步执行的已排队作业。

在大多数情况下，同时运行这三个任务是正确的选择。提供三个独立的任务可以在需要时进行更精细的控制。要一次性运行所有三个任务（GitLab 15.6 及更高版本中可用）：

# omnibus-gitlab
sudo gitlab-rake gitlab:sidekiq:migrate_jobs:retry gitlab:sidekiq:migrate_jobs:schedule gitlab:sidekiq:migrate_jobs:queued

# source installations
bundle exec rake gitlab:sidekiq:migrate_jobs:retry gitlab:sidekiq:migrate_jobs:schedule gitlab:sidekiq:migrate_jobs:queued RAILS_ENV=production