Sidekiq 작업 마이그레이션 Rake 작업

Tier: Free, Premium, Ultimate Offering: Self-Managed
caution
이 작업은 매우 흔치 않아야 합니다. 대부분의 GitLab 인스턴스에 대해 권장하지 않습니다.

Sidekiq 라우팅 규칙을 사용하면 관리자가 특정 배경 작업을 일반 대기열에서 대안 대기열로 다시 라우팅할 수 있습니다. 기본적으로 GitLab은 각 배경 작업 유형당 하나의 대기열을 사용합니다. GitLab에는 400가 넘는 배경 작업 유형이 있으며, 따라서 400가 넘는 대기열이 있습니다.

대부분의 관리자는이 설정을 변경할 필요가 없습니다. 특히 대규모의 백그라운드 작업 처리 작업 부하가 있는 경우에는 GitLab이 청취하는 대기열 수로 인해 Redis 성능에 영향을 줄 수 있습니다.

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