Documentation: how to re-run a background migration
Re-running a background migration was done in this MR: !103359 (merged) and various options were discussed over slack conversation (can be found below).
Slack conversation:
what is the best way if I want to re-run again a batched BG migration (specifically I want to recount epic cached counts again - https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/post_migrate/20220905120848_backfill_epic_cache_counts.rb)? Can I just create a new post-migration (same as https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/post_migrate/20220905120848_backfill_epic_cache_counts.rb) or would it be a problem because there already was migration referring to the same class?
you wanna use the same batched background migration class with the same job arguments? If you use the same arguments, you will not be able to run it again https://gitlab.com/gitlab-org/gitlab/-/blame/113f91639976d5dde512f27413c8c10e47d817d8/lib/gitlab/database/migrations/batched_background_migration_helpers.rb#L82
good to know, thanks. I can think of two options: 1) create new bg migration class (which just inherits from the original class, so the only difference is its class name) 2) or change one of arguments (e.g. use batch_size 1001 instead of 1000). Option (1) is cleaner - second option is hacky.WDYT? Should I go with (1)?
The second option will not work, these are the arguments that make a batched background migration “unique” if Gitlab::Database::BackgroundMigration::BatchedMigration.for_configuration(gitlab_schema, job_class_name, batch_table_name, batch_column_name, job_arguments).exists?
I think a cleaner way is to perhaps have an additional argument, e.g. version or run_version - so that it would conflict less with a possible real version argument and use that to differentiate between multiple runs of the same migration. This would let us avoid have these empty classes that inherit from original migration just to have a different class name. So we'll have less code that does not do much. WDYT ? Also if this sounds reasonable maybe we we should document this as a suggested usage for rescheduling the same migration on the batched migration documentation ?
Proposed Solution: Delete the enqueued migration and re-running the migration job (reference).
The above solution has to be documented in the batched background migration doc for future reference.