@@ -429,3 +429,80 @@ should fit comfortably within the delay time for a few reasons:
...
@@ -429,3 +429,80 @@ should fit comfortably within the delay time for a few reasons:
Never try to optimize by fully filling the delay window even if you are confident
Never try to optimize by fully filling the delay window even if you are confident
the queries themselves have no timing variance.
the queries themselves have no timing variance.
### Background jobs tracking
`queue_background_migration_jobs_by_range_at_intervals` can create records for each job that is scheduled to run.
You can enable this behavior by passing `track_jobs: true`. Each record starts with a `pending` status. Make sure that your worker updates the job status to `succeeded` by calling `Gitlab::Database::BackgroundMigrationJob.mark_all_as_succeeded` in the `perform` method of your background migration.
```ruby
# Background migration code
defperform(start_id,end_id)
# do work here
mark_job_as_succeeded(start_id,end_id)
end
private
# Make sure that the arguments passed here match those passed to the background
See [`lib/gitlab/background_migration/drop_invalid_vulnerabilities.rb`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/background_migration/drop_invalid_vulnerabilities.rb) for a full example.
#### Rescheduling pending jobs
You can reschedule pending migrations from the `background_migration_jobs` table by creating a post-deployment migration and calling `requeue_background_migration_jobs_by_range_at_intervals` with the migration name and delay interval.
See [`db/post_migrate/20210604070207_retry_backfill_traversal_ids.rb`](https://gitlab.com/gitlab-org/gitlab/blob/master/db/post_migrate/20210604070207_retry_backfill_traversal_ids.rb) for a full example.