📣
TiDB Cloud Essential はパブリックプレビュー中です。このページは自動翻訳されたものです。原文はこちらからご覧ください。
TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

主な機能

このドキュメントでは、TiDBデータ移行（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...}を移行するとします。 testへの2つのアップストリームMySQLインスタンスのt_{1,2,3...}のテーブル。ダウンストリーム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レプリケーションルール-db /テーブルに似ています。これは、一部のデータベースまたは一部のテーブルのすべての操作をフィルタリングまたは移行するためにのみ使用できます。

パラメータ設定

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形式のbinlogのみをサポートしており、 STATEMENTまたはMIXED形式のbinlogはサポートしていません。したがって、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で終了するかどうかを判断します。

      • はいの場合、フィルターtest 。 t 。
      • そうでない場合は、引き続きテーブルレベルでフィルタリングします。

    • do-dbsとignore-dbsの両方が空の場合は、テーブルレベルでフィルタリングを続行します。

  2. テーブルレベルでのフィルタリング：

    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.スキーマとテーブルはdo-tablesと一致しdb-name: "~^forum.*",tbl-name: "messages" 。

    • Binlogイベントフィルター

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

    ノート：

    • 同じテーブルが複数のルールに一致する場合、これらのルールが順番に適用され、ブロックリストが許可リストよりも優先されます。これは、 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に一致するアップストリームMySQLまたはMariaDBインスタンステーブルのtable-patternイベントまたはDDL SQLステートメントは、以下のルールによってフィルタリングされます。

    • events ：binlogイベント配列。次の表から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 ：指定されたDDLSQLステートメントをフィルタリングするために使用されます。マッチングルールは、正規表現の使用をサポートしています。たとえば、 "^DROP\\s+PROCEDURE" 。

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

      • 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は、 insertに一致するすべてのテーブルのcreate table 、およびupdate test_*のみを移行し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操作がbinlogのposition-Aで開始し、 position-Bで終了する場合、増分レプリケーションの開始点はposition-Aより前またはposition-Bより後である必要があります。そうしないと、エラーが発生します。詳しくはFAQをご覧ください。

    パラメータ設定

      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ロックを手動で処理するにする必要があります。

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