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

TiDB Data Migration (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" # 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-regexpschema-regexp 、およびsource-regexp正規表現のみをサポートしており、 ~記号で始めることはできません。

  • schema-patterntable-pattern 、ワイルドカードと正規表現の両方をサポートします。正規表現は~記号で始まる必要があります。

パラメータの説明

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

使用例

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

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

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

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

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

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

注記:

  • 下流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にします。 tダウンストリーム TiDB インスタンスのテーブル。同時に、シャードテーブルのソース情報を抽出し、それを下流のマージテーブルに書き込む必要があります。

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

  • extract-table : schema-patterntable-patternに一致するシャードテーブルの場合、DM はtable-regexpを使用してシャードテーブル名を抽出し、 t_部分を除いた名前サフィックスをマージされたテーブルのtarget-column 、つまりc_table列に書き込みます。
  • extract-schema : schema-patterntable-patternに一致するシャード スキーマの場合、DM はschema-regexpを使用してシャード スキーマ名を抽出し、 test_部分を除いた名前サフィックスをマージされたテーブルのtarget-column 、つまりc_schema列に書き込みます。
  • extract-source : schema-patterntable-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_tablec_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, );

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

シャード化スキーマのシナリオでは、 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-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"

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

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