エラーの処理
このドキュメントでは、エラーシステムと、DMを使用する場合の一般的なエラーの処理方法を紹介します。
エラーシステム
エラーシステムでは、通常、特定のエラーの情報は次のとおりです。
code：エラーコード。DMは、同じエラータイプに対して同じエラーコードを使用します。 DMのバージョンが変わってもエラーコードは変わりません。
一部のエラーはDMの反復中に削除される可能性がありますが、エラーコードは削除されません。 DMは、新しいエラーに対して既存のエラーコードではなく、新しいエラーコードを使用します。
class：エラータイプ。エラーが発生したコンポーネント（エラーソース）をマークするために使用されます。
次の表に、すべてのエラータイプ、エラーソース、およびエラーサンプルを示します。
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}
ただし、場合によっては、データ移行タスクをリセットする必要があります。詳しくはデータ移行タスクをリセットするをご覧ください。
一般的なエラーを処理する
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コマンドを実行します。