TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

移行タスクの事前チェック

DM を使用してアップストリームからダウンストリームにデータを移行する前に、事前チェックを行うことでアップストリーム データベース構成のエラーを検出し、移行がスムーズに進むようにします。このドキュメントでは、DM 事前チェック機能について、その使用シナリオ、チェック項目、引数などを紹介します。

使用シナリオ

データ移行タスクをスムーズに実行するために、DM はタスクの開始時に自動的に事前チェックをトリガーし、チェック結果を返します。DM は、事前チェックに合格した後にのみ移行を開始します。

事前チェックを手動でトリガーするには、 check-taskコマンドを実行します。

例えば：

tiup dmctl check-task ./task.yaml

チェック項目の説明

タスクの事前チェックがトリガーされると、DM は移行モードの構成に従って対応する項目をチェックします。

このセクションでは、すべての事前チェック項目をリストします。

注記：

このドキュメントでは、必ず合格しなければならないチェック項目には「(必須)」というラベルが付いています。

  • 必須チェック項目に合格しなかった場合、DM はチェック後にエラーを返し、移行タスクを続行しません。この場合、エラー メッセージに従って構成を変更し、事前チェックの要件を満たした後にタスクを再試行してください。

  • 必須ではないチェック項目に合格しなかった場合、DM はチェック後に警告を返します。チェック結果に警告のみが含まれ、エラーが含まれていない場合、DM は自動的に移行タスクを開始します。

共通チェック項目

選択した移行モードに関係なく、事前チェックには常に次の共通チェック項目が含まれます。

  • データベースバージョン

    • MySQL バージョン > 5.5

    • MariaDB バージョン >= 10.1.2

  • アップストリームMySQLテーブルスキーマの互換性

    • アップストリーム テーブルに、TiDB でサポートされていない外部キーがあるかどうかを確認します。事前チェックで外部キーが見つかった場合は、警告が返されます。

    • アップストリーム テーブルが TiDB と互換性のない文字セットを使用していないかどうかを確認します。詳細については、 TiDB でサポートされる文字セット参照してください。

    • アップストリーム テーブルに主キー制約または一意キー制約 (v1.0.7 から導入) があるかどうかを確認します。

完全なデータ移行のためのチェック項目

完全データ移行モード（ task-mode: full ）の場合、 共通チェック項目に加えて、事前チェックには以下のチェック項目も含まれます。

  • (必須) アップストリームデータベースのダンプ権限

    • INFORMATION_SCHEMA およびダンプ テーブルに対する SELECT 権限
    • RELOAD権限がconsistency=flush場合
    • ダンプテーブルに対するLOCK TABLES権限consistency=flush/lock場合）

  • (必須) アップストリーム MySQL マルチインスタンス シャーディング テーブルの一貫性

    • 悲観的モードでは、すべてのシャード テーブルのテーブル スキーマが次の項目で一貫しているかどうかを確認します。

      • 列の数
      • カラム名
      • カラムの順序
      • カラムタイプ
      • 主キー
      • ユニークインデックス

    • 楽観的モードでは、すべてのシャード テーブルのスキーマが楽観的互換性満たしているかどうかを確認します。

    • 移行タスクがstart-taskコマンドによって正常に開始された場合、このタスクの事前チェックでは整合性チェックがスキップされます。

  • シャードテーブル内の主キーの自動増分

    • シャード テーブルに自動増分主キーがある場合、事前チェックは警告を返します。自動増分主キーに競合がある場合は、解決策については自動増分主キーの競合を処理するを参照してください。

物理的な輸入のためのアイテムを確認する

タスク構成でimport-mode: "physical"設定すると、 物理的な輸入正常に実行されることを確認するために、次のチェック項目が追加されます。プロンプトに従った後、これらのチェック項目の要件を満たすのが難しい場合は、 論理インポートモードを使用してデータをインポートしてみてください。

  • 下流データベースの空の領域

    • 空のリージョンの数がmax(1000, 3 * the number of tables) (「1000」と「テーブル数の 3 倍」のうち大きい方) より大きい場合、事前チェックは警告を返します。関連する PD パラメータを調整して、空のリージョンのマージを高速化し、空のリージョンの数が減少するのを待つことができます。3 PD スケジューリングのベスト プラクティス - 低速リージョンのマージ参照してください。

  • 下流データベースにおけるリージョン分布

    • 異なる TiKV ノード上のリージョンの数をチェックします。リージョン数が最も少ない TiKV ノードにはaリージョンがあり、リージョン数が最も多い TiKV ノードにはbリージョンがあると仮定すると、 a / bが 0.75 未満の場合、事前チェックは警告を返します。関連する PD パラメータを調整してリージョンのスケジュールを高速化し、リージョン数が変化するのを待つことができます。7 PD スケジューリングのベスト プラクティス -Leader/リージョンの配分がバランスが取れていない参照してください。

  • 下流データベースのTiDB、PD、およびTiKVのバージョン

    • 物理インポートでは、TiDB、PD、および TiKV のインターフェースを呼び出す必要があります。バージョンに互換性がない場合、事前チェックでエラーが返されます。

  • 下流データベースの空き容量

    • アップストリーム データベースの許可リストにあるすべてのテーブルの合計サイズを推定します ( source_size )。ダウンストリーム データベースの空き容量がsource_size未満の場合、事前チェックはエラーを返します。ダウンストリーム データベースの空き容量が TiKV レプリカの数 source_size 2 未満の場合、事前チェックは警告を返します。

  • 下流データベースが物理インポートと互換性のないタスクを実行しているかどうか

    • 現在、物理インポートはタスクティCDCおよびピトルと互換性がありません。これらのタスクがダウンストリーム データベースで実行されている場合、事前チェックはエラーを返します。

