重要
このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

GH-ost/PT-oscを使用するデータベースからの移行

本番シナリオでは、DDL実行中のテーブルロックにより、データベースからの読み取りまたはデータベースへの書き込みがある程度ブロックされる可能性があります。したがって、オンラインDDLツールは、読み取りと書き込みへの影響を最小限に抑えるためにDDLを実行するためによく使用されます。一般的なDDLツールは幽霊pt-oscです。

DMを使用してMySQLからTiDBにデータを移行する場合、online-ddlをエンベールして、DMとgh-ostまたはpt-oscのコラボレーションを可能にすることができます。 online-ddlを有効にする方法と、このオプションを有効にした後のワークフローの詳細については、 gh-ostまたはpt-oscを使用した連続レプリケーションを参照してください。このドキュメントでは、DMツールとオンラインDDLツールのコラボレーションの詳細に焦点を当てています。

オンラインDDLツールを使用したDMの作業の詳細

このセクションでは、online-schema-changeを実装する際のオンラインDDLツール幽霊およびpt-oscを使用したDMの作業の詳細について説明します。

online-schema-change:gh-ost

gh-ostがonline-schema-changeを実装すると、次の3種類のテーブルが作成されます。

  • gho:DDLを適用するために使用されます。データが完全に複製され、ghoテーブルがoriginテーブルと一致している場合、originテーブルは名前の変更によって置き換えられます。
  • ghc:online-schema-changeに関連する情報を格納するために使用されます。
  • del:オリジンテーブルの名前を変更して作成されます。

移行の過程で、DMは上記のテーブルを3つのカテゴリに分類します。

  • ghostTable: _*_gho
  • _*_del_*_ghc
  • realTable:online-ddlを実行するオリジンテーブル。

gh-ostで主に使用されるSQLステートメントとそれに対応するDMの操作は次のとおりです。

  1. _ghcのテーブルを作成します。

    Create /* gh-ost */ table `test`.`_test4_ghc` (
                            id bigint auto_increment,
                            last_update timestamp not null DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
                            hint varchar(64) charset ascii not null,
                            value varchar(4096) charset ascii not null,
                            primary key(id),
                            unique key hint_uidx(hint)
                    ) auto_increment=256 ;
    

    DMは_test4_ghcのテーブルを作成しません。

  2. _ghoのテーブルを作成します。

    Create /* gh-ost */ table `test`.`_test4_gho` like `test`.`test4` ;
    

    DMは_test4_ghoのテーブルを作成しません。 DMは、 ghost_schema 、およびghost_table of server_id dm_worker 、ダウンストリームのdm_meta.{task_name}_onlineddlレコードを削除し、メモリ内の関連情報をクリアします。

    DELETE FROM dm_meta.{task_name}_onlineddl WHERE id = {server_id} and ghost_schema = {ghost_schema} and ghost_table = {ghost_table};
    
  3. _ghoのテーブルで実行する必要のあるDDLを適用します。

    Alter /* gh-ost */ table `test`.`_test4_gho` add column cl1 varchar(20) not null ;
    

    DMは_test4_ghoのDDL操作を実行しません。このDDLをdm_meta.{task_name}_onlineddlとメモリに記録します。

    REPLACE INTO dm_meta.{task_name}_onlineddl (id, ghost_schema , ghost_table , ddls) VALUES (......);
    
  4. _ghcのテーブルにデータを書き込み、元のテーブルのデータを_ghoのテーブルに複製します。

    INSERT /* gh-ost */ INTO `test`.`_test4_ghc` VALUES (......);
    INSERT /* gh-ost `test`.`test4` */ ignore INTO `test`.`_test4_gho` (`id`, `date`, `account_id`, `conversion_price`, `ocpc_matched_conversions`, `ad_cost`, `cl2`)
      (SELECT `id`, `date`, `account_id`, `conversion_price`, `ocpc_matched_conversions`, `ad_cost`, `cl2` FROM `test`.`test4` FORCE INDEX (`PRIMARY`)
        WHERE (((`id` > _binary'1') OR ((`id` = _binary'1'))) AND ((`id` < _binary'2') OR ((`id` = _binary'2')))) lock IN share mode
      )   ;
    

    DMは、 realtable用ではないDMLステートメントを実行しません。

  5. 移行が完了すると、元のテーブルと_ghoのテーブルの両方の名前が変更され、オンラインDDL操作が完了します。

    Rename /* gh-ost */ table `test`.`test4` to `test`.`_test4_del`, `test`.`_test4_gho` to `test`.`test4`;
    

    DMは、次の2つの操作を実行します。

    • DMは、上記のrenameつの操作を2つのSQLステートメントに分割します。

      rename test.test4 to test._test4_del;
      rename test._test4_gho to test.test4;
      
    • DMはrename to _test4_delを実行しません。 rename ghost_table to origin tableを実行する場合、DMは次の手順を実行します。

      • 手順3でメモリに記録されたDDLを読み取ります
      • ghost_tableghost_schemaorigin_tableとそれに対応するスキーマに置き換えます
      • 置き換えられたDDLを実行します
      alter table test._test4_gho add column cl1 varchar(20) not null;
      -- Replaced with:
      alter table test.test4 add column cl1 varchar(20) not null;
      

