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

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

使用シナリオ

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

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

例えば：

tiup dmctl check-task ./task.yaml

チェック項目の説明

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

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

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

必須チェック項目に合格しなかった場合、DMはチェック後にエラーを返し、移行タスクを続行しません。この場合、エラーメッセージに従って設定を変更し、事前チェックの要件を満たしてからタスクを再試行してください。
必須ではないチェック項目が不合格になった場合、DM はチェック後に警告を返します。チェック結果に警告のみが含まれ、エラーが含まれていない場合、DM は自動的に移行タスクを開始します。

共通チェック項目

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

データベースバージョン
- MySQL バージョン > 5.5
- MariaDB バージョン >= 10.1.2
警告
- DMを使用したMySQL 8.0からTiDBへのデータ移行は実験的機能です（DM v2.0以降に導入）。本番環境での使用は推奨されません。
- DMを使用したMariaDBからTiDBへのデータ移行は実験的機能です。本番環境での使用は推奨されません。
アップストリームMySQLテーブルスキーマの互換性
- 上流テーブルに外部キーがあるかどうかを確認します。これはTiDBではサポートされていません。事前チェックで外部キーが見つかった場合は警告が返されます。
- 上流テーブルがTiDBと互換性のない文字セットを使用していないか確認してください。詳細については、 TiDB でサポートされている文字セット参照してください。
- アップストリームテーブルに主キー制約または一意キー制約 (v1.0.7 から導入) があるかどうかを確認します。
警告
- アップストリームで互換性のない文字セットが使用されている場合でも、ダウンストリームでutf8mb4文字セットを使用してテーブルを作成することでレプリケーションを続行できます。ただし、この方法は推奨されません。アップストリームで使用されている互換性のない文字セットを、ダウンストリームでサポートされている別の文字セットに置き換えることをお勧めします。
- 上流テーブルに主キー制約または一意キー制約がない場合、同じデータ行が下流テーブルに複数回レプリケートされる可能性があり、これもレプリケーションのパフォーマンスに影響を与える可能性があります。本番環境では、上流テーブルに主キー制約または一意キー制約を指定することをお勧めします。

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

完全データ移行モード（ 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未満の場合、事前チェックは警告を返します。
下流データベースが物理インポートと互換性のないタスクを実行しているかどうか
- 現在、物理インポートはタスクTiCDCおよびPITRとは互換性がありません。これらのタスクが下流データベースで実行されている場合、事前チェックはエラーを返します。

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

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

(必須) 上流データベースのレプリケーション権限
- レプリケーションクライアント権限
- レプリケーションスレーブ権限
データベースのプライマリ/セカンダリ構成
- プライマリ-セカンダリレプリケーションの失敗を回避するには、アップストリームデータベースにデータベース 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_id`	server_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`	ダウンストリームデータベースが物理インポートと互換性のないタスクを実行しているかどうかを確認します。

注記：
v6.0より前のバージョンでは、より多くの無視可能なチェック項目がサポートされていました。v6.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 auto" # 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 間の物理接続数を決定します。3 threads値が大きすぎると、上流データベースの負荷が増加する可能性があります。そのため、 threads適切な値に設定する必要があります。