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

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

TiDB データ移行 (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-regexpsource-regexp正規表現のみをサポートし、 ~記号で始まることはできません。

  • schema-patterntable-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 つのアップストリーム MySQL インスタンスのtest_{1,2,3...}テーブルt_{1,2,3...}ダウンストリーム TiDB インスタンスのtest tに移行します。

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

  • rule-1schema-pattern: "test_*"およびtable-pattern: "t_*"一致するテーブルの DML または DDL ステートメントをダウンストリームtesttに移行するために使用されます。
  • rule-2CREATE/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"

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

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

tストリームインスタンスをダウンストリームインスタンスtestに移行するには、前のセクションシャード化されたスキーマとテーブルをマージすると同様のルーティングルールを作成する必要があります。さらに、 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-columnsc_tablec_schemac_source )が含まれている必要があります。また、これらの列は最後の列であり、文字列型である必要があります

CREATE TABLE `test`.`t` ( a int 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 PRIMARY KEY, c_schema varchar(10) DEFAULT NULL, c_source varchar(10) DEFAULT NULL );
  • c-sourceは存在しません:
CREATE TABLE `test`.`t` ( a int PRIMARY KEY, c_table varchar(10) DEFAULT NULL, c_schema varchar(10) DEFAULT NULL, );
  • c_schemaは文字列型ではありません:
CREATE TABLE `test`.`t` ( a int PRIMARY KEY, c_table varchar(10) DEFAULT NULL, c_schema int DEFAULT NULL, c_source varchar(10) DEFAULT NULL, );

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

シャード スキーマのシナリオを想定して、2 つのアップストリーム MySQL インスタンスのtest_{1,2,3...}テーブルt_{1,2,3...}ダウンストリーム TiDB インスタンスのtest 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"

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