Commit 2aec9637 authored by Krasimir Angelov's avatar Krasimir Angelov Committed by Nick Gaskill

Enable by default scheduled execution of batched background migrations

parent f5fb758b
......@@ -16,7 +16,7 @@ module Database
INTERVAL_VARIANCE = 5.seconds.freeze
def perform
return unless Feature.enabled?(:execute_batched_migrations_on_schedule, type: :ops) && active_migration
return unless Feature.enabled?(:execute_batched_migrations_on_schedule, type: :ops, default_enabled: :yaml) && active_migration
with_exclusive_lease(active_migration.interval) do
# Now that we have the exclusive lease, reload migration in case another process has changed it.
......
---
title: Enable by default scheduled execution of batched background migrations
merge_request: 61316
author:
type: added
......@@ -5,4 +5,4 @@ rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/326241
milestone: '13.11'
type: ops
group: group::database
default_enabled: false
default_enabled: true
......@@ -107,6 +107,10 @@ Sidekiq::Queue.new("background_migration").size
Sidekiq::ScheduledSet.new.select { |r| r.klass == 'BackgroundMigrationWorker' }.size
```
### Batched background migrations
See the documentation on [batched background migrations](../user/admin_area/monitoring/background_migrations.md).
### What do I do if my background migrations are stuck?
WARNING:
......
---
stage: Enablement
group: Database
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# Batched Background Migrations **(FREE SELF)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/51332) in GitLab 13.11.
> - [Deployed behind a feature flag](../../../user/feature_flags.md), disabled by default.
> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/329511) in GitLab 13.12.
> - Enabled on GitLab.com.
> - Recommended for production use.
> - For GitLab self-managed instances, GitLab administrators can opt to [disable it](#enable-or-disable-batched-background-migrations). **(FREE SELF)**
There can be [risks when disabling released features](../../../user/feature_flags.md#risks-when-disabling-released-features).
Refer to this feature's version history for more details.
To update database tables in batches, GitLab can use batched background migrations. These migrations
are created by GitLab developers and run automatically on upgrade. However, such migrations are
limited in scope to help with migrating some `integer` database columns to `bigint`. This is needed to
prevent integer overflow for some tables.
All migrations must be finished before upgrading GitLab. To check the status of the existing
migrations, execute this command:
```ruby
Gitlab::Database::BackgroundMigration::BatchedMigration.pluck(:id, :table_name, :status)
```
## Enable or disable Batched Background Migrations **(FREE SELF)**
Batched Background Migrations is under development but ready for production use.
It is deployed behind a feature flag that is **enabled by default**.
[GitLab administrators with access to the GitLab Rails console](../../../administration/feature_flags.md)
can opt to disable it.
To enable it:
```ruby
Feature.enable(:execute_batched_migrations_on_schedule)
```
To disable it:
```ruby
Feature.disable(:execute_batched_migrations_on_schedule)
```
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