Add latest changes from gitlab-org/gitlab@14-7-stable-eev14.7.0-rc42

1 files changed, 3 insertions, 94 deletions

diff --git a/doc/development/avoiding_downtime_in_migrations.md b/doc/development/avoiding_downtime_in_migrations.md
index a5fc1909551..1d36bbf1212 100644
--- a/doc/development/avoiding_downtime_in_migrations.md
+++ b/doc/development/avoiding_downtime_in_migrations.md
@@ -228,100 +228,9 @@ can take a very long time to complete, preventing a deployment from proceeding.
 They can also produce a lot of pressure on the database due to it rapidly
 updating many rows in sequence.
 
-To reduce database pressure you should instead use
-`change_column_type_using_background_migration` or `rename_column_using_background_migration`
-when migrating a column in a large table (for example, `issues`). These methods work
-similarly to the concurrent counterparts but uses background migration to spread
-the work / load over a longer time period, without slowing down deployments.
-
-For example, to change the column type using a background migration:
-
-```ruby
-class ExampleMigration < Gitlab::Database::Migration[1.0]
-  disable_ddl_transaction!
-
-  class Issue < ActiveRecord::Base
-    self.table_name = 'issues'
-
-    include EachBatch
-
-    def self.to_migrate
-      where('closed_at IS NOT NULL')
-    end
-  end
-
-  def up
-    change_column_type_using_background_migration(
-      Issue.to_migrate,
-      :closed_at,
-      :datetime_with_timezone
-    )
-  end
-
-  def down
-    change_column_type_using_background_migration(
-      Issue.to_migrate,
-      :closed_at,
-      :datetime
-    )
-  end
-end
-```
-
-This would change the type of `issues.closed_at` to `timestamp with time zone`.
-
-Keep in mind that the relation passed to
-`change_column_type_using_background_migration` _must_ include `EachBatch`,
-otherwise it will raise a `TypeError`.
-
-This migration then needs to be followed in a separate release (_not_ a patch
-release) by a cleanup migration, which should steal from the queue and handle
-any remaining rows. For example:
-
-```ruby
-class MigrateRemainingIssuesClosedAt < Gitlab::Database::Migration[1.0]
-  disable_ddl_transaction!
-
-  class Issue < ActiveRecord::Base
-    self.table_name = 'issues'
-    include EachBatch
-  end
-
-  def up
-    Gitlab::BackgroundMigration.steal('CopyColumn')
-    Gitlab::BackgroundMigration.steal('CleanupConcurrentTypeChange')
-
-    migrate_remaining_rows if migrate_column_type?
-  end
-
-  def down
-    # Previous migrations already revert the changes made here.
-  end
-
-  def migrate_remaining_rows
-    Issue.where('closed_at_for_type_change IS NULL AND closed_at IS NOT NULL').each_batch do |batch|
-      batch.update_all('closed_at_for_type_change = closed_at')
-    end
-
-    cleanup_concurrent_column_type_change(:issues, :closed_at)
-  end
-
-  def migrate_column_type?
-    # Some environments may have already executed the previous version of this
-    # migration, thus we don't need to migrate those environments again.
-    column_for('issues', 'closed_at').type == :datetime # rubocop:disable Migration/Datetime
-  end
-end
-```
-
-The same applies to `rename_column_using_background_migration`:
-
-1. Create a migration using the helper, which will schedule background
-   migrations to spread the writes over a longer period of time.
-1. In the next monthly release, create a clean-up migration to steal from the
-   Sidekiq queues, migrate any missing rows, and cleanup the rename. This
-   migration should skip the steps after stealing from the Sidekiq queues if the
-   column has already been renamed.
+To reduce database pressure you should instead use a background migration
+when migrating a column in a large table (for example, `issues`). This will
+spread the work / load over a longer time period, without slowing down deployments.
 
 For more information, see [the documentation on cleaning up background
 migrations](background_migrations.md#cleaning-up).