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 は、 テーブルセレクターによって提供される
schema-pattern
/table-pattern
ルールに一致するアップストリーム MySQL または MariaDB インスタンス テーブルをダウンtarget-table
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 に移行してマージする必要がある場合は、 このチュートリアルを参照してください。
シャード化されたスキーマとテーブルをマージする
シャード化されたスキーマとテーブルのシナリオを想定して、 test_{1,2,3...}
つのアップストリーム MySQL インスタンスt
t_{1,2,3...}
テーブルをダウンストリーム TiDB インスタンスの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"
テーブル、スキーマ、ソース情報を抽出し、マージされたテーブルに書き込みます。
シャードされたスキーマとテーブルのシナリオを想定して、 test_{1,2,3...}
つのアップストリーム MySQL インスタンスのt_{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,
);
シャード化されたスキーマをマージする
t_{1,2,3...}
されたスキーマのシナリオを想定して、2 つのアップストリーム MySQL インスタンスのt_{1,2,3...}
テーブルをダウンtest_{1,2,3...}
TiDB インスタンスの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"