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

エラー処理

このドキュメントでは、エラー システムと、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-trackerschema-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-master ノードと DM-worker ノードにあります。エラーに関する重要な情報を取得するには、 エラーシステムを参照してください。次に、 一般的なエラーを処理するセクションを確認して解決策を見つけます。

  3. エラーがこのドキュメントでカバーされておらず、ログを確認したりメトリックを監視したりしても問題を解決できない場合は、R&D に連絡できます。

  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 ステートメント (DDL ステートメントおよびINSERT 、 UPDATEまたはDELETEタイプの DML ステートメントを含む) を実行するときに発生します。詳細なエラー情報については、通常、データベース操作に対して返されるエラー コードとエラー情報を含むエラー メッセージを確認してください。
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などのバイナリ ログ エラーの取得または解析に失敗して移行タスクが中断されます。

理由

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

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

ソリューション

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

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

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

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

  4. リレー ログ ディレクトリで、対応するrelay.metaファイルを更新して、次の binlog ファイルからプルします。 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-worker を再起動します。

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

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

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

  3. グローバル チェックポイントおよびダウンストリーム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 の Dump 処理ユニットによってエクスポートされた SQL ファイルの分割をサポートしていません。

ソリューション

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

    デフォルトの--statement-size設定によれば、Dump 処理ユニットによって生成されるデフォルトのサイズ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コマンドを実行します。