主な機能

このドキュメントでは、TiDB Data Migration (DM) によって提供されるデータ移行機能について説明し、適切なパラメーター構成を紹介します。

DM のバージョンが異なると、テーブル ルーティング、ブロック リストと許可リスト、binlog イベント フィルター機能でスキーマまたはテーブル名の一致ルールが異なることに注意してください。

  • DM v1.0.5 以降のバージョンでは、上記のすべての機能がワイルドカードマッチをサポートしています。 DM のすべてのバージョンで、ワイルドカード式に使用できる*1 つだけであり、最後に*を配置する必要があることに注意してください。
  • v1.0.5 より前の DM バージョンでは、テーブル ルーティングと binlog イベント フィルターはワイルドカードをサポートしますが、 [...][!...]の式はサポートしません。ブロック & 許可リストは、正規表現のみをサポートしています。

単純なシナリオでのマッチングには、ワイルドカードを使用することをお勧めします。

テーブル ルーティング

テーブル ルーティング機能により、DM は上流の MySQL または MariaDB インスタンスの特定のテーブルを下流の指定されたテーブルに移行できます。

ノート:

  • 1 つのテーブルに対して複数の異なるルーティング ルールを構成することはサポートされていません。
  • スキーマの一致ルールは、 パラメータ構成rule-2に示すように、移行CREATE/DROP SCHEMA xxに使用される個別に構成する必要があります。

パラメータ構成

routes: rule-1: schema-pattern: "test_*" table-pattern: "t_*" target-schema: "test" target-table: "t" rule-2: schema-pattern: "test_*" target-schema: "test"

パラメータの説明

DM は、 テーブル セレクターによって提供されるschema-pattern / table-patternルールに一致する上流の MySQL または MariaDB インスタンス テーブルを下流のtarget-schema / target-tableに移行します。

使用例

このセクションでは、さまざまなシナリオでの使用例を示します。

シャードされたスキーマとテーブルをマージする

シャードされたスキーマとテーブルのシナリオで、 test_{1,2,3...}を移行すると仮定します。 testへの 2 つのアップストリーム MySQL インスタンスのt_{1,2,3...}のテーブル。ダウンストリーム TiDB インスタンスのtテーブル。

アップストリーム インスタンスをダウンストリームに移行するにはtest . tでは、次のルーティング ルールを作成する必要があります。

  • rule-1は、 schema-pattern: "test_*"table-pattern: "t_*"に一致するテーブルの DML または DDL ステートメントをダウンストリームtestに移行するために使用されます。 t .
  • rule-2は、 CREATE/DROP SCHEMA xxなどのschema-pattern: "test_*"に一致するスキーマの DDL ステートメントを移行するために使用されます。

ノート:

  • ダウンストリームschema: testが既に存在し、削除しない場合は、 rule-2を省略できます。
  • ダウンストリームschema: testが存在せず、 rule-1のみが構成されている場合、移行中にschema test doesn't existエラーが報告されます。
rule-1: schema-pattern: "test_*" table-pattern: "t_*" target-schema: "test" target-table: "t" rule-2: schema-pattern: "test_*" target-schema: "test"

シャードされたスキーマをマージする

シャード スキーマのシナリオで、 test_{1,2,3...}を移行すると仮定します。 2 つのアップストリーム MySQL インスタンスのt_{1,2,3...}のテーブルからtest .ダウンストリームの TiDB インスタンスにt_{1,2,3...}のテーブル。

アップストリーム スキーマをダウンストリームに移行するにはtest . t_[1,2,3]では、ルーティング ルールを 1 つだけ作成する必要があります。

rule-1: schema-pattern: "test_*" target-schema: "test"

不適切なテーブル ルーティング

次の 2 つのルーティング ルールが構成されていると仮定しtest_1_bakt_1_bakrule-1rule-2の両方に一致する場合、テーブル ルーティング構成が数の制限に違反しているため、エラーが報告されます。

rule-1: schema-pattern: "test_*" table-pattern: "t_*" target-schema: "test" target-table: "t" rule-2: schema-pattern: "test_1_bak" table-pattern: "t_1_bak" target-schema: "test" target-table: "t_bak"

テーブル リストのブロックと許可

