Commit d9d6fbb2 authored by Marcia Ramos's avatar Marcia Ramos

Merge branch 'garyh-master-patch-14204' into 'master'

Clarifying some info about sidekiq jobs in background migrations

See merge request gitlab-org/gitlab!41718
parents 9c20a33d 8b9cfddf
# Background Migrations ---
type: reference, dev
stage: none
group: Development
info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments-to-development-guidelines"
---
# Background migrations
Background migrations can be used to perform data migrations that would Background migrations can be used to perform data migrations that would
otherwise take a very long time (hours, days, years, etc) to complete. For otherwise take a very long time (hours, days, years, etc) to complete. For
...@@ -92,6 +99,20 @@ bulk_migrate_async( ...@@ -92,6 +99,20 @@ bulk_migrate_async(
) )
``` ```
Note that this will queue a Sidekiq job immediately: if you have a large number
of records, this may not be what you want. You can use the function
`queue_background_migration_jobs_by_range_at_intervals` to split the job into
batches:
```ruby
queue_background_migration_jobs_by_range_at_intervals(
ClassName,
BackgroundMigrationClassName,
2.minutes,
batch_size: 10_000
)
```
You'll also need to make sure that newly created data is either migrated, or You'll also need to make sure that newly created data is either migrated, or
saved in both the old and new version upon creation. For complex and time saved in both the old and new version upon creation. For complex and time
consuming migrations it's best to schedule a background job using an consuming migrations it's best to schedule a background job using an
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment