What requires downtime? · Gitlab 中文文檔

# What requires downtime? > 原文：[https://docs.gitlab.com/ee/development/what_requires_downtime.html](https://docs.gitlab.com/ee/development/what_requires_downtime.html) * [Dropping Columns](#dropping-columns) * [Step 1: Ignoring the column (release M)](#step-1-ignoring-the-column-release-m) * [Step 2: Dropping the column (release M+1)](#step-2-dropping-the-column-release-m1) * [Step 3: Removing the ignore rule (release M+2)](#step-3-removing-the-ignore-rule-release-m2) * [Renaming Columns](#renaming-columns) * [Step 1: Add The Regular Migration](#step-1-add-the-regular-migration) * [Step 2: Add A Post-Deployment Migration](#step-2-add-a-post-deployment-migration) * [Changing Column Constraints](#changing-column-constraints) * [Changing Column Types](#changing-column-types) * [Step 1: Create A Regular Migration](#step-1-create-a-regular-migration) * [Step 2: Create A Post Deployment Migration](#step-2-create-a-post-deployment-migration) * [Casting data to a new type](#casting-data-to-a-new-type) * [Changing The Schema For Large Tables](#changing-the-schema-for-large-tables) * [Adding Indexes](#adding-indexes) * [Dropping Indexes](#dropping-indexes) * [Adding Tables](#adding-tables) * [Dropping Tables](#dropping-tables) * [Renaming Tables](#renaming-tables) * [Adding Foreign Keys](#adding-foreign-keys) * [Removing Foreign Keys](#removing-foreign-keys) * [Data Migrations](#data-migrations) # What requires downtime?[](#what-requires-downtime "Permalink") 使用數據庫時，可以在不使 GitLab 脫機的情況下執行某些操作，其他操作確實需要停機時間. 本指南介紹了各種操作，其影響以及如何在不停機的情況下執行這些操作. ## Dropping Columns[](#dropping-columns "Permalink") 刪除列很棘手，因為正在運行的 GitLab 進程可能仍在使用這些列. 為了安全地解決此問題，您需要在三個版本中執行三個步驟： 1. 忽略列（版本 M） 2. 刪除列（版本 M + 1） 3. 刪除忽略規則（版本 M + 2）之所以將其分布在三個發行版中，是因為刪除列是一種破壞性操作，不易回滾. 遵循此過程可幫助我們確保沒有部署到 GitLab.com 并升級將這些步驟集中在一起的自我管理安裝的過程. ### Step 1: Ignoring the column (release M)[](#step-1-ignoring-the-column-release-m "Permalink") 第一步是忽略應用程序代碼中的列. 這是必要的，因為 Rails 緩存列并在各個地方重復使用此緩存. 這可以通過定義要忽略的列來完成. 例如，要忽略用戶模型中的`updated_at` ，請使用以下命令： ``` class User < ApplicationRecord include IgnorableColumns ignore_column :updated_at, remove_with: '12.7', remove_after: '2019-12-22' end ``` 多列也可以忽略： ``` ignore_columns %i[updated_at created_at], remove_with: '12.7', remove_after: '2019-12-22' ``` 我們要求通過以下方式指示何時可以安全地刪除列忽略： * `remove_with` ：設置為 GitLab 版本，通常在添加列忽略后兩個版本（M + 2）. * `remove_after` ：設置為一個日期，在該日期之后，我們認為通常可以在 M + 2 版本的開發周期內刪除列忽略項. 這些信息使我們能夠更好地推理列忽略，并確保對于常規發行版和部署到 GitLab.com 而言，我們都不會過早刪除列忽略. 例如，這避免了我們部署大量更改的情況，其中包括同時忽略列的更改和隨后刪除列忽略的更改（這將導致停機）. 在此示例中，忽略列的更改在 12.5 版中進行. ### Step 2: Dropping the column (release M+1)[](#step-2-dropping-the-column-release-m1 "Permalink") 繼續我們的示例，刪除該列將進入版本 12.6 中*的部署后*遷移： ``` remove_column :user, :updated_at ``` ### Step 3: Removing the ignore rule (release M+2)[](#step-3-removing-the-ignore-rule-release-m2 "Permalink") 在下一個版本中，在此示例 12.7 中，我們設置了另一個合并請求以刪除忽略規則. 這將刪除`ignore_column`行，并且如果不再需要，還將`IgnoreableColumns` . 只有在`remove_after`日期過去之后，才應將其與`remove_with`指示的發行版合并. ## Renaming Columns[](#renaming-columns "Permalink") 重命名列通常需要停機，因為在數據庫遷移期間/之后，應用程序可能會繼續使用舊的列名稱. 要在不停機的情況下重命名列，我們需要兩個遷移：常規遷移和部署后遷移. 這些遷移都可以在同一版本中進行. ### Step 1: Add The Regular Migration[](#step-1-add-the-regular-migration "Permalink") 首先，我們需要創建常規遷移. 此遷移應當前使用`Gitlab::Database::MigrationHelpers#rename_column_concurrently`來執行重命名. 例如 ``` # A regular migration in db/migrate class RenameUsersUpdatedAtToUpdatedAtTimestamp < ActiveRecord::Migration[4.2] include Gitlab::Database::MigrationHelpers disable_ddl_transaction! def up rename_column_concurrently :users, :updated_at, :updated_at_timestamp end def down undo_rename_column_concurrently :users, :updated_at, :updated_at_timestamp end end ``` 這將負責重命名列，確保數據保持同步，通過索引和外鍵進行復制等. **注意：**如果一列包含 1 個或多個不包含原始列名稱的索引，則上述過程將失敗. 在這種情況下，您首先需要重命名這些索引. ### Step 2: Add A Post-Deployment Migration[](#step-2-add-a-post-deployment-migration "Permalink") 重命名過程需要在部署后遷移中進行一些清理. 我們可以使用`Gitlab::Database::MigrationHelpers#cleanup_concurrent_column_rename`來執行此清理： ``` # A post-deployment migration in db/post_migrate class CleanupUsersUpdatedAtRename < ActiveRecord::Migration[4.2] include Gitlab::Database::MigrationHelpers disable_ddl_transaction! def up cleanup_concurrent_column_rename :users, :updated_at, :updated_at_timestamp end def down undo_cleanup_concurrent_column_rename :users, :updated_at, :updated_at_timestamp end end ``` **注意：**如果要重命名[大表](https://gitlab.com/gitlab-org/gitlab/-/blob/master/rubocop/rubocop-migrations.yml#L3) ，請仔細考慮第一次遷移已運行但第二次清理遷移尚未運行的狀態. 使用[Canary](https://about.gitlab.com/handbook/engineering/infrastructure/library/canary/) ，系統可能會在此狀態下運行大量時間. ## Changing Column Constraints[](#changing-column-constraints "Permalink") 通常，無需停機即可添加或刪除`NOT NULL`子句（或其他約束）. 但是，這確實需要*首先*部署所有應用程序更改. 因此，在部署后的遷移中應該發生更改列約束的情況. 避免使用`change_column`因為它會產生無效查詢，因為它會重新定義整個列類型. 您可以針對每個特定用例查看以下指南： * [Adding foreign-key constraints](migration_style_guide.html#adding-foreign-key-constraints) * [Adding `NOT NULL` constraints](database/not_null_constraints.html) * [Adding limits to text columns](database/strings_and_the_text_data_type.html) ## Changing Column Types[](#changing-column-types "Permalink") 可以使用`Gitlab::Database::MigrationHelpers#change_column_type_concurrently`來更改列的類型. 此方法的工作方式與`rename_column_concurrently`類似. 例如，假設我們要將`users.username`的類型從`string`更改為`text` . ### Step 1: Create A Regular Migration[](#step-1-create-a-regular-migration "Permalink") 常規遷移用于創建具有臨時名稱的新列，并設置一些觸發器以使數據保持同步. 這樣的遷移如下所示： ``` # A regular migration in db/migrate class ChangeUsersUsernameStringToText < ActiveRecord::Migration[4.2] include Gitlab::Database::MigrationHelpers disable_ddl_transaction! def up change_column_type_concurrently :users, :username, :text end def down cleanup_concurrent_column_type_change :users, :username end end ``` ### Step 2: Create A Post Deployment Migration[](#step-2-create-a-post-deployment-migration "Permalink") 接下來，我們需要使用部署后遷移來清理更改： ``` # A post-deployment migration in db/post_migrate class ChangeUsersUsernameStringToTextCleanup < ActiveRecord::Migration[4.2] include Gitlab::Database::MigrationHelpers disable_ddl_transaction! def up cleanup_concurrent_column_type_change :users, :username end def down change_column_type_concurrently :users, :username, :string end end ``` 就是這樣，我們完成了！ ### Casting data to a new type[](#casting-data-to-a-new-type "Permalink") 某些類型更改需要將數據轉換為新類型. 例如，從`text`更改為`jsonb` . 在這種情況下，請使用`type_cast_function`選項. 確保沒有不良數據，并且投射將始終成功. 您還可以提供一個自定義函數來處理轉換錯誤. 遷移示例： ``` def up change_column_type_concurrently :users, :settings, :jsonb, type_cast_function: 'jsonb' end ``` ## Changing The Schema For Large Tables[](#changing-the-schema-for-large-tables "Permalink") 雖然`change_column_type_concurrently`和`rename_column_concurrently`可以用于在`rename_column_concurrently`機的情況下更改表的架構，但對于大型表來說，效果并不理想. 由于所有工作都是按順序進行的，因此遷移可能需要很長時間才能完成，從而阻止了部署的進行. 由于數據庫按順序快速更新許多行，因此它們也可能給數據庫帶來很大壓力. 為減輕數據庫壓力，在遷移大表中的列時（例如`issues` ），應改用`change_column_type_using_background_migration`或`rename_column_using_background_migration` . 這些方法的工作方式與并發的類似，但是使用后臺遷移將工作/負載分散在更長的時間段內，而不會減慢部署速度. 例如，要使用后臺遷移來更改列類型： ``` class ExampleMigration < ActiveRecord::Migration[4.2] include Gitlab::Database::MigrationHelpers 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 ``` 這將將`issues.closed_at`的類型更改為`timestamp with time zone` . 請記住，傳遞給`change_column_type_using_background_migration`的關系*必須*包含`EachBatch` ，否則將引發`TypeError` . 然后，此遷移需要在單獨的發行版（ *而不是*補丁程序發行版）中進行清除遷移，該清除遷移應從隊列中竊取并處理所有剩余的行. 例如： ``` class MigrateRemainingIssuesClosedAt < ActiveRecord::Migration[4.2] include Gitlab::Database::MigrationHelpers DOWNTIME = false 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 ``` 這同樣適用于`rename_column_using_background_migration` ： 1. 使用幫助程序創建遷移，該遷移將安排后臺遷移以將寫入分散在更長的時間范圍內. 2. 在下一個每月發行版中，創建清理遷移以從 Sidekiq 隊列中竊取，遷移所有丟失的行并清理重命名. 如果該列已被重命名，則此遷移應在從 Sidekiq 隊列中竊取后跳過步驟. 有關更多信息，請參閱[有關清理后臺遷移的文檔](background_migrations.html#cleaning-up) . ## Adding Indexes[](#adding-indexes "Permalink") 使用`add_concurrent_index`時，添加索引不需要停機. 另請參閱《 [遷移樣式指南》](migration_style_guide.html#adding-indexes) . ## Dropping Indexes[](#dropping-indexes "Permalink") 刪除索引不需要停機. ## Adding Tables[](#adding-tables "Permalink") 此操作是安全的，因為還沒有使用該表的代碼. ## Dropping Tables[](#dropping-tables "Permalink") 使用部署后遷移可以安全地完成刪除表的操作，但前提是應用程序不再使用該表. ## Renaming Tables[](#renaming-tables "Permalink") 重命名表需要停機，因為在數據庫遷移期間/之后，應用程序可能會繼續使用舊表名. ## Adding Foreign Keys[](#adding-foreign-keys "Permalink") 添加外鍵通常需要 3 個步驟： 1. 開始交易 2. 運行`ALTER TABLE`添加約束 3. 檢查所有現有數據因為`ALTER TABLE`通常會在事務結束之前獲取獨占鎖，所以這意味著該方法將需要停機. GitLab allows you to work around this by using `Gitlab::Database::MigrationHelpers#add_concurrent_foreign_key`. This method ensures that no downtime is needed. ## Removing Foreign Keys[](#removing-foreign-keys "Permalink") 此操作不需要停機. ## Data Migrations[](#data-migrations "Permalink") 數據遷移可能很棘手. 遷移數據的通常方法是采取 3 個步驟： 1. 遷移初始數據 2. 部署應用程序代碼 3. 遷移所有剩余數據通常這有效，但并非總是如此. 例如，如果要將字段的格式從 JSON 更改為其他格式，我們會遇到一些問題. 如果我們在部署應用程序代碼之前更改現有數據，則很可能會遇到錯誤. 另一方面，如果我們在部署應用程序代碼后進行遷移，則可能會遇到相同的問題. 如果您只需要更正一些無效數據，則部署后遷移通常就足夠了. 如果您需要更改數據格式（例如，從 JSON 更改為其他格式），通常最好為新數據格式添加一個新列，然后讓應用程序使用該列. 在這種情況下，程序將是： 1. 以新格式添加新列 2. 將現有數據復制到此新列 3. 部署應用程序代碼 4. In a post-deployment migration, copy over any remaining data 通常，沒有一個萬能的解決方案，因此最好在合并請求中討論此類遷移，以確保以最佳方式實現它們.