アップストリーム データベース インスタンス テーブルのブロック リストと許可リストのフィルタリング ルールは、MySQL の replication-rules-db/tables に似ており、一部のデータベースまたは一部のテーブルのすべての操作をフィルタリングまたは移行するために使用できます。

パラメータ構成

block-allow-list: # Use black-white-list if the DM version is earlier than or equal to v2.0.0-beta.2. rule-1: do-dbs: ["test*"] # Starting with characters other than "~" indicates that it is a wildcard; # v1.0.5 or later versions support the regular expression rules. do-tables: - db-name: "test[123]" # Matches test1, test2, and test3. tbl-name: "t[1-5]" # Matches t1, t2, t3, t4, and t5. - db-name: "test" tbl-name: "t" rule-2: do-dbs: ["~^test.*"] # Starting with "~" indicates that it is a regular expression. ignore-dbs: ["mysql"] do-tables: - db-name: "~^test.*" tbl-name: "~^t.*" - db-name: "test" tbl-name: "t" ignore-tables: - db-name: "test" tbl-name: "log"

パラメータの説明

  • do-dbs : スキーマのリストの移行を許可します。MySQL のreplicate-do-dbと同様です。
  • ignore-dbs : 移行するスキーマのブロック リスト。MySQL のreplicate-ignore-dbに似ています。
  • do-tables : MySQL のreplicate-do-tableと同様に、テーブルのリストの移行を許可します。 db-nametbl-nameの両方を指定する必要があります
  • ignore-tables : 移行するテーブルのブロック リスト。MySQL のreplicate-ignore-tableに似ています。 db-nametbl-nameの両方を指定する必要があります

上記のパラメーターの値が~文字で始まる場合、この値の後続の文字は正規表現として扱われます。このパラメーターを使用して、スキーマまたはテーブル名を一致させることができます。

フィルタリングプロセス

do-dbsignore-dbsに対応するフィルタリング ルールは、MySQL のデータベース レベルのレプリケーションおよびバイナリ ログ オプションの評価に似ています。 do-tablesignore-tablesに対応するフィルタリング ルールは、MySQL のテーブル レベルのレプリケーション オプションの評価に似ています。

ノート:

DM と MySQL では、許可リストとブロック リストのフィルタリング ルールは次の点で異なります。

  • MySQL では、 replicate-wild-do-tablereplicate-wild-ignore-tableはワイルドカード文字をサポートしています。 DM では、一部のパラメーター値は、 ~文字で始まる正規表現を直接サポートしています。
  • DM は現在、 ROW形式のバイナリログのみをサポートしており、 STATEMENTまたはMIXED形式のバイナリログはサポートしていません。したがって、DM のフィルタリング ルールは、MySQL のROW形式のフィルタリング ルールに対応します。
  • MySQL は、ステートメントのUSEセクションで明示的に指定されたデータベース名によってのみ DDL ステートメントを決定します。 DM は、最初に DDL ステートメントのデータベース名セクションに基づいてステートメントを決定します。 DDL ステートメントにそのようなセクションが含まれていない場合、DM はUSEセクションによってステートメントを判別します。判別する SQL ステートメントがUSE test_db_2; CREATE TABLE test_db_1.test_table (c1 INT PRIMARY KEY)であるとします。 replicate-do-db=test_db_1は MySQL で構成され、 do-dbs: ["test_db_1"]は DM で構成されます。次に、このルールは DM にのみ適用され、MySQL には適用されません。

フィルタリング プロセスは次のとおりです。

  1. スキーマ レベルでフィルター処理します。

    • do-dbsが空でない場合、一致するスキーマがdo-dbsに存在するかどうかを判断します。

      • はいの場合は、引き続きテーブル レベルでフィルタリングします。
      • そうでない場合は、フィルタtestを使用します。 t .
    • do-dbsが空でignore-dbsが空でない場合、 ignore-dbsで一致するスキーマが存在するかどうかを判断します。

      • はいの場合、フィルターtestt .
      • そうでない場合は、引き続きテーブル レベルでフィルタリングします。
    • do-dbsignore-dbsの両方が空の場合は、引き続きテーブル レベルでフィルタリングします。

  2. テーブル レベルでフィルター処理します。

    1. do-tablesが空でない場合、 do-tablesに一致するテーブルが存在するかどうかを判断します。

      • はいの場合は、移行testします。 t .
      • そうでない場合は、フィルタtestを使用します。 t .
    2. ignore-tablesが空でない場合、 ignore-tablesに一致するテーブルが存在するかどうかを判断します。

      • はいの場合、フィルターtestt .
      • そうでない場合は、移行testします。 t .
    3. do-tablesignore-tablesの両方が空の場合は、 testを移行します。 t .

