• キューに入っているジョブや将来のジョブをマイグレーションします。

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