{{< details >}}

  • Tier: 基础版，专业版，旗舰版
  • Offering: 私有化部署

{{< /details >}}

{{< alert type=”warning” >}}

此操作应该是极为罕见的。我们不为极狐GitLab 实例推荐此操作。

{{< /alert >}}

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

大多数管理员不需要更改此设置。在某些情况下，特别是较大的后台任务处理工作负载，Redis 性能可能会因为极狐GitLab 监听的队列数量而受到影响。

如果更改 Sidekiq 路由规则，管理员需要在迁移时格外小心，以避免完全丢失任务。基本的迁移步骤是：

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

迁移已排队和未来任务

步骤 4 涉及重写一些已经存储在 Redis 中但将来运行的 Sidekiq 任务数据。将来需要运行的任务有两组：计划任务和需要重试的任务。我们提供了单独的 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