diff options
Diffstat (limited to 'doc/administration/sidekiq/sidekiq_job_migration.md')
| -rw-r--r-- | doc/administration/sidekiq/sidekiq_job_migration.md | 19 |
1 files changed, 11 insertions, 8 deletions
diff --git a/doc/administration/sidekiq/sidekiq_job_migration.md b/doc/administration/sidekiq/sidekiq_job_migration.md index f61021ad4e7..b93d86d4c86 100644 --- a/doc/administration/sidekiq/sidekiq_job_migration.md +++ b/doc/administration/sidekiq/sidekiq_job_migration.md @@ -4,7 +4,7 @@ group: unassigned info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments --- -# Sidekiq job migration **(FREE SELF)** +# Sidekiq job migration Rake tasks **(FREE SELF)** WARNING: This operation should be very uncommon. We do not recommend it for the vast majority of GitLab instances. @@ -17,24 +17,27 @@ If the Sidekiq routing rules are changed, administrators need to take care with 1. Listen to both the old and new queues. 1. Update the routing rules. -1. Wait until there are no publishers dispatching jobs to the old queues. -1. Run the [Rake tasks for future jobs](#future-jobs). -1. Wait for the old queues to be empty. +1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect. +1. Run the [Rake tasks for migrating queued and future jobs](#migrate-queued-and-future-jobs). 1. Stop listening to the old queues. -## Future jobs +## Migrate queued and future jobs Step 4 involves rewriting some Sidekiq job data for jobs that are already stored in Redis, but due to run in future. There are two sets of jobs to run in future: scheduled jobs and jobs to be retried. We provide a separate Rake task to migrate each set: - `gitlab:sidekiq:migrate_jobs:retry` for jobs to be retried. - `gitlab:sidekiq:migrate_jobs:scheduled` for scheduled jobs. -Most of the time, running both at the same time is the correct choice. There are two separate tasks to allow for more fine-grained control where needed. To run both at once: +Queued jobs that are yet to be run can also be migrated with a Rake task: + +- `gitlab:sidekiq:migrate_jobs:queued` for queued jobs to be performed asynchronously. + +Most of the time, running all three at the same time is the correct choice. There are three separate tasks to allow for more fine-grained control where needed. To run all three at once: ```shell # omnibus-gitlab -sudo gitlab-rake gitlab:sidekiq:migrate_jobs:retry gitlab:sidekiq:migrate_jobs:schedule +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 RAILS_ENV=production +bundle exec rake gitlab:sidekiq:migrate_jobs:retry gitlab:sidekiq:migrate_jobs:schedule gitlab:sidekiq:migrate_jobs:queued RAILS_ENV=production ``` |