重要

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

TiDB データ移行の主な機能

このドキュメントでは、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_bak 。 t_1_bakがrule-1とrule-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-nameとtbl-nameの両方を指定する必要があります
ignore-tables : 移行するテーブルのブロックリスト。MySQL のreplicate-ignore-tableに似ています。 db-nameとtbl-nameの両方を指定する必要があります

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

フィルタリングプロセス

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

ノート：
DM と MySQL では、許可リストとブロックリストのフィルタリングルールは次の点で異なります。
MySQL では、 replicate-wild-do-tableとreplicate-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 には適用されません。

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

スキーマレベルでフィルター処理します。
- do-dbsが空でない場合、一致するスキーマがdo-dbsに存在するかどうかを判断します。
  - はいの場合は、引き続きテーブルレベルでフィルタリングします。
  - そうでない場合は、フィルタtestを使用します。 t .
- do-dbsが空でignore-dbsが空でない場合、 ignore-dbsで一致するスキーマが存在するかどうかを判断します。
  - はいの場合、フィルターtest 。 t .
  - そうでない場合は、引き続きテーブルレベルでフィルタリングします。
- do-dbsとignore-dbsの両方が空の場合は、引き続きテーブルレベルでフィルタリングします。
テーブルレベルでフィルター処理します。
1. do-tablesが空でない場合、 do-tablesに一致するテーブルが存在するかどうかを判断します。
  - はいの場合は、移行testします。 t .
  - そうでない場合は、フィルタtestを使用します。 t .
2. ignore-tablesが空でない場合、 ignore-tablesに一致するテーブルが存在するかどうかを判断します。
  - はいの場合、フィルターtest 。 t .
  - そうでない場合は、移行testします。 t .
3. do-tablesとignore-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`	はい	スキーマ`forum`は`do-dbs`に一致し、引き続きテーブルレベルでフィルタリングします。 2. スキーマとテーブルは`do-tables`と`ignore-tables`のいずれとも一致せず、 `do-tables`は空ではありません。
`forum` . `messages`	いいえ	スキーマ`forum`は`do-dbs`に一致し、引き続きテーブルレベルでフィルタリングします。 2. 表`messages`は`do-tables`の`db-name: "~^forum.*",tbl-name: "messages"`の中にあります。
`forum_backup_2018` . `messages`	いいえ	スキーマ`forum_backup_2018`は`do-dbs`に一致し、引き続きテーブルレベルでフィルタリングします。 2. スキーマとテーブルは`db-name: "~^forum.*",tbl-name: "messages"` of `do-tables`と一致します。

Binlogイベントフィルター

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

ノート：
同じテーブルが複数のルールに一致する場合、これらのルールは順番に適用され、ブロックリストは許可リストよりも優先されます。これは、テーブルにIgnoreとDoの両方のルールが適用されている場合、 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 イベントは含まれません
`insert`	DML	`INSERT` DML イベント
`update`	DML	`UPDATE` DML イベント
`delete`	DML	`DELETE` DML イベント
`create database`	DDL	`CREATE DATABASE` DDL イベント
`drop database`	DDL	`DROP DATABASE` DDL イベント
`create table`	DDL	`CREATE TABLE` DDL イベント
`create index`	DDL	`CREATE INDEX` DDL イベント
`drop table`	DDL	`DROP TABLE` DDL イベント
`truncate table`	DDL	`TRUNCATE TABLE` DDL イベント
`rename table`	DDL	`RENAME TABLE` DDL イベント
`drop index`	DDL	`DROP INDEX` DDL イベント
`alter table`	DDL	`ALTER 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 table 、 insert 、 update 、および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: trueはonline-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 ロックを手動で処理するする必要があります。

TiDB データ移行の主な機能

テーブル ルーティング

パラメータ構成

パラメータの説明

使用例

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

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

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

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

パラメータ構成

パラメータの説明

フィルタリングプロセス

使用例

Binlogイベント フィルター

パラメータ構成

パラメータの説明

使用例

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

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

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

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

オンライン DDL ツール

制限

パラメータ構成

シャードマージ

制限

パラメータ構成

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

このページは役に立ちましたか？

テーブルルーティング

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

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

Binlogイベントフィルター