TiDBデータ移行におけるエラーの処理
このドキュメントでは、エラー システムと、DM を使用するときに発生する一般的なエラーの処理方法について説明します。
エラーシステム
エラー システムでは、通常、特定のエラーの情報は次のようになります。
code: エラーコード。DMでは、同じエラータイプに対して同じエラーコードが使用されます。DMのバージョンが変更されても、エラーコードは変更されません。
DM 反復処理中に一部のエラーが削除される可能性がありますが、エラー コードは削除されません。DM は、新しいエラーに対して既存のエラー コードではなく新しいエラー コードを使用します。
class: エラータイプ。エラーが発生したコンポーネント(エラー ソース) をマークするために使用されます。
次の表には、すべてのエラー タイプ、エラー ソース、およびエラー サンプルが表示されます。
scope: エラー範囲。エラーが発生したときに、 DM オブジェクトのスコープとソースをマークするために使用されます。
scopeは、not-set、upstream、downstream、internal4 つのタイプが含まれます。エラーのロジックが上流データベースと下流データベース間のリクエストに直接関係する場合、スコープは
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 *スローするか、または、 binlogエラーの取得または解析に失敗して移行タスクが中断され、binlog get binlog error ERROR 1236 (HY000)やbinlog checksum mismatch, data may be corrupted 。
理由
リレー ログ プルまたは増分レプリケーションの DM プロセス中に、アップストリームbinlogファイルのサイズが4 GBを超えると、この 2 つのエラーが発生する可能性があります。
原因：リレーログを書き込む際、DMはbinlogの位置とbinlogファイルのサイズに基づいてイベント検証を行い、複製されたbinlogの位置をチェックポイントとして保存する必要があります。しかし、公式のMySQLではbinlogの位置をuint32保存しています。そのため、4GBを超えるbinlogファイルのbinlogの位置がオーバーフローし、上記のエラーが発生します。
ソリューション
リレー ユニットの場合は、次のソリューションを使用して手動で移行を回復します。
エラーが発生したときに、対応するbinlogファイルのサイズが 4GB を超えたことをアップストリームで特定します。
DM ワーカーを停止します。
アップストリーム内の対応するbinlogファイルをリレー ログ ファイルとしてリレー ログ ディレクトリにコピーします。
リレーログディレクトリ内の対応する
relay.metaのファイルを更新し、次のbinlogファイルから取得します。DMワーカーに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に更新します。DM ワーカーを再起動します。
binlogレプリケーション処理ユニットの場合は、次のソリューションを使用して手動で移行を回復します。
エラーが発生したときに、対応するbinlogファイルのサイズが 4GB を超えたことをアップストリームで特定します。
stop-task使用して移行タスクを停止します。グローバル チェックポイントとダウンストリーム
dm_metaデータベースの各テーブル チェックポイントのbinlog_name、エラーのあるbinlogファイルの名前に更新します。5binlog_pos、移行が完了した有効な位置の値 (例: 4) に更新します。例：エラーが発生したタスクの名前が
dm_test、対応するタスク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';再入可能性を確保するには、移行タスク構成の
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クォータ制限があります。3max_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ワイドテーブルの単一行が
64M超える場合は、次の設定を変更し、設定が有効になっていることを確認する必要があります。TiDBサーバーで
set @@global.max_allowed_packet=134217728（134217728=128MB）を実行します。まず、DMタスク設定ファイルのセクション
target-databaseにmax-allowed-packet: 134217728（128MB）を追加します。次に、コマンドstop-taskを実行し、コマンドstart-task実行します。