ノート:

gh-ostの特定のSQLステートメントは、実行で使用されるパラメーターによって異なります。このドキュメントには、主要なSQLステートメントのみが記載されています。詳細については、 gh-ostドキュメントを参照してください。

online-schema-change:pt

pt-oscがonline-schema-changeを実装すると、次の2種類のテーブルが作成されます。

  • new :DDLを適用するために使用されます。データが完全に複製され、 newテーブルが元のテーブルと一致する場合、元のテーブルは名前の変更によって置き換えられます。
  • old :オリジンテーブルの名前を変更して作成されます。
  • pt_osc_*_upd種類のトリガーpt_osc_*_del pt_osc_*_ins 。 pt_oscのプロセスで、オリジンテーブルによって生成された新しいデータがトリガーによってnewに複製されます。

移行の過程で、DMは上記のテーブルを3つのカテゴリに分類します。

  • ghostTable: _*_new
  • trashTable: _*_old
  • realTable:online-ddlを実行するオリジンテーブル。

pt-oscで主に使用されるSQLステートメントとそれに対応するDMの操作は次のとおりです。

  1. _newのテーブルを作成します。

    CREATE TABLE `test`.`_test4_new` ( id int(11) NOT NULL AUTO_INCREMENT,
    date date DEFAULT NULL, account_id bigint(20) DEFAULT NULL, conversion_price decimal(20,3) DEFAULT NULL,  ocpc_matched_conversions bigint(20) DEFAULT NULL, ad_cost decimal(20,3) DEFAULT NULL,cl2 varchar(20) COLLATE utf8mb4_bin NOT NULL,cl1 varchar(20) COLLATE utf8mb4_bin NOT NULL,PRIMARY KEY (id) ) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin ;
    

    DMは_test4_newのテーブルを作成しません。 DMは、 ghost_schema 、およびghost_table of server_id dm_worker 、ダウンストリームのdm_meta.{task_name}_onlineddlレコードを削除し、メモリ内の関連情報をクリアします。

    DELETE FROM dm_meta.{task_name}_onlineddl WHERE id = {server_id} and ghost_schema = {ghost_schema} and ghost_table = {ghost_table};
    
  2. _newのテーブルでDDLを実行します。

    ALTER TABLE `test`.`_test4_new` add column c3 int;
    

    DMは_test4_newのDDL操作を実行しません。代わりに、このDDLをdm_meta.{task_name}_onlineddlとメモリに記録します。

    REPLACE INTO dm_meta.{task_name}_onlineddl (id, ghost_schema , ghost_table , ddls) VALUES (......);
    
  3. データ移行に使用する3つのトリガーを作成します。

    CREATE TRIGGER `pt_osc_test_test4_del` AFTER DELETE ON `test`.`test4` ...... ;
    CREATE TRIGGER `pt_osc_test_test4_upd` AFTER UPDATE ON `test`.`test4` ...... ;
    CREATE TRIGGER `pt_osc_test_test4_ins` AFTER INSERT ON `test`.`test4` ...... ;
    

    DMは、TiDBでサポートされていないトリガー操作を実行しません。

  4. 元のテーブルデータを_newのテーブルに複製します。

    INSERT LOW_PRIORITY IGNORE INTO `test`.`_test4_new` (`id`, `date`, `account_id`, `conversion_price`, `ocpc_matched_conversions`, `ad_cost`, `cl2`, `cl1`) SELECT `id`, `date`, `account_id`, `conversion_price`, `ocpc_matched_conversions`, `ad_cost`, `cl2`, `cl1` FROM `test`.`test4` LOCK IN SHARE MODE /*pt-online-schema-change 3227 copy table*/
    

    DMは、 realtable用ではないDMLステートメントを実行しません。

  5. データ移行が完了すると、元のテーブルと_newのテーブルの名前が変更され、オンラインDDL操作が完了します。

    RENAME TABLE `test`.`test4` TO `test`.`_test4_old`, `test`.`_test4_new` TO `test`.`test4`
    

    DMは、次の2つの操作を実行します。

    • DMは、上記のrenameつの操作を2つのSQLステートメントに分割します。

       rename test.test4 to test._test4_old;
       rename test._test4_new to test.test4;
      
    • DMはrename to _test4_oldを実行しません。 rename ghost_table to origin tableを実行する場合、DMは次の手順を実行します。

      • 手順2でメモリに記録されたDDLを読み取ります
      • ghost_tableghost_schemaorigin_tableとそれに対応するスキーマに置き換えます
      • 置き換えられたDDLを実行します
      ALTER TABLE `test`.`_test4_new` add column c3 int;
      -- Replaced with:
      ALTER TABLE `test`.`test4` add column c3 int;
      
  6. オンラインDDL操作の_oldのテーブルと3つのトリガーを削除します。

    DROP TABLE IF EXISTS `test`.`_test4_old`;
    DROP TRIGGER IF EXISTS `pt_osc_test_test4_del` AFTER DELETE ON `test`.`test4` ...... ;
    DROP TRIGGER IF EXISTS `pt_osc_test_test4_upd` AFTER UPDATE ON `test`.`test4` ...... ;
    DROP TRIGGER IF EXISTS `pt_osc_test_test4_ins` AFTER INSERT ON `test`.`test4` ...... ;
    

    DMは_test4_oldとトリガーを削除しません。

