📣
TiDB Cloud Serverless が
Starter
に変わりました！このページは自動翻訳されたものです。
原文はこちらからご覧ください。
TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

移行するテーブルのテーブルスキーマを管理する

このドキュメントでは、 dmctlを使用して移行中にDMでテーブルのスキーマを管理する方法について説明します。

実装の原則

DMを使用してテーブルを移行する場合、DMはテーブルスキーマに対して次の操作を実行します。

  • 完全なエクスポートとインポートの場合、DMは現在の時刻のアップストリームテーブルスキーマをSQLファイルに直接エクスポートし、テーブルスキーマをダウンストリームに適用します。

  • インクリメンタルレプリケーションの場合、データリンク全体に次のテーブルスキーマが含まれます。これらは同じでも異なる場合もあります。

    schema

    • schema-Uとして識別される、現時点でのアップストリームテーブルスキーマ。
    • DMによって現在消費されているbinlogイベントのテーブルスキーマschema-Bとして識別されます。このスキーマは、履歴時のアップストリームテーブルスキーマに対応します。
    • schema-Iとして識別されるDM（スキーマトラッカーコンポーネント）で現在維持されているテーブルスキーマ。
    • schema-Dとして識別されるダウンストリームTiDBクラスタのテーブルスキーマ。

    ほとんどの場合、上記の4つのテーブルスキーマは同じです。

アップストリームデータベースがDDL操作を実行してテーブルスキーマを変更すると、 schema-Uが変更されます。内部スキーマトラッカーコンポーネントとダウンストリームTiDBクラスタにDDL操作を適用することにより、DMはschema-Iとschema-Dを順番に更新し、 schema-Uとの整合性を維持します。したがって、DMは通常、 schema-Bテーブルスキーマに対応するbinlogイベントを消費できます。つまり、DDL操作が正常に移行された後でも、 schema-B 、およびschema-Uはschema-I性がありschema-D 。

ただし、 オプティミスティックモードシャーディングDDLサポートを有効にして移行中に、ダウンストリームテーブルのschema-Dが、一部のアップストリームシャードテーブルのschema-Bおよびschema-Iと一致しない場合があります。このような場合でも、DMはschema-Iとschema-Bの一貫性を維持して、DMLに対応するbinlogイベントを正常に解析できるようにします。

さらに、一部のシナリオ（ダウンストリームテーブルにアップストリームテーブルよりも多くの列がある場合など）では、 schema-Dがschema-Bおよびschema-Iと矛盾する場合があります。

上記のシナリオをサポートし、スキーマの不整合によって引き起こされる他の移行の中断を処理するために、DMは、DMに保持されているschema-Iのテーブルスキーマを取得、変更、および削除するoperate-schemaのコマンドを提供します。

指示

help operate-schema

`get`/`set`/`remove` the schema for an upstream table.

Usage:
  dmctl operate-schema <operate-type> <-s source ...> <task-name | task-file> <-d database> <-t table> [schema-file] [--flush] [--sync] [flags]

Flags:
  -d, --database string   database name of the table
      --flush             flush the table info and checkpoint immediately
  -h, --help              help for operate-schema
      --sync              sync the table info to master to resolve shard ddl lock, only for optimistic mode now
  -t, --table string      table name

Global Flags:
  -s, --source strings   MySQL Source ID.

ノート：

  • テーブルスキーマはデータ移行中に変更される可能性があるため、予測可能なテーブルスキーマを取得するために、現在operate-schemaコマンドは、データ移行タスクがPaused状態の場合にのみ使用できます。
  • 誤った取り扱いによるデータの損失を回避するために、スキーマを変更する前に、まずテーブルスキーマを取得してバックアップすることを強くお勧めします。

パラメーター

  • operate-type ：
    • 必須。
    • スキーマに対する操作のタイプを指定します。オプションの値は、 get 、およびset remove 。
  • -s ：
    • 必須。
    • 操作が適用されるMySQLソースを指定します。
  • task-name | task-file ：
    • 必須。
    • タスク名またはタスクファイルのパスを指定します。
  • -d ：
    • 必須。
    • テーブルが属するアップストリームデータベースの名前を指定します。
  • -t ：
    • 必須。
    • テーブルに対応するアップストリームテーブルの名前を指定します。
  • schema-file ：
    • 操作タイプがsetの場合に必要です。他の操作タイプの場合はオプション。
    • 設定するテーブルスキーマファイル。ファイルの内容は有効なCREATE TABLEステートメントである必要があります。
  • --flush ：
    • オプション。
    • DMがタスクの再開後にスキーマをロードできるように、スキーマをチェックポイントに書き込みます。
    • デフォルト値はtrueです。
  • --sync ：
    • オプション。オプティミスティックシャーディングDDLモードでエラーが発生した場合にのみ使用されます。
    • このスキーマで楽観的なシャーディングメタデータを更新します。

使用例

テーブルスキーマを取得する

db_singleタスクのmysql-replica-01ソースに対応する`db_single`.`t1`テーブルのテーブルスキーマを取得する場合は、次のコマンドを実行します。

operate-schema get -s mysql-replica-01 task_single -d db_single -t t1

{
    "result": true,
    "msg": "",
    "sources": [
        {
            "result": true,
            "msg": "CREATE TABLE `t1` ( `c1` int(11) NOT NULL, `c2` int(11) DEFAULT NULL, PRIMARY KEY (`c1`)) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_bin",
            "source": "mysql-replica-01",
            "worker": "127.0.0.1:8262"
        }
    ]
}

テーブルスキーマを設定する

次のように、 db_singleのタスクでmysql-replica-01のMySQLソースに対応する`db_single`.`t1`のテーブルのテーブルスキーマを設定する場合：

CREATE TABLE `t1` (
    `c1` int(11) NOT NULL,
    `c2` bigint(11) DEFAULT NULL,
    PRIMARY KEY (`c1`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_bin

上記のCREATE TABLEのステートメントをファイル（たとえば、 db_single.t1-schema.sql ）として保存し、次のコマンドを実行します。

operate-schema set -s mysql-replica-01 task_single -d db_single -t t1 db_single.t1-schema.sql

{
    "result": true,
    "msg": "",
    "sources": [
        {
            "result": true,
            "msg": "",
            "source": "mysql-replica-01",
            "worker": "127.0.0.1:8262"
        }
    ]
}

テーブルスキーマを削除する

ノート：

DMに保持されているテーブルスキーマが削除された後、このテーブルに関連するDDL / DMLステートメントをダウンストリームに移行する必要がある場合、DMは次の3つのソースからテーブルスキーマを順番に取得しようとします。

  • チェックポイントテーブルのtable_infoフィールド
  • 楽観的なシャーディングDDLのメタ情報
  • ダウンストリームTiDBの対応するテーブル

db_singleタスクのmysql-replica-01ソースに対応する`db_single`.`t1`テーブルのテーブルスキーマを削除する場合は、次のコマンドを実行します。

operate-schema remove -s mysql-replica-01 task_single -d db_single -t t1

{
    "result": true,
    "msg": "",
    "sources": [
        {
            "result": true,
            "msg": "",
            "source": "mysql-replica-01",
            "worker": "127.0.0.1:8262"
        }
    ]
}

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