Sidekiqジョブ移行Rakeタスク

Sidekiqルーティングルールを使用すると、管理者は、特定のバックグラウンドジョブを通常のキューから代替キューに再ルーティングできます。デフォルトでは、GitLabはバックグラウンドジョブタイプごとに1つのキューを使用します。GitLabには400を超えるバックグラウンドジョブタイプがあるため、対応して400を超えるキューがあります。

ほとんどの管理者は、この設定を変更する必要はありません。特に大規模なバックグラウンドジョブ処理ワークロードの場合、GitLabがリッスンするキューの数により、Redisのパフォーマンスが低下する可能性があります。

Sidekiqルーティングルールが変更された場合、管理者は、ジョブを完全に失うことを避けるために、移行に注意する必要があります。基本的な移行手順は次のとおりです:

1. 古いキューと新しいキューの両方をリッスンします。
2. ルーティングルールを更新します。
3. 変更を有効にするには、GitLabを再設定します。
4. キューおよび将来のジョブを移行するためのRakeタスクを実行します。
5. 古いキューへのリスンを停止します。

キューおよび将来のジョブを移行する

ステップ4では、Redisにすでに保存されているが、将来実行されるジョブの一部のSidekiqジョブデータを書き換えます。将来実行される予定のジョブの2つのセット: スケジュールされたジョブと再試行されるジョブ。各セットを移行するために、個別のRakeタスクを提供します:

• 再試行されるジョブのgitlab:sidekiq:migrate_jobs:retry。
• スケジュールされたジョブのgitlab:sidekiq:migrate_jobs:schedule。

まだ実行されていないキューに入れられたジョブも、Rakeタスクで移行できます（GitLab 15.6で利用可能以降）:

• 非同期で実行されるキューに入れられたジョブのgitlab:sidekiq:migrate_jobs:queued。

ほとんどの場合、3つすべてを同時に実行することが正しい選択です。3つの個別のタスクにより、必要に応じて、よりきめ細かい制御が可能になります。3つすべてを一度に実行するには（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