TiDB データ移行におけるエラーの処理
このドキュメントでは、DM 使用時のエラー システムと一般的なエラーの処理方法を紹介します。
エラーシステム
エラー システムでは、通常、特定のエラーの情報は次のとおりです。
code: エラーコード。DM は、同じエラー タイプに対して同じエラー コードを使用します。 DMのバージョンが変わってもエラーコードは変わりません。
一部のエラーは DM の反復中に削除される可能性がありますが、エラー コードは削除されません。 DM は、新しいエラーに対して既存のエラー コードではなく新しいエラー コードを使用します。
class: エラーの種類。これは、エラーが発生したコンポーネント(エラーソース) をマークするために使用されます。
次の表に、すべてのエラー タイプ、エラー ソース、およびエラー サンプルを示します。
scope: エラー範囲。これは、エラーが発生したときに DM オブジェクトのスコープとソースをマークするために使用されます。
scopenot-set、upstream、downstream、およびinternalの 4 つのタイプが含まれます。エラーのロジックがアップストリーム データベースとダウンストリーム データベース間のリクエストに直接関係する場合、スコープは
upstreamまたはdownstreamに設定されます。それ以外の場合は、現在internalに設定されています。level: エラーレベル。エラーの重大度レベル (
low、medium、およびhighを含む)。lowレベルのエラーは通常、ユーザーの操作や誤った入力に関連しています。移行タスクには影響しません。mediumレベルのエラーは通常、ユーザー設定に関連しています。新しく開始された一部のサービスに影響します。ただし、既存の DM 移行ステータスには影響しません。- レベル
highエラーは、移行タスクの中断を避けるために解決する必要があるため、通常は注意が必要です。
message: エラーの説明。エラーの詳細な説明。エラー呼び出しチェーン上のエラー メッセージのすべての追加レイヤーをラップして保存するには、 エラー.ラップモードが採用されます。レイヤーでラップされたメッセージ記述は DM のエラーを示し、最レイヤーでラップされたメッセージ記述はエラーの原因を示します。
workaround: エラー処理メソッド (オプション)このエラーの処理方法。一部の確認されたエラー (構成エラーなど) については、DM は対応する手動処理方法を
workaroundに示します。エラースタック情報(オプション)
DM がエラースタック情報を出力するかどうかは、エラーの重大度と必要性に応じて異なります。エラー スタックには、エラーが発生したときの完全なスタック呼び出し情報が記録されます。基本情報やエラーメッセージからはエラーの原因が特定できない場合は、エラースタックを使用してエラー発生時のコードの実行パスを追跡できます。
エラー コードの完全なリストについては、 エラーコードリストを参照してください。
トラブルシューティング
DM の実行中にエラーが発生した場合は、次の手順を実行してこのエラーのトラブルシューティングを行ってください。
query-statusコマンドを実行してタスクの実行状況とエラー出力を確認します。エラーに関連するログ ファイルを確認してください。ログ ファイルは DM マスター ノードと DM ワーカー ノード上にあります。エラーに関する重要な情報を取得するには、 エラーシステムを参照してください。次に、 一般的なエラーの処理セクションを確認して解決策を見つけます。
このドキュメントでエラーが説明されておらず、ログを確認したりメトリックを監視したりしても問題を解決できない場合は、 支持を得ます PingCAP またはコミュニティから問い合わせてください。
エラーが解決したら、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エラーの取得または解析に失敗して移行タスクが中断されbinlog checksum mismatch, data may be corrupted
理由
リレー ログのプルまたは増分レプリケーションの DM プロセス中に、アップストリームのbinlogファイルのサイズが4 GBを超えると、この 2 つのエラーが発生する可能性があります。
原因:リレー ログを書き込むとき、DM はbinlogの位置とbinlogログ ファイルのサイズに基づいてイベント検証を実行し、レプリケートされたbinlogの位置をチェックポイントとして保存する必要があります。ただし、公式の MySQL では、binlogの位置を保存するためにuint32を使用します。これは、4 GB を超えるbinlogファイルのbinlog位置がオーバーフローし、上記のエラーが発生することを意味します。
ソリューション
中継ユニットの場合は、次の解決策を使用して移行を手動で回復します。
エラーが発生したときに、対応するbinlogファイルのサイズが 4GB を超えていたことをアップストリームで特定します。
DM ワーカーを停止します。
アップストリームの対応するbinlogファイルをリレー ログ ファイルとしてリレー ログ ディレクトリにコピーします。
リレー ログ ディレクトリで、次の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-gtidf0e914ef-54cf-11e7-813d-6c92bf2fa791:1-138218058に更新します。DM ワーカーを再起動します。
binlogレプリケーション処理ユニットの場合は、次の解決策を使用して移行を手動で回復します。
エラーが発生したときに、対応するbinlogファイルのサイズが 4GB を超えていたことをアップストリームで特定します。
stop-taskを使用して移行タスクを停止します。グローバル チェックポイントの 1 と、ダウンストリーム
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_packet64M。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コマンドを実行します。