diff options
| author | GitLab Bot <gitlab-bot@gitlab.com> | 2022-10-05 03:09:43 +0000 |
|---|---|---|
| committer | GitLab Bot <gitlab-bot@gitlab.com> | 2022-10-05 03:09:43 +0000 |
| commit | b1646969577dbafca1b5936c3aa9535ae17d8558 (patch) | |
| tree | 7b8c7d67a447efe0daee4aa26bd8011bf5d59433 /doc/development/database_review.md | |
| parent | 59429d48eb1cf7032cf12363b83a045743f02a1e (diff) | |
| download | gitlab-ce-b1646969577dbafca1b5936c3aa9535ae17d8558.tar.gz | |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/development/database_review.md')
| -rw-r--r-- | doc/development/database_review.md | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/doc/development/database_review.md b/doc/development/database_review.md index 0b267f642ce..58776c5330c 100644 --- a/doc/development/database_review.md +++ b/doc/development/database_review.md @@ -240,9 +240,11 @@ Include in the MR description: - Check queries timing (If any): In a single transaction, cumulative query time executed in a migration needs to fit comfortably in `15s` - preferably much less than that - on GitLab.com. - For column removals, make sure the column has been [ignored in a previous release](database/avoiding_downtime_in_migrations.md#dropping-columns) -- Check [background migrations](database/background_migrations.md): +- Check [batched background migrations](database/batched_background_migrations.md): - Establish a time estimate for execution on GitLab.com. For historical purposes, it's highly recommended to include this estimation on the merge request description. + This can be the number of expected batches times the delay interval. + - Manually trigger the [database testing](database/database_migration_pipeline.md) job (`db:gitlabcom-database-testing`) in the `test` stage. - If a single `update` is below than `1s` the query can be placed directly in a regular migration (inside `db/migrate`). - Background migrations are normally used, but not limited to: @@ -253,8 +255,6 @@ Include in the MR description: it's suggested to treat background migrations as [post migrations](migration_style_guide.md#choose-an-appropriate-migration-type): place them in `db/post_migrate` instead of `db/migrate`. - - If a migration [has tracking enabled](database/background_migrations.md#background-jobs-tracking), - ensure `mark_all_as_succeeded` is called even if no work is done. - Check [timing guidelines for migrations](migration_style_guide.md#how-long-a-migration-should-take) - Check migrations are reversible and implement a `#down` method - Check new table migrations: |