TiDB データ移行におけるエラーの処理
このドキュメントでは、エラー システムと、DM を使用するときに発生する一般的なエラーの処理方法について説明します。
エラーシステム
エラーシステムでは、通常、特定のエラーの情報は次のようになります。
code: エラーコード。DM は同じエラー タイプに対して同じエラー コードを使用します。DM バージョンが変わってもエラー コードは変わりません。
DM 反復中に一部のエラーが削除される可能性がありますが、エラー コードは削除されません。DM は、新しいエラーに対して既存のエラー コードではなく新しいエラー コードを使用します。
class: エラータイプ。エラーが発生したコンポーネント(エラー ソース) をマークするために使用されます。
次の表には、すべてのエラー タイプ、エラー ソース、およびエラー サンプルが表示されます。
scope: エラー範囲。エラーが発生したときに DM オブジェクトのスコープとソースをマークするために使用されます。
scopeには、not-set、upstream、downstream、およびinternalの 4 つのタイプが含まれます。エラーのロジックが上流データベースと下流データベース間のリクエストに直接関係する場合、スコープは
upstreamまたはdownstreamに設定されます。それ以外の場合、現在はinternalに設定されています。level: エラーレベル。エラー
high重大度レベルlowmedium含まれます。- レベル
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エラーの取得または解析に失敗して中断され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ファイルをリレー ログ ファイルとしてリレー ログ ディレクトリにコピーします。
リレーログディレクトリで、次のbinlogファイルからプルするために、対応する
relay.metaファイルを更新します。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-gtidf0e914ef-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ワイドテーブルの単一行が
64M超える場合は、次の設定を変更し、設定が有効になっていることを確認する必要があります。TiDBサーバーで
set @@global.max_allowed_packet=134217728（134217728= 128 MB）を実行します。まず、DM タスク構成ファイルの
target-databaseセクションにmax-allowed-packet: 134217728(128 MB) を追加します。次に、stop-taskコマンドを実行し、start-taskコマンドを実行します。