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"
単純なシナリオでは、スキーマとテーブルの一致にワイルドカードを使用することをお勧めします。ただし、次のバージョンの違いに注意してください。
DM v1.0.5 以降のバージョンの場合、テーブル ルーティングはワイルドカードマッチサポートしますが、ワイルドカード式で指定できるのは
*だけであり、最後に*を配置する必要があります。v1.0.5 より前のバージョンの DM では、テーブル ルーティングはワイルドカードをサポートしますが、
[...]と[!...]式はサポートしません。
パラメータの説明
- DM は、 テーブル セレクターによって提供される
schema-pattern/table-patternルールに一致する上流の MySQL または MariaDB インスタンス テーブルを下流のtarget-schema/target-tableに移行します。 schema-patternルールに一致するシャード テーブルの場合、DMtable-patternextract-tableを使用してテーブル名を抽出します。table-regexp正規表現、extract-schemaを使用したスキーマ名。schema-regexp正規表現、およびextract-sourceを使用したソース情報。source-regexp正規表現。次に、DM は、抽出された情報を下流のマージされたテーブルの対応するtarget-columnに書き込みます。
使用例
このセクションでは、4 つの異なるシナリオでの使用例を示します。
小さなデータセットの MySQL シャードを TiDB に移行してマージする必要がある場合は、 このチュートリアルを参照してください。
シャードされたスキーマとテーブルをマージする
シャードされたスキーマとテーブルのシナリオで、 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テーブル。同時に、シャードされたテーブルのソース情報を抽出し、それをダウンストリームのマージされたテーブルに書き込みたいと考えています。
アップストリーム インスタンスをダウンストリームに移行するにはtest . tでは、前のセクションシャードされたスキーマとテーブルをマージすると同様のルーティング ルールを作成する必要があります。さらに、 extract-table 、 extract-schema 、およびextract-source構成を追加する必要があります。
extract-table:schema-patternとtable-patternに一致するシャード テーブルの場合、DM はtable-regexp使用してシャード テーブル名を抽出し、マージされたテーブルのtarget-column、つまりc_table列にt_の部分を除いた名前サフィックスを書き込みます。extract-schema:schema-patternとtable-patternに一致するシャード スキーマの場合、DM はschema-regexp使用してシャード スキーマ名を抽出し、マージされたテーブルのtarget-column、つまりc_schema列にtest_の部分を除いた名前サフィックスを書き込みます。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,
);
シャードされたスキーマをマージする
シャード スキーマのシナリオで、 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"