エラーの処理
このドキュメントでは、エラーシステムと、DMを使用する場合の一般的なエラーの処理方法を紹介します。
エラーシステム
エラーシステムでは、通常、特定のエラーの情報は次のとおりです。
code：エラーコード。DMは、同じエラータイプに対して同じエラーコードを使用します。 DMのバージョンが変わってもエラーコードは変わりません。
一部のエラーはDMの反復中に削除される可能性がありますが、エラーコードは削除されません。 DMは、新しいエラーに対して既存のエラーコードではなく、新しいエラーコードを使用します。
class：エラータイプ。エラーが発生したコンポーネント（エラーソース）をマークするために使用されます。
次の表に、すべてのエラータイプ、エラーソース、およびエラーサンプルを示します。
エラータイプ エラーソース エラーサンプル databaseデータベース操作 [code=10003:class=database:scope=downstream:level=medium] database driver: invalid connectionfunctionalDMの基本的な機能 [code=11005:class=functional:scope=internal:level=high] not allowed operation: alter multiple tables in one statementconfig設定が正しくありません [code=20005:class=config:scope=internal:level=medium] empty source-id not validbinlog-opビンログ操作 [code=22001:class=binlog-op:scope=internal:level=high] empty UUIDs not validcheckpointチェックポイント操作 [code=24002:class=checkpoint:scope=internal:level=high] save point bin.1234 is older than current pos bin.1371task-checkタスクチェックの実行 [code=26003:class=task-check:scope=internal:level=medium] new table router errorrelay-event-libリレーモジュールの基本機能を実行する [code=28001:class=relay-event-lib:scope=internal:level=high] parse server-uuid.indexrelay-unitリレー処理装置 [code=30015:class=relay-unit:scope=upstream:level=high] TCPReader get event: ERROR 1236 (HY000): Could not open log filedump-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 foundsync-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 blockingdm-tracerDMトレーサーサービス [code=42004:class=dm-tracer:scope=internal:level=medium] trace event test.1 not foundschema-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、およびdownstreamのupstreamつのタイプが含まれinternal。エラーのロジックにアップストリームデータベースとダウンストリームデータベース間のリクエストが直接含まれる場合、スコープは
upstreamまたはdownstreamに設定されます。それ以外の場合は、現在internalに設定されています。level：エラーレベル。low、およびmediumを含むエラーの重大度high。lowレベルのエラーは通常、ユーザーの操作と誤った入力に関連しています。移行タスクには影響しません。mediumレベルのエラーは通常、ユーザー構成に関連しています。新しく開始されたサービスに影響します。ただし、既存のDM移行ステータスには影響しません。highレベルのエラーは、移行タスクの中断を回避するために解決する必要があるため、通常は注意が必要です。
message：エラーの説明。エラーの詳細な説明。エラーメッセージのすべての追加レイヤーをエラーコールチェーンにラップして保存するために、 エラー。ラップモードが採用されています。最外層でラップされたメッセージの説明はDMのエラーを示し、最内層でラップされたメッセージの説明はエラーの原因を示します。
workaround：エラー処理方法（オプション）このエラーの処理方法。一部の確認済みエラー（構成エラーなど）については、DMは対応する手動処理方法を
workaroundで示しています。エラースタック情報（オプション）
DMがエラースタック情報を出力するかどうかは、エラーの重大度と必要性によって異なります。エラースタックは、エラーが発生したときに完全なスタック呼び出し情報を記録します。基本情報やエラーメッセージからエラーの原因がわからない場合は、エラースタックを使用してエラー発生時のコードの実行パスをたどることができます。
エラーコードの完全なリストについては、 エラーコードリストを参照してください。
トラブルシューティング
DMの実行中にエラーが発生した場合は、次の手順を実行してこのエラーのトラブルシューティングを行ってください。
query-statusコマンドを実行して、タスクの実行状態とエラー出力を確認してください。エラーに関連するログファイルを確認してください。ログファイルはDM-masterノードとDM-workerノードにあります。エラーに関する重要な情報を取得するには、 エラーシステムを参照してください。次に、 一般的なエラーの処理のセクションをチェックして解決策を見つけます。
エラーがこのドキュメントでカバーされておらず、ログを確認したりメトリックを監視したりしても問題を解決できない場合は、R＆Dに連絡できます。
エラーが解決したら、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=10005 | QUERY型SQLステートメントを実行するときに発生します。 | |
code=10006 | INSERT 、またはUPDATEタイプのDDLステートメントおよびDMLステートメントを含むEXECUTEタイプのSQLステートメントを実行するときに発生しDELETE 。より詳細なエラー情報については、通常、データベース操作で返されるエラーコードとエラー情報を含むエラーメッセージを確認してください。 | |
code=11006 | DMの組み込みパーサーが互換性のないDDLステートメントを解析するときに発生します。 | 解決策についてはデータ移行-互換性のないDDLステートメントを参照してください。 |
code=20010 | タスク構成で提供されるデータベースパスワードを復号化するときに発生します。 | 構成タスクで提供されたダウンストリームデータベースのパスワードがdmctlを使用して正しく暗号化されているであるかどうかを確認します。 |
code=26002 | タスクチェックはデータベース接続の確立に失敗します。より詳細なエラー情報については、通常、データベース操作で返されるエラーコードとエラー情報を含むエラーメッセージを確認してください。 | DM-masterが配置されているマシンにアップストリームへのアクセス許可があるかどうかを確認します。 |
code=32001 | 異常なダンプ処理装置 | エラーメッセージにmydumper: argument list too long.が含まれている場合は、block-allowリストに従って、 task.yamlファイルのMydumper引数extra-argsに--regexの正規表現を手動で追加して、エクスポートするテーブルを構成します。たとえば、 helloという名前のすべてのテーブルをエクスポートするには、 --regex '.*\\.hello$'を追加します。すべてのテーブルをエクスポートするには、 --regex '.*'を追加します。 |
code=38008 | DMコンポーネント間の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の位置を格納します。これは、4 GBを超えるbinlogファイルのbinlog位置がオーバーフローし、上記のエラーが発生することを意味します。
ソリューション
リレーユニットの場合、次のソリューションを使用して手動で移行を回復します。
エラーが発生したときに、対応するbinlogファイルのサイズが4GBを超えたことをアップストリームで識別します。
DMワーカーを停止します。
アップストリームの対応するbinlogファイルをリレーログファイルとしてリレーログディレクトリにコピーします。
リレーログディレクトリで、対応する
relay.metaのファイルを更新して、次のbinlogファイルからプルします。 DM-workerにenable_gtidを指定した場合は、trueファイルを更新するときに、次のrelay.metaファイルに対応する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に更新します。DMワーカーを再起動します。
binlogレプリケーション処理装置の場合、次のソリューションを使用して手動でマイグレーションをリカバリーします。
エラーが発生したときに、対応するbinlogファイルのサイズが4GBを超えたことをアップストリームで識別します。
stop-taskを使用して移行タスクを停止します。グローバルチェックポイントおよびダウンストリーム
dm_metaデータベースの各テーブルチェックポイントのbinlog_nameを、エラーのあるbinlogファイルの名前に更新します。binlog_posを、移行が完了した有効な位置の値（たとえば、4）に更新します。例：エラーのあるタスクの名前は
dm_test、対応するssource-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';再入可能を確保するために、移行タスク構成の
syncersセクションでsafe-mode: trueを指定します。start-taskを使用して移行タスクを開始します。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コマンドを実行します。