より多くの列を持つ下流の 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 NOT NULL,
  PRIMARY KEY (`id`)
)

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

# Downstream table schema
CREATE TABLE `messages` (
  `id` int 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 で設定する必要があります。手順は以下のとおりです。

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

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-addr`	dmctl が接続されるクラスター内の任意の DM マスターノードの`${advertise-addr}`指定します。3 `${advertise-addr}` 、DM マスターが外部にアドバタイズするアドレスを示します。
`binlog-schema set`	スキーマ情報を手動で設定します。
`-s`	ソースを指定します。1 `${source-id}` MySQL データのソース ID を示します。
`${task-name}`	データ移行タスクの`task.yaml`構成ファイルで定義されている移行タスクの名前を指定します。
`${database-name}`	データベースを指定します。1 `${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

一時停止状態の移行タスクを再開するには、 resume-taskコマンドを使用します。
```
tiup dmctl --master-addr ${advertise-addr} resume-task ${task-name}
```
query-statusコマンドを使用して、データ移行タスクが正しく実行されていることを確認します。
```
tiup dmctl --master-addr ${advertise-addr} query-status ${task-name}
```

より多くの列を持つ下流の TiDB テーブルにデータを移行する

DM を使用して、より多くの列を持つ下流の TiDB テーブルにデータを移行します。

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