📣
TiDB Cloud Essential はパブリックプレビュー中です。このページは自動翻訳されたものです。原文はこちらからご覧ください。
TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

TiDBデータ移行におけるエラーの処理

このドキュメントでは、エラー システムと、DM を使用するときに発生する一般的なエラーの処理方法について説明します。

エラーシステム

エラー システムでは、通常、特定のエラーの情報は次のようになります。

  • code : エラーコード。

    DMでは、同じエラータイプに対して同じエラーコードが使用されます。DMのバージョンが変更されても、エラーコードは変更されません。

    DM 反復処理中に一部のエラーが削除される可能性がありますが、エラー コードは削除されません。DM は、新しいエラーに対して既存のエラー コードではなく新しいエラー コードを使用します。

  • class : エラータイプ。

    エラーが発生したコンポーネント(エラー ソース) をマークするために使用されます。

    次の表には、すべてのエラー タイプ、エラー ソース、およびエラー サンプルが表示されます。

    エラーの種類エラーソースエラーサンプル
    databaseデータベース操作[code=10003:class=database:scope=downstream:level=medium] database driver: invalid connection
    functionalDMの基礎関数[code=11005:class=functional:scope=internal:level=high] not allowed operation: alter multiple tables in one statement
    config設定が正しくありません[code=20005:class=config:scope=internal:level=medium] empty source-id not valid
    binlog-opBinlog操作[code=22001:class=binlog-op:scope=internal:level=high] empty UUIDs not valid
    checkpointチェックポイント操作[code=24002:class=checkpoint:scope=internal:level=high] save point bin.1234 is older than current pos bin.1371
    task-checkタスクチェックを実行しています[code=26003:class=task-check:scope=internal:level=medium] new table router error
    relay-event-libリレーモジュールの基本関数を実行する[code=28001:class=relay-event-lib:scope=internal:level=high] parse server-uuid.index
    relay-unitリレー処理装置[code=30015:class=relay-unit:scope=upstream:level=high] TCPReader get event: ERROR 1236 (HY000): Could not open log file
    dump-unitダンプ処理装置[code=32001:class=dump-unit:scope=internal:level=high] mydumper runs with error: CRITICAL **: 15:12:17.559: Error connecting to database: Access denied for user 'root'@'172.17.0.1' (using password: NO)
    load-unit負荷処理装置[code=34002:class=load-unit:scope=internal:level=high] corresponding ending of sql: ')' not found
    sync-unit同期処理ユニット[code=36027:class=sync-unit:scope=internal:level=high] Column count doesn't match value count: 9 (columns) vs 10 (values)
    dm-masterDMマスターサービス[code=38008:class=dm-master:scope=internal:level=high] grpc request error: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial tcp 172.17.0.2:8262: connect: connection refused"
    dm-workerDMワーカーサービス[code=40066:class=dm-worker:scope=internal:level=high] ExecuteDDL timeout, try use query-status to query whether the DDL is still blocking
    dm-tracerDMトレーサーサービス[code=42004:class=dm-tracer:scope=internal:level=medium] trace event test.1 not found
    schema-trackerスキーマトラッカー（増分データレプリケーション中）[code=44006:class=schema-tracker:scope=internal:level=high],"cannot track DDL: ALTER TABLE test DROP COLUMN col1"
    scheduler操作のスケジュール設定（データ移行タスク）[code=46001:class=scheduler:scope=internal:level=high],"the scheduler has not started"
    dmctldmctl 内または他のコンポーネントとのやり取り中にエラーが発生する[code=48001:class=dmctl:scope=internal:level=high],"can not create grpc connection"

  • scope : エラー範囲。

    エラーが発生したときに、 DM オブジェクトのスコープとソースをマークするために使用されます。 scopeは、 not-set 、 upstream 、 downstream 、 internal 4 つのタイプが含まれます。

    エラーのロジックが上流データベースと下流データベース間のリクエストに直接関係する場合、スコープはupstreamまたはdownstreamに設定されます。それ以外の場合、現在はinternalに設定されています。

  • level : エラーレベル。

    エラーの重大度レベル ( low 、 medium 、 high 。

    • レベルlowエラーは通常、ユーザー操作や誤った入力に関連します。移行タスクには影響しません。
    • レベルmediumエラーは通常、ユーザー設定に関連しています。これは新しく開始された一部のサービスに影響しますが、既存のDM移行ステータスには影響しません。
    • 移行タスクが中断される可能性を回避するために、レベルhighエラーを解決する必要があるため、通常は注意が必要です。

  • message : エラーの説明。

    エラーの詳細な説明。エラー呼び出しチェーン上のエラーメッセージの各追加レイヤーをラップして保存するために、モードエラー。ラップ採用されています。レイヤーにラップされたメッセージ記述はDM内のエラーを示し、最レイヤーにラップされたメッセージ記述はエラーの原因を示します。

  • workaround : エラー処理方法（オプション）

    このエラーの処理方法。確認済みのエラー（設定エラーなど）については、DMはworkaroundで対応する手動処理方法を示しています。

  • エラースタック情報（オプション）

    DMがエラースタック情報を出力するかどうかは、エラーの重大度と必要性によって異なります。エラースタックには、エラー発生時のスタック呼び出し情報がすべて記録されます。基本情報とエラーメッセージだけではエラーの原因を特定できない場合は、エラースタックを使用することで、エラー発生時のコード実行パスを追跡できます。

エラー コードの完全なリストについては、 エラーコードリストを参照してください。

トラブルシューティング

DM の実行中にエラーが発生した場合は、次の手順に従ってこのエラーをトラブルシューティングしてください。

  1. query-statusコマンドを実行して、タスクの実行ステータスとエラー出力を確認します。

  2. エラーに関連するログファイルを確認してください。ログファイルはDMマスターノードとDMワーカーノードにあります。エラーに関する重要な情報を取得するには、 エラーシステムを参照してください。その後、 よくあるエラーの処理セクションを参照して解決策を見つけてください。

  3. このドキュメントにエラーが記載されておらず、ログを確認したりメトリックを監視したりしても問題を解決できない場合は、PingCAP またはコミュニティにサポートを受ける 。

  4. エラーが解決したら、dmctl を使用してタスクを再起動します。

    resume-task ${task name}

ただし、場合によってはデータ移行タスクをリセットする必要があります。詳細はデータ移行タスクをリセットするを参照してください。

よくあるエラーの処理

エラーコードエラーの説明取り扱い方法
code=10001異常なデータベース操作です。エラー メッセージとエラー スタックをさらに分析します。
code=10002基盤データベースからのエラーbad connectionです。これは通常、DMと下流のTiDBインスタンス間の接続に異常があり（ネットワーク障害またはTiDBの再起動が原因と考えられます）、現在要求されているデータがTiDBに送信されていないことを示します。DMはこのようなエラーに対して自動リカバリを提供します。長時間リカバリが成功しない場合は、ネットワークまたはTiDBのステータスを確認してください。
code=10003基盤データベースからのエラーinvalid connectionです。これは通常、DMと下流のTiDBインスタンス間の接続に異常があり（ネットワーク障害またはTiDBの再起動が原因と考えられます）、現在要求されているデータの一部がTiDBに送信されていることを示します。DMはこのようなエラーに対して自動回復機能を提供します。長時間回復できない場合は、エラーメッセージをさらに確認し、実際の状況に基づいて情報を分析してください。
code=10005QUERY種類の SQL ステートメントを実行するときに発生します。
code=10006EXECUTEタイプのSQL文（ INSERT UPDATEまたはDELETEタイプのDDL文およびDML文を含む）の実行時に発生します。詳細なエラー情報については、通常、データベース操作で返されるエラーコードとエラー情報を含むエラーメッセージを確認してください。
code=11006DM の組み込みパーサーが互換性のない DDL ステートメントを解析するときに発生します。解決策についてはデータ移行 - 互換性のない DDL ステートメントを参照してください。
code=20010タスク構成で指定されたデータベース パスワードを復号化するときに発生します。構成タスクで指定されたダウンストリーム データベース パスワードがdmctlを使用して正しく暗号化されましたあるかどうかを確認します。
code=26002タスクチェックでデータベース接続を確立できませんでした。詳細なエラー情報については、エラーメッセージを確認してください。エラーメッセージには通常、データベース操作で返されたエラーコードとエラー情報が含まれています。DM マスターが配置されているマシンにアップストリームにアクセスする権限があるかどうかを確認します。
code=32001異常ダンプ処理装置エラーメッセージにmydumper: argument list too long.が含まれている場合は、ブロック/許可リストに従って、 task.yamlファイルの Mydumper 引数extra-argsに--regex正規表現を手動で追加して、エクスポートするテーブルを設定します。例えば、 helloという名前のテーブルをすべてエクスポートするには--regex '.*\\.hello$'を追加し、すべてのテーブルをエクスポートするには--regex '.*'を追加します。
code=38008DM コンポーネント間の gRPC 通信でエラーが発生します。チェックclass ：どのコンポーネントの相互作用でエラーが発生しているかを確認します。通信エラーの種類を特定します。gRPC接続の確立時にエラーが発生する場合は、通信サーバーが正常に動作しているかどうかを確認します。

invalid connectionエラーが返され、移行タスクが中断された場合、どうすればよいですか?

理由

エラーinvalid connectionは、DM と下流の TiDB データベース間の接続に異常 (ネットワーク障害、TiDB の再起動、TiKV のビジー状態など) が発生し、現在の要求のデータの一部が TiDB に送信されたことを示します。

ソリューション

DMは移行タスクにおいてデータを下流へ並行して移行する機能を備えているため、タスクが中断されると様々なエラーが発生する可能性があります。これらのエラーはquery-status使用して確認できます。

  • 増分レプリケーション プロセス中にinvalid connectionエラーのみが発生した場合、DM はタスクを自動的に再試行します。
  • バージョンの問題により DM が自動的に再試行されない場合、または再試行に失敗した場合は、 stop-task使用してタスクを停止し、 start-task使用してタスクを再起動します。

移行タスクがdriver: bad connectionエラーが返されました

理由

エラーdriver: bad connectionは、DM と上流の TiDB データベース間の接続に異常 (ネットワーク障害や TiDB の再起動など) が発生し、その時点では現在のリクエストのデータがまだ TiDB に送信されていないことを示します。

解決

現在のバージョンのDMは、エラー発生時に自動的に再試行します。自動再試行をサポートしていない以前のバージョンをご利用の場合は、コマンドstop-taskを実行してタスクを停止し、その後コマンドstart-task実行してタスクを再開してください。

リレーユニットはevent from in diff from passed-in event *スローするか、または、 binlogエラーの取得または解析に失敗して移行タスクが中断され、binlog get binlog error ERROR 1236 (HY000)やbinlog checksum mismatch, data may be corrupted 。

理由

リレー ログ プルまたは増分レプリケーションの DM プロセス中に、アップストリームbinlogファイルのサイズが4 GBを超えると、この 2 つのエラーが発生する可能性があります。

原因：リレーログを書き込む際、DMはbinlogの位置とbinlogファイルのサイズに基づいてイベント検証を行い、複製されたbinlogの位置をチェックポイントとして保存する必要があります。しかし、公式のMySQLではbinlogの位置をuint32保存しています。そのため、4GBを超えるbinlogファイルのbinlogの位置がオーバーフローし、上記のエラーが発生します。

ソリューション

リレー ユニットの場合は、次のソリューションを使用して手動で移行を回復します。

  1. エラーが発生したときに、対応するbinlogファイルのサイズが 4GB を超えたことをアップストリームで特定します。

  2. DM ワーカーを停止します。

  3. アップストリーム内の対応するbinlogファイルをリレー ログ ファイルとしてリレー ログ ディレクトリにコピーします。

  4. リレーログディレクトリ内の対応するrelay.metaのファイルを更新し、次のbinlogファイルから取得します。DMワーカーにenable_gtid ～ true指定した場合は、 relay.metaファイルを更新するときに、次のbinlogファイルに対応するGTIDを変更する必要があります。それ以外の場合は、GTIDを変更する必要はありません。

    例: エラーが発生した場合、 binlog-name = "mysql-bin.004451"とbinlog-pos = 2453をそれぞれbinlog-name = "mysql-bin.004452"とbinlog-pos = 4に更新し、 binlog-gtidをf0e914ef-54cf-11e7-813d-6c92bf2fa791:1-138218058に更新します。

  5. DM ワーカーを再起動します。

binlogレプリケーション処理ユニットの場合は、次のソリューションを使用して手動で移行を回復します。

  1. エラーが発生したときに、対応するbinlogファイルのサイズが 4GB を超えたことをアップストリームで特定します。

  2. stop-task使用して移行タスクを停止します。

  3. グローバル チェックポイントとダウンストリームdm_metaデータベースの各テーブル チェックポイントのbinlog_name 、エラーのあるbinlogファイルの名前に更新します。5 binlog_pos 、移行が完了した有効な位置の値 (例: 4) に更新します。

    例：エラーが発生したタスクの名前がdm_test 、対応するタスクsource-idがreplica-1 、対応するbinlogファイルがmysql-bin|000001.004451場合、次のコマンドを実行します。

    UPDATE dm_test_syncer_checkpoint SET binlog_name='mysql-bin|000001.004451', binlog_pos = 4 WHERE id='replica-1';

  4. 再入可能性を確保するには、移行タスク構成のsyncersセクションでsafe-mode: true指定します。

  5. start-task使用して移行タスクを開始します。

  6. query-status使用して移行タスクのステータスをビュー。元のエラーの原因となったリレーログファイルの移行が完了したら、 safe-mode元の値に戻して移行タスクを再開できます。

タスクをクエリするかログを確認すると、 Access denied for user 'root'@'172.31.43.27' (using password: YES)表示されます。

すべてのDM設定ファイルにおけるデータベース関連のパスワードについては、 dmctlで暗号化したパスワードを使用することをお勧めします。データベースパスワードが空の場合は、暗号化する必要はありません。プレーンテキストパスワードの暗号化方法については、 dmctlを使用してデータベースパスワードを暗号化する参照してください。

さらに、上流データベースと下流データベースのユーザーには、対応する読み取り権限と書き込み権限が必要です。データ移行タスクを開始する際には、データ移行も対応する権限を自動的に事前チェックします必要です。

load処理ユニットからpacket for query is too large. Try adjusting the 'max_allowed_packet' variable

理由

  • MySQLクライアントとMySQL/TiDBサーバーの両方にmax_allowed_packetクォータ制限があります。3 max_allowed_packetいずれかが制限を超えると、クライアントはエラーメッセージを受け取ります。現在、最新バージョンのDMとTiDBサーバーでは、デフォルト値はmax_allowed_packetではなく64Mです。

  • DM の完全データ インポート処理ユニットは、DM のダンプ処理ユニットによってエクスポートされた SQL ファイルの分割をサポートしていません。

ソリューション

  • ダンプ処理ユニットにはextra-argsオプションのうちstatement-size設定することをお勧めします。

    デフォルトの--statement-size設定によると、ダンプ処理ユニットによって生成されるデフォルトのサイズInsert Statementは約1Mです。このデフォルト設定では、ロード処理ユニットはほとんどの場合、エラーpacket for query is too large. Try adjusting the 'max_allowed_packet' variable報告しません。

    データダンプ中に、以下のログがWARN出力されることがあります。このWARNはダンプ処理には影響しません。これは、幅の広いテーブルがダンプされたことを示しているだけです。

    Row bigger than statement_size for xxx

  • ワイドテーブルの単一行が64M超える場合は、次の設定を変更し、設定が有効になっていることを確認する必要があります。

    • TiDBサーバーでset @@global.max_allowed_packet=134217728 （ 134217728 =128MB）を実行します。

    • まず、DMタスク設定ファイルのセクションtarget-databaseにmax-allowed-packet: 134217728 （128MB）を追加します。次に、コマンドstop-taskを実行し、コマンドstart-task実行します。

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