TiDB データ移行テーブルルーティング

TiDB データ移行 (DM) を使用してデータを移行する場合、テーブルルーティングを構成して、アップストリーム MySQL または MariaDB インスタンスの特定のテーブルをダウンストリームの指定されたテーブルに移行できます。

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

テーブルルーティングを構成する

routes:
  rule-1:
    schema-pattern: "test_*"
    table-pattern: "t_*"
    target-schema: "test"
    target-table: "t"
    # extract-table, extract-schema, and extract-source are optional and
    # are required only when you need to extract information about sharded
    # tables, sharded schemas, and source datatabase information.
    extract-table:
      table-regexp: "t_(.*)"
      target-column: "c_table"
    extract-schema:
      schema-regexp: "test_(.*)"
      target-column: "c_schema"
    extract-source:
      source-regexp: "(.*)"
      target-column: "c_source"
  rule-2:
    schema-pattern: "test_*"
    target-schema: "test"

データベース名とテーブル名の一致には、正規表現とワイルドカードがサポートされています。単純なシナリオでは、スキーマとテーブルの一致にワイルドカードを使用することをお勧めします。ただし、次の点に注意してください。

* 、 ? 、 []などのワイルドカードがサポートされています。ワイルドカードの一致には*記号が 1 つだけ存在でき、末尾に配置する必要があります。たとえば、 table-pattern: "t_*"では、 "t_*" t_で始まるすべてのテーブルを示します。詳細についてはワイルドカードマッチングを参照してください。
table-regexp 、 schema-regexp 、 source-regexp正規表現のみをサポートし、 ~記号で始まることはできません。
schema-patternとtable-patternワイルドカードと正規表現の両方をサポートします。正規表現は~記号で始まる必要があります。

パラメータの説明

DM はtarget-table テーブルセレクターによって提供されるschema-pattern / table-patternルールに一致するアップストリーム MySQL または MariaDB インスタンステーブルをダウンストリームtarget-schemaに移行します。
schema-pattern / table-patternルールに一致するシャードテーブルの場合、DM はextract-table . table-regexp正規表現を使用してテーブル名を抽出し、 extract-schema . schema-regexp正規表現を使用してスキーマ名を抽出し、 extract-source . source-regexp正規表現を使用してソース情報を抽出します。次に、DM は抽出した情報を下流のマージされたテーブルの対応するtarget-columnに書き込みます。

使用例

このセクションでは、4 つの異なるシナリオでの使用例を示します。

小さなデータセットの MySQL シャードを TiDB に移行してマージする必要がある場合は、このチュートリアルを参照してください。

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

シャード化されたスキーマとテーブルのシナリオを想定して、2 つt test_{1,2,3...} t_{1,2,3...} testします。

アップストリームインスタンスをダウンストリーム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"

テーブル、スキーマ、ソース情報を抽出し、マージされたテーブルに書き込みます。

シャードされたスキーマとテーブルのシナリオを想定して、 t_{1,2,3...} test_{1,2,3...}をダウンストリーム TiDB インスタンスのtestテーブルに移行します。同時に、シャードされたテーブルのソース情報を抽出し、それをダウンtのマージされたテーブルに書き込みます。

アップストリームインスタンスをダウンストリームtestに移行するには、前のセクションシャード化されたスキーマとテーブルをマージすると同様のルーティングルールを作成する必要があります。 t 、 extract-table 、 extract-schema 、およびextract-source構成を追加する必要があります。

extract-table : schema-patternとtable-patternに一致するシャードテーブルの場合、DM はtable-regexpを使用してシャードテーブル名を抽出し、 t_部分を除いた名前サフィックスをマージされたテーブルのtarget-column 、つまりc_table列に書き込みます。
extract-schema : schema-patternとtable-patternに一致するシャードスキーマの場合、DM はschema-regexpを使用してシャードスキーマ名を抽出し、 test_部分を除いた名前サフィックスをマージされたテーブルのtarget-column 、つまりc_schema列に書き込みます。
extract-source : schema-patternとtable-patternに一致するシャードテーブルの場合、DM はソースインスタンス情報をマージされたテーブルのtarget-column 、つまりc_source列に書き込みます。

  rule-1:
    schema-pattern: "test_*"
    table-pattern: "t_*"
    target-schema: "test"
    target-table: "t"
    extract-table:
      table-regexp: "t_(.*)"
      target-column: "c_table"
    extract-schema:
      schema-regexp: "test_(.*)"
      target-column: "c_schema"
    extract-source:
      source-regexp: "(.*)"
      target-column: "c_source"
  rule-2:
    schema-pattern: "test_*"
    target-schema: "test"

アップストリームのシャードテーブルのソース情報をダウンストリームのマージテーブルに抽出するには、移行を開始する前に、ダウンストリームにマージテーブルを手動で作成する必要があります。マージテーブルには、ソース情報を指定するために使用される 3 つのtarget-columns ( c_table 、 c_schema 、およびc_source ) が含まれている必要があります。また、これらの列は最後の列であり、文字列型である必要があります。

CREATE TABLE `test`.`t` (
    a int(11) PRIMARY KEY,
    c_table varchar(10) DEFAULT NULL,
    c_schema varchar(10) DEFAULT NULL,
    c_source varchar(10) DEFAULT NULL
);

アップストリームに次の 2 つのデータソースがあると仮定します。

データソースmysql-01 :

mysql> select * from test_11.t_1;
+---+
| a |
+---+
| 1 |
+---+
mysql> select * from test_11.t_2;
+---+
| a |
+---+
| 2 |
+---+
mysql> select * from test_12.t_1;
+---+
| a |
+---+
| 3 |
+---+

データソースmysql-02 :

mysql> select * from test_13.t_3;
+---+
| a |
+---+
| 4 |
+---+

DM を使用して移行すると、マージされたテーブル内のデータは次のようになります。

mysql> select * from test.t;
+---+---------+----------+----------+
| a | c_table | c_schema | c_source |
+---+---------+----------+----------+
| 1 | 1       | 11       | mysql-01 |
| 2 | 2       | 11       | mysql-01 |
| 3 | 1       | 12       | mysql-01 |
| 4 | 3       | 13       | mysql-02 |
+---+---------+----------+----------+

結合テーブルを作成する際の誤った例

注記：
次のいずれかのエラーが発生した場合、シャードされたテーブルとスキーマのソース情報がマージされたテーブルに書き込まれない可能性があります。

最後の 3 列にc-tableがありません。

CREATE TABLE `test`.`t` (
    c_table varchar(10) DEFAULT NULL,
    a int(11) PRIMARY KEY,
    c_schema varchar(10) DEFAULT NULL,
    c_source varchar(10) DEFAULT NULL
);

c-sourceは存在しません:

CREATE TABLE `test`.`t` (
    a int(11) PRIMARY KEY,
    c_table varchar(10) DEFAULT NULL,
    c_schema varchar(10) DEFAULT NULL,
);

c_schema文字列型ではありません:

CREATE TABLE `test`.`t` (
    a int(11) PRIMARY KEY,
    c_table varchar(10) DEFAULT NULL,
    c_schema int(11) DEFAULT NULL,
    c_source varchar(10) DEFAULT NULL,
);

シャードスキーマをマージする

シャードされたスキーマのシナリオを想定して、2 つt_{1,2,3...} test_{1,2,3...} t_{1,2,3...} testします。

アップストリームスキーマをダウンストリーム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"