ノート:

pt-oscの特定のSQLステートメントは、実行で使用されるパラメーターによって異なります。このドキュメントには、主要なSQLステートメントのみが記載されています。詳細については、 pt-oscドキュメントを参照してください。

その他のオンラインスキーマ変更ツール

場合によっては、オンラインスキーマ変更ツールのデフォルトの動作を変更する必要があります。たとえば、 ghost tabletrash tableにカスタマイズされた名前を使用できます。それ以外の場合は、gh-ostやpt-oscの代わりに、同じ動作原理と変更プロセスで他のツールを使用することをお勧めします。

このようなカスタマイズされたニーズを実現するには、 ghost tabletrash tableの名前に一致する正規表現を作成する必要があります。

v2.0.7以降、DMは変更されたオンラインスキーマ変更ツールを実験的にサポートします。 DMタスク構成でonline-ddl=trueを設定し、 shadow-table-rulestrash-table-rulesを構成することにより、変更された一時テーブルを正規表現と一致させることができます。

たとえば、 ghost tableの名前が_{origin_table}_pcnewtrash tableの名前が_{origin_table}_pcoldのカスタマイズされたpt-oscを使用する場合、カスタムルールを次のように設定できます。

online-ddl: true
shadow-table-rules: ["^_(.+)_(?:pcnew)$"]
trash-table-rules: ["^_(.+)_(?:pcold)$"]