より多くの列を含むダウンストリーム TiDB テーブルにデータを移行する

このドキュメントでは、対応するアップストリーム テーブルよりも多くの列を持つダウンストリーム TiDB テーブルにデータを移行するときに実行する追加手順について説明します。通常の移行手順については、次の移行シナリオを参照してください。

DM を使用して、より多くの列を含むダウンストリーム TiDB テーブルにデータを移行する

アップストリームのbinlogをレプリケートする場合、DM はダウンストリームの現在のテーブル スキーマを使用してbinlogを解析し、対応する DML ステートメントを生成しようとします。アップストリームbinlogのテーブルの列番号がダウンストリーム テーブル スキーマの列番号と一致しない場合、次のエラーが発生します。

"errors": [ { "ErrCode": 36027, "ErrClass": "sync-unit", "ErrScope": "internal", "ErrLevel": "high", "Message": "startLocation: [position: (mysql-bin.000001, 2022), gtid-set:09bec856-ba95-11ea-850a-58f2b4af5188:1-9 ], endLocation: [ position: (mysql-bin.000001, 2022), gtid-set: 09bec856-ba95-11ea-850a-58f2b4af5188:1-9]: gen insert sqls failed, schema: log, table: messages: Column count doesn't match value count: 3 (columns) vs 2 (values)", "RawCause": "", "Workaround": "" } ]

以下はアップストリーム テーブル スキーマの例です。

# Upstream table schema CREATE TABLE `messages` ( `id` int(11) NOT NULL, PRIMARY KEY (`id`) )

以下は、ダウンストリーム テーブル スキーマの例です。

# Downstream table schema CREATE TABLE `messages` ( `id` int(11) NOT NULL, `message` varchar(255) DEFAULT NULL, # This is the additional column that only exists in the downstream table. PRIMARY KEY (`id`) )

DM がダウンストリーム テーブル スキーマを使用して、アップストリームによって生成されたbinlogイベントを解析しようとすると、DM は上記Column count doesn't matchエラーを報告します。

このような場合、 binlog-schemaコマンドを使用して、データ ソースから移行するテーブルのテーブル スキーマを設定できます。指定されたテーブル スキーマは、DM によってレプリケートされるbinlogイベント データに対応する必要があります。シャードテーブルを移行する場合は、シャードテーブルごとに、binlogイベントデータを解析するために DM でテーブルスキーマを設定する必要があります。手順は次のとおりです。

  1. DM で SQL ファイルを作成し、上流のテーブル スキーマに対応するCREATE TABLEステートメントをファイルに追加します。たとえば、次のテーブル スキーマをlog.messages.sqlに保存します。 DM v6.0 以降のバージョンでは、SQL ファイルを作成せずに--from-sourceまたは--from-targetフラグを追加することでテーブル スキーマを更新できます。詳細は移行するテーブルのテーブルスキーマを管理するを参照してください。

    # Upstream table schema CREATE TABLE `messages` ( `id` int(11) NOT NULL, PRIMARY KEY (`id`) )
  2. binlog-schemaコマンドを使用して、データ ソースから移行するテーブルのテーブル スキーマを設定します。この時点では、上記Column count doesn't matchのエラーにより、データ移行タスクは一時停止状態になっているはずです。

    tiup dmctl --master-addr ${advertise-addr} binlog-schema update -s ${source-id} ${task-name} ${database-name} ${table-name} ${schema-file}

    このコマンドのパラメータの説明は次のとおりです。

    パラメータ説明
    -master-addrdmctl が接続されるクラスター内の任意の DM マスター ノードの${advertise-addr}を指定します。 ${advertise-addr} DM マスターが外部に宣伝するアドレスを示します。
    binlog-schema setスキーマ情報を手動で設定します。
    -sソースを指定します。 ${source-id} MySQL データのソース ID を示します。
    ${task-name}データ移行タスクの構成ファイルtask.yamlで定義された移行タスクの名前を指定します。
    ${database-name}データベースを指定します。 ${database-name}上流データベースの名前を示します。
    ${table-name}上流テーブルの名前を指定します。
    ${schema-file}設定するテーブルスキーマファイルを指定します。

    例えば:

    tiup dmctl --master-addr 172.16.10.71:8261 binlog-schema update -s mysql-01 task-test -d log -t message log.message.sql
  3. resume-taskコマンドを使用して、一時停止状態の移行タスクを再開します。

    tiup dmctl --master-addr ${advertise-addr} resume-task ${task-name}
  4. query-statusコマンドを使用して、データ移行タスクが正しく実行されていることを確認します。

    tiup dmctl --master-addr ${advertise-addr} query-status resume-task ${task-name}

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

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