増分データ移行のチェック項目

増分データ移行モード（ task-mode: incremental ）の場合、 共通チェック項目に加えて、事前チェックには次のチェック項目も含まれます。

  • (必須) 上流データベースのレプリケーション権限

    • レプリケーションクライアント権限
    • REPLICATION SLAVE 権限

  • データベースのプライマリ/セカンダリ構成

    • プライマリ - セカンダリ レプリケーションの失敗を回避するには、アップストリーム データベースにデータベース ID server_idを指定することをお勧めします (AWS Aurora以外の環境では GTID が推奨されます)。

  • (必須) MySQL binlog設定

    • binlogが有効になっているかどうかを確認します (DM で必要)。
    • binlog_format=ROWが構成されているかどうかを確認します (DM は ROW 形式のbinlogの移行のみをサポートします)。
    • binlog_row_image=FULL設定されているかどうかを確認します (DM はbinlog_row_image=FULLのみをサポートします)。
    • binlog_do_dbまたはbinlog_ignore_dbが設定されている場合は、移行するデータベース テーブルがbinlog_do_dbおよびbinlog_ignore_dbの条件を満たしているかどうかを確認します。

  • (必須) アップストリーム データベースがオンラインDDLプロセス ( ghostテーブルは作成されているが、 renameフェーズはまだ実行されていない) にあるかどうかを確認します。アップストリームがオンライン DDL プロセスにある場合、事前チェックでエラーが返されます。この場合、DDL が完了するまで待ってから再試行してください。

完全データ移行と増分データ移行のチェック項目

完全および増分データ移行モード（ task-mode: all ）の場合、事前チェックには共通チェック項目に加えて完全なデータ移行チェック項目と増分データ移行チェック項目含まれます。

無視できるチェック項目

事前チェックにより、環境内の潜在的なリスクを見つけることができます。チェック項目を無視することはお勧めしません。データ移行タスクに特別なニーズがある場合は、 ignore-checking-items設定項目使用して一部のチェック項目をスキップできます。

チェック項目説明
dump_privilegeアップストリーム MySQL インスタンス内のユーザーのダンプ権限をチェックします。
replication_privilegeアップストリーム MySQL インスタンス内のユーザーのレプリケーション権限をチェックします。
versionアップストリーム データベースのバージョンを確認します。
server_idserver_id がアップストリーム データベースで設定されているかどうかを確認します。
binlog_enableアップストリーム データベースでbinlog が有効になっているかどうかを確認します。
table_schemaアップストリーム MySQL テーブル内のテーブル スキーマの互換性をチェックします。
schema_of_shard_tablesアップストリーム MySQL マルチインスタンス シャード内のテーブル スキーマの一貫性をチェックします。
auto_increment_IDアップストリームの MySQL マルチインスタンス シャードで自動インクリメント主キーが競合するかどうかを確認します。
online_ddlアップストリームがオンラインDDLの処理中かどうかを確認します。
empty_region物理インポートのダウンストリーム データベース内の空の領域の数を確認します。
region_distribution物理インポートのダウンストリーム データベース内のリージョンの分布を確認します。
downstream_versionダウンストリーム データベース内の TiDB、PD、および TiKV のバージョンを確認します。
free_spaceダウンストリーム データベースの空き領域を確認します。
downstream_mutex_featuresダウンストリーム データベースが物理インポートと互換性のないタスクを実行しているかどうかを確認します。

注記：

6.0 より前のバージョンでは、より多くの無視可能なチェック項目がサポートされています。6.0 以降、DM では、データの安全性に関連する一部のチェック項目を無視することはできません。たとえば、 binlog_row_imageパラメータを誤って構成すると、レプリケーション中にデータが失われる可能性があります。

事前チェック引数を設定する

移行タスクの事前チェックは並列処理をサポートしています。シャード化されたテーブルの行数が 100 万レベルに達した場合でも、事前チェックは数分で完了します。

事前チェックのスレッド数を指定するには、移行タスク構成ファイルのmydumpersフィールドのthreads引数を構成できます。

mydumpers:                           # Configuration arguments of the dump processing unit
  global:                            # Configuration name
    threads: 4                       # The number of threads that access the upstream when the dump processing unit performs the precheck and exports data from the upstream database (4 by default)
    chunk-filesize: 64               # The size of the files generated by the dump processing unit (64 MB by default)
    extra-args: "--consistency none" # Other arguments of the dump processing unit. You do not need to manually configure table-list in `extra-args`, because it is automatically generated by DM.

注記：

値threadsは、アップストリーム データベースと DM 間の物理接続の数を決定します。値がthreadsに大きすぎると、アップストリームの負荷が増加する可能性があります。したがって、適切な値にthreadsを設定する必要があります。

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