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

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 パラメータを調整して、空のリージョンの結合を高速化し、空のリージョンの数が減少するのを待つことができます。 PD スケジュールのベスト プラクティス - 低速なリージョンマージを参照してください。
  • ダウンストリームデータベースのリージョン分布

    • さまざまな TiKV ノード上のリージョンの数を確認します。リージョン数が最も低い TiKV ノードにリージョンがaつあり、リージョン数が最も高い TiKV ノードにbのリージョンがあると仮定すると、 a / bが 0.75 未満の場合、事前チェックは警告を返します。関連する PD パラメータを調整して、リージョンのスケジュールを高速化し、リージョンの数が変更されるのを待つことができます。 PD スケジュールのベスト プラクティス -Leader/リージョンの分散のバランスが取れていませんを参照してください。
  • ダウンストリーム データベース内の TiDB、PD、および TiKV のバージョン

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

    • アップストリーム データベースの許可リスト内のすべてのテーブルの合計サイズを推定します ( source_size )。ダウンストリーム データベースの空き領域がsource_size未満の場合、事前チェックはエラーを返します。ダウンストリーム データベースの空き領域が TiKV レプリカの数 source_size 2 未満の場合、事前チェックにより警告が返されます。
  • ダウンストリーム データベースが物理インポートと互換性のないタスクを実行しているかどうか

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

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

増分データ移行モード ( task-mode: incremental ) の場合、事前チェックにはよくあるチェック項目に加えて、次のチェック項目も含まれます。

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

    • レプリケーションクライアント権限
    • レプリケーションスレーブ権限
  • データベースのプライマリ-セカンダリ構成

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

    • 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ダウンストリーム データベースが物理インポートと互換性のないタスクを実行していないかどうかを確認します。

注記:

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 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適切な値に設定する必要があります。

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

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