📣
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 内でエラーが発生するか、dmctl が他のコンポーネントと対話するときにエラーが発生します。[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=10006INSERT 、またはDELETEタイプの DDL ステートメントおよび DML ステートメントを含む、 EXECUTEタイプの SQL ステートメントUPDATE実行するときに発生します。詳細なエラー情報については、エラー メッセージを確認してください。通常、データベース操作で返されたエラー コードとエラー情報が含まれています。
code=11006DM の組み込みパーサーが互換性のない DDL ステートメントを解析するときに発生します。解決策についてはデータ移行 - 互換性のない DDL ステートメントを参照してください。
code=20010タスク構成で指定されたデータベースのパスワードを復号化するときに発生します。構成タスクで指定されたダウンストリーム データベースのパスワードがdmctl を使用して正しく暗号化されているであるかどうかを確認します。
code=26002タスクチェックでデータベース接続の確立に失敗しました。詳細なエラー情報については、エラー メッセージを確認してください。通常、データベース操作で返されたエラー コードとエラー情報が含まれています。DM-master が配置されているマシンにアップストリームへのアクセス許可があるかどうかを確認します。
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 *エラー イベントをスローするか、 get binlog error ERROR 1236 (HY000)やbinlog checksum mismatch, data may be corruptedなどのbinlogエラーの取得または解析に失敗して移行タスクが中断され、データが破損している可能性があります。

理由

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

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

ソリューション

中継ユニットの場合は、次の解決策を使用して移行を手動で回復します。

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

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

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

  4. リレー ログ ディレクトリで、次のbinlogファイルから取得するように対応するrelay.metaファイルを更新します。 DM-worker に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. グローバル チェックポイントの 1 と、ダウンストリームdm_metaデータベースの各テーブル チェックポイントのbinlog_nameを、エラーが発生したbinlogファイルの名前に更新します。 binlog_posを、移行が完了した有効な位置の値、たとえば 4 に更新します。

    例: エラーが発生したタスクの名前はdm_test 、対応する s 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です。 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

  • 幅の広いテーブルの 1 行が64Mを超える場合は、次の構成を変更し、構成が有効になることを確認する必要があります。

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

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

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