• 대기 중 및 향후 작업 마이그레이션

Sidekiq 작업 이전 Rake 작업

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

# 소스 설치
bundle exec rake gitlab:sidekiq:migrate_jobs:retry gitlab:sidekiq:migrate_jobs:schedule gitlab:sidekiq:migrate_jobs:queued RAILS_ENV=production