Sidekiq 作业迁移

caution这种操作应该非常少见。我们不建议对绝大多数极狐GitLab 实例使用它。

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

大多数管理员不需要更改此设置。在某些具有特别大的后台作业处理工作负载的情况下，Redis 性能可能会由于极狐GitLab 侦听的队列数量而受到影响。

如果 Sidekiq 路由规则发生更改，管理员需要小心迁移以避免完全丢失作业。基本的迁移步骤是：

  1. 同时侦听旧队列和新队列。
  2. 更新路由规则。
  3. 等到没有发布者向旧队列分派作业。
  4. 运行适用于未来作业的 Rake 任务。
  5. 等待旧队列为空。
  6. 停止侦听旧队列。

未来作业

第 4 步涉及为已存储在 Redis 中但将在未来运行的作业重写一些 Sidekiq 作业数据。将来有两组作业要运行：计划作业和要重试的作业。我们提供一个单独的 Rake 任务来迁移每个集合：

  • gitlab:sidekiq:migrate_jobs:retry 用于要重试的作业。
  • gitlab:sidekiq:migrate_jobs:scheduled 用于计划作业。

大多数时候，同时运行两者是正确的选择。有两个单独的任务允许在需要时进行更细粒度的控制。要同时运行两者： 

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

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