ノート:

スキーマtestをフィルタリングする必要があるかどうかを判断するには、スキーマ レベルでフィルタリングするだけで済みます。

使用例

アップストリームの MySQL インスタンスに次のテーブルが含まれているとします。

`logs`.`messages_2016` `logs`.`messages_2017` `logs`.`messages_2018` `forum`.`users` `forum`.`messages` `forum_backup_2016`.`messages` `forum_backup_2017`.`messages` `forum_backup_2018`.`messages`

構成は次のとおりです。

block-allow-list: # Use black-white-list if the DM version is earlier than or equal to v2.0.0-beta.2. bw-rule: do-dbs: ["forum_backup_2018", "forum"] ignore-dbs: ["~^forum_backup_"] do-tables: - db-name: "logs" tbl-name: "~_2018$" - db-name: "~^forum.*" tbl-name: "messages" ignore-tables: - db-name: "~.*" tbl-name: "^messages.*"

bw-ruleルールを使用した後:

テーブルフィルタリングするかどうかフィルタリングする理由
logs . messages_2016はいスキーマlogsはどのdo-dbsとも一致しません。
logs . messages_2017はいスキーマlogsはどのdo-dbsとも一致しません。
logs . messages_2018はいスキーマlogsはどのdo-dbsとも一致しません。
forum_backup_2016 . messagesはいスキーマforum_backup_2016はどのdo-dbsとも一致しません。
forum_backup_2017 . messagesはいスキーマforum_backup_2017はどのdo-dbsとも一致しません。
forum . usersはい
  • スキーマforumdo-dbsに一致し、引き続きテーブル レベルでフィルタリングします。
    2. スキーマとテーブルはdo-tablesignore-tablesのいずれとも一致せず、 do-tablesは空ではありません。
  • forum . messagesいいえ
  • スキーマforumdo-dbsに一致し、引き続きテーブル レベルでフィルタリングします。
    2. 表messagesdo-tablesdb-name: "~^forum.*",tbl-name: "messages"の中にあります。
  • forum_backup_2018 . messagesいいえ
  • スキーマforum_backup_2018do-dbsに一致し、引き続きテーブル レベルでフィルタリングします。
    2. スキーマとテーブルはdb-name: "~^forum.*",tbl-name: "messages" of do-tablesと一致します。
  • Binlogイベント フィルター

    Binlogイベント フィルターは、ブロックおよび許可リストのフィルター処理ルールよりも細かいフィルター処理ルールです。 INSERTまたはTRUNCATE TABLEのようなステートメントを使用して、移行またはフィルターで除外する必要があるschema/tableのバイナリログ イベントを指定できます。

    ノート:

    • 同じテーブルが複数のルールに一致する場合、これらのルールは順番に適用され、ブロック リストは許可リストよりも優先されます。これは、テーブルにIgnoreDoの両方のルールが適用されている場合、 Ignoreのルールが有効になることを意味します。
    • DM v2.0.2 以降では、ソース構成ファイルで binlog イベント フィルターを構成できます。詳細については、 アップストリーム データベースConfiguration / コンフィグレーションファイルを参照してください。

    パラメータ構成

    filters: rule-1: schema-pattern: "test_*" ​table-pattern: "t_*" ​events: ["truncate table", "drop table"] sql-pattern: ["^DROP\\s+PROCEDURE", "^CREATE\\s+PROCEDURE"] ​action: Ignore

    パラメータの説明

    • schema-pattern / table-pattern : schema-pattern / table-patternに一致する上流の MySQL または MariaDB インスタンス テーブルの binlog イベントまたは DDL SQL ステートメントは、以下のルールによってフィルター処理されます。

    • events : バイナリログ イベント配列。次の表から 1 つ以上のEventのみを選択できます。

      イベントタイプ説明
      all以下のすべてのイベントが含まれます
      all dml以下のすべての DML イベントが含まれます
      all ddl以下のすべての DDL イベントが含まれます
      none以下のイベントは含まれません
      none ddl以下の DDL イベントは含まれません
      none dml以下の DML イベントは含まれません
      insertDMLINSERT DML イベント
      updateDMLUPDATE DML イベント
      deleteDMLDELETE DML イベント
      create databaseDDLCREATE DATABASE DDL イベント
      drop databaseDDLDROP DATABASE DDL イベント
      create tableDDLCREATE TABLE DDL イベント
      create indexDDLCREATE INDEX DDL イベント
      drop tableDDLDROP TABLE DDL イベント
      truncate tableDDLTRUNCATE TABLE DDL イベント
      rename tableDDLRENAME TABLE DDL イベント
      drop indexDDLDROP INDEX DDL イベント
      alter tableDDLALTER TABLE DDL イベント
    • sql-pattern : 指定された DDL SQL ステートメントをフィルタリングするために使用されます。一致ルールは、正規表現の使用をサポートしています。たとえば、 "^DROP\\s+PROCEDURE"です。

    • action : 文字列 ( Do / Ignore )。以下のルールに基づいて、フィルタリングするかどうかを判断します。 2 つのルールのいずれかが満たされる場合、バイナリログはフィルタリングされます。それ以外の場合、バイナリログはフィルタリングされません。

      • Do : 許可リスト。 binlog は、次の 2 つの条件のいずれかでフィルター処理されます。
        • イベントのタイプがルールのeventリストにありません。
        • イベントの SQL ステートメントは、ルールのsql-patternつと一致しません。
      • Ignore : ブロック リスト。 binlog は、次の 2 つの条件のいずれかでフィルター処理されます。
        • イベントのタイプは、ルールのeventリストにあります。
        • イベントの SQL ステートメントは、ルールのsql-patternに一致できます。

    使用例

    このセクションでは、シャーディングのシナリオ (シャードされたスキーマとテーブル) での使用例を示します。

    すべてのシャーディング削除操作をフィルタリングする

    すべての削除操作を除外するには、次の 2 つのフィルタリング ルールを構成します。

    • filter-table-ruleは、 drop table truncate tableおよびdelete statement操作を除外しtest_*t_*パターン。
    • filter-schema-ruleは、 test_*のパターンに一致するすべてのスキーマのdrop databaseの操作を除外します。
    filters: filter-table-rule: schema-pattern: "test_*" table-pattern: "t_*" events: ["truncate table", "drop table", "delete"] action: Ignore filter-schema-rule: schema-pattern: "test_*" events: ["drop database"] action: Ignore

    シャーディング DML ステートメントのみを移行する

    シャーディング DML ステートメントのみを移行するには、次の 2 つのフィルタリング ルールを構成します。

    • do-table-ruleは、 test_*に一致するすべてのテーブルのcreate tableinsertupdate 、およびdeleteステートメントのみを移行します。 t_*パターン。
    • do-schema-ruleは、 test_*パターンに一致するすべてのスキーマのcreate databaseステートメントのみを移行します。

    ノート:

    create database/tableステートメントが移行される理由は、スキーマとテーブルが作成された後にのみ DML ステートメントを移行できるためです。

    filters: do-table-rule: schema-pattern: "test_*" table-pattern: "t_*" events: ["create table", "all dml"] action: Do do-schema-rule: schema-pattern: "test_*" events: ["create database"] action: Do

    TiDB がサポートしていない SQL ステートメントを除外する

    TiDB がサポートしていないPROCEDUREステートメントを除外するには、次のfilter-procedure-ruleを構成します。

    filters: filter-procedure-rule: schema-pattern: "test_*" table-pattern: "t_*" sql-pattern: ["^DROP\\s+PROCEDURE", "^CREATE\\s+PROCEDURE"] action: Ignore

    filter-procedure-ruleは、 test_*に一致するすべてのテーブルの^CREATE\\s+PROCEDUREおよび^DROP\\s+PROCEDUREステートメントを除外します。 t_*パターン。

    TiDB パーサーがサポートしていない SQL ステートメントを除外する

    tableパーサーがサポートしていない SQL ステートメントの場合、DM はそれらを解析してschema情報を取得できません。したがって、グローバル フィルタリング ルールschema-pattern: "*"を使用する必要があります。

    ノート:

    移行する必要のあるデータを除外しないようにするには、グローバル フィルタリング ルールをできるだけ厳密に構成する必要があります。

    TiDB パーサー (一部のバージョン) がサポートしていないPARTITIONステートメントを除外するには、次のフィルター規則を構成します。

    filters: filter-partition-rule: schema-pattern: "*" sql-pattern: ["ALTER\\s+TABLE[\\s\\S]*ADD\\s+PARTITION", "ALTER\\s+TABLE[\\s\\S]*DROP\\s+PARTITION"] action: Ignore

    オンライン DDL ツール

    MySQL エコシステムでは、gh-ost や pt-osc などのツールが広く使用されています。 DM は、これらのツールをサポートして、不要な中間データの移行を回避します。

    制限

    • DM は gh-ost と pt-osc のみをサポートします。
    • online-ddlが有効な場合、増分レプリケーションに対応するチェックポイントは、オンライン DDL 実行のプロセスにあってはなりません。たとえば、アップストリームのオンライン DDL 操作がバイナリログのposition-Aで開始し、 position-Bで終了する場合、増分レプリケーションの開始点はposition-Aより前またはposition-Bより後である必要があります。そうしないと、エラーが発生します。詳細はFAQを参照してください。

    パラメータ構成

    • v2.0.5 and later
    • earlier than v2.0.5

    v2.0.5 以降のバージョンでは、 task構成ファイルのonline-ddl構成アイテムを使用する必要があります。

    • 上流の MySQL/MariaDB が (同時に) gh-ost または pt-osc ツールを使用する場合は、タスク構成ファイルでonline-ddlからtrueを設定します。
    online-ddl: true

    ノート:

    v2.0.5 以降、 online-ddl-schemeは廃止されたため、 online-ddl-schemeの代わりにonline-ddlを使用する必要があります。つまり、設定online-ddl: trueonline-ddl-schemeを上書きし、設定online-ddl-scheme: "pt"またはonline-ddl-scheme: "gh-ost"online-ddl: trueに変換されます。

    v2.0.5 より前 (v2.0.5 を除く) では、 task構成ファイルのonline-ddl-scheme構成アイテムを使用する必要があります。

    • アップストリームの MySQL/MariaDB が gh-ost ツールを使用している場合は、タスク構成ファイルで設定します。
    online-ddl-scheme: "gh-ost"
    • アップストリームの MySQL/MariaDB が pt ツールを使用している場合は、タスク構成ファイルで設定します。
    online-ddl-scheme: "pt"

    シャードマージ

    DM は、上流の MySQL/MariaDB シャード テーブルの DML および DDL データのマージと、マージされたデータの下流の TiDB テーブルへの移行をサポートします。

    制限

    現在、シャード マージ機能は限られたシナリオでのみサポートされています。詳細については、 シャーディング DDL の使用 ペシミスティック モードでの制限事項およびシャーディング DDL の使用法 オプティミスティック モードでの制限事項を参照してください。

    パラメータ構成

    タスク構成ファイルでshard-modeからpessimisticを設定します。

    shard-mode: "pessimistic" # The shard merge mode. Optional modes are ""/"pessimistic"/"optimistic". The "" mode is used by default which means sharding DDL merge is disabled. If the task is a shard merge task, set it to the "pessimistic" mode. After getting a deep understanding of the principles and restrictions of the "optimistic" mode, you can set it to the "optimistic" mode.

    シャーディング DDL ロックを手動で処理する

    一部の異常なシナリオでは、 シャーディング DDL ロックを手動で処理するする必要があります。

    Playground
    新規
    登録なしで TiDB の機能をワンストップでインタラクティブに体験できます。
    製品
    TiDB Cloud
    TiDB
    価格
    PoC お問い合わせ
    エコシステム
    TiKV
    TiFlash
    OSS Insight
    © 2024 PingCAP. All Rights Reserved.
    Privacy Policy.