TiDB データ移行でエラーを処理する

このドキュメントでは、エラー システムと、DM を使用する際の一般的なエラーの処理方法を紹介します。

エラーシステム

エラーシステムでは、通常、特定のエラーの情報は次のとおりです。

• code : エラー コード。

  DM は、同じエラー タイプに対して同じエラー コードを使用します。 DMのバージョンが変わってもエラーコードは変わりません。

  DM 反復中に一部のエラーが除去される可能性がありますが、エラー コードは除去されません。 DM は、新しいエラーに対して既存のエラー コードではなく、新しいエラー コードを使用します。

• class : エラーの種類。

  エラーが発生したコンポーネント (エラー ソース) をマークするために使用されます。

  次の表に、すべてのエラー タイプ、エラー ソース、およびエラー サンプルを示します。

  エラーの種類	エラーの原因	エラーサンプル
  database	データベース操作	[code=10003:class=database:scope=downstream:level=medium] database driver: invalid connection
  functional	DMの基本関数	[code=11005:class=functional:scope=internal:level=high] not allowed operation: alter multiple tables in one statement
  config	不適切な構成	[code=20005:class=config:scope=internal:level=medium] empty source-id not valid
  binlog-op	Binlog操作	[code=22001:class=binlog-op:scope=internal:level=high] empty UUIDs not valid
  checkpoint	チェックポイント操作	[code=24002:class=checkpoint:scope=internal:level=high] save point bin.1234 is older than current pos bin.1371
  task-check	タスクチェックの実行	[code=26003:class=task-check:scope=internal:level=medium] new table router error
  relay-event-lib	リレーモジュールの基本関数の実行	[code=28001:class=relay-event-lib:scope=internal:level=high] parse server-uuid.index
  relay-unit	中継処理ユニット	[code=30015:class=relay-unit:scope=upstream:level=high] TCPReader get event: ERROR 1236 (HY000): Could not open log file
  dump-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 found
  sync-unit	同期処理ユニット	[code=36027:class=sync-unit:scope=internal:level=high] Column count doesn't match value count: 9 (columns) vs 10 (values)
  dm-master	DMマスターサービス	[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-worker	DMワーカーサービス	[code=40066:class=dm-worker:scope=internal:level=high] ExecuteDDL timeout, try use query-status to query whether the DDL is still blocking
  dm-tracer	DMトレーサーサービス	[code=42004:class=dm-tracer:scope=internal:level=medium] trace event test.1 not found
  schema-tracker	schema-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"
  dmctl	dmctl 内で、または他のコンポーネントと対話するときにエラーが発生する	[code=48001:class=dmctl:scope=internal:level=high],"can not create grpc connection"

• scope : エラー範囲。

  エラーが発生したときに、DM オブジェクトのスコープとソースをマークするために使用されます。 scopeには、 not-set 、 upstream 、 downstream 、およびinternalの 4 つのタイプが含まれます。

  エラーのロジックがアップストリーム データベースとダウンストリーム データベースの間の要求に直接関係している場合、スコープはupstreamまたはdownstreamに設定されます。それ以外の場合、現在はinternalに設定されています。

• level : エラーレベル。

  low 、 medium 、およびhighを含む、エラーの重大度レベル。

  • lowレベルのエラーは、通常、ユーザーの操作と誤った入力に関連しています。移行タスクには影響しません。
  • 通常、 mediumレベルのエラーはユーザー構成に関連しています。新しく開始された一部のサービスに影響します。ただし、既存の DM 移行ステータスには影響しません。
  • highレベルのエラーは、移行タスクが中断される可能性を回避するために解決する必要があるため、通常は注意が必要です。

• message : エラーの説明。

  エラーの詳細な説明。エラー コール チェーンのエラー メッセージのすべての追加レイヤーをラップして格納するには、 エラー。ラップモードが採用されます。最外層でラップされたメッセージの説明は DM のエラーを示し、最レイヤーでラップされたメッセージの説明はエラーのソースを示します。

• workaround : エラー処理方法 (オプション)

  このエラーの処理方法。一部の確認済みエラー (構成エラーなど) については、DM は対応する手動処理方法をworkaroundに示します。

• エラースタック情報 (オプション)

  DM がエラースタック情報を出力するかどうかは、エラーの重大度と必要性によって異なります。エラー スタックは、エラーが発生したときの完全なスタック呼び出し情報を記録します。基本情報とエラーメッセージからエラー原因が特定できない場合は、エラースタックを使用してエラー発生時のコードの実行経路をたどることができます。

エラー コードの完全なリストについては、 エラーコード一覧を参照してください。

トラブルシューティング

DM の実行中にエラーが発生した場合は、次の手順に従ってこのエラーをトラブルシューティングします。

1. query-statusコマンドを実行して、タスクの実行状況とエラー出力を確認します。

2. エラーに関連するログ ファイルを確認します。ログ ファイルは、DM-master ノードと DM-worker ノードにあります。エラーに関する重要な情報を取得するには、 エラーシステムを参照してください。次に、 一般的なエラーを処理するセクションを確認して解決策を見つけます。

3. エラーがこのドキュメントでカバーされておらず、ログを確認したりメトリックを監視したりしても問題を解決できない場合は、R&D に連絡できます。

4. エラーが解決したら、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 ファイルの binlog 位置が 4 GB を超えてオーバーフローし、上記のエラーが発生することを意味します。

ソリューション

リレー ユニットの場合は、次の解決策を使用して移行を手動で回復します。

1. エラーが発生した時点で、対応する binlog ファイルのサイズが 4GB を超えていることをアップストリームで特定します。

2. DM ワーカーを停止します。

3. アップストリームの対応する binlog ファイルをリレー ログ ファイルとしてリレー ログ ディレクトリにコピーします。

4. リレー ログ ディレクトリで、対応するrelay.metaファイルを更新して、次の binlog ファイルからプルします。 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-gtidをf0e914ef-54cf-11e7-813d-6c92bf2fa791:1-138218058に更新します。

5. DM-worker を再起動します。

バイナリログ レプリケーション処理ユニットの場合、次のソリューションを使用して移行を手動で回復します。

1. エラーが発生した時点で、対応する binlog ファイルのサイズが 4GB を超えていることをアップストリームで特定します。

2. stop-taskを使用して移行タスクを停止します。

3. グローバル チェックポイントおよびダウンストリームdm_metaデータベースの各テーブル チェックポイントのbinlog_nameを、エラーが発生した binlog ファイルの名前に更新します。 binlog_posを、移行が完了した有効な位置の値 (4 など) に更新します。

   例: エラーのあるタスクの名前はdm_test 、対応する s 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';
   

4. 移行タスク構成のsyncersセクションでsafe-mode: trueを指定して、再入可能にします。

5. start-taskを使用して移行タスクを開始します。

6. 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 の Dump 処理ユニットによってエクスポートされた SQL ファイルの分割をサポートしていません。

ソリューション

• ダンプ処理ユニットにはextra-argsのstatement-sizeオプションを設定することをお勧めします。

  デフォルトの--statement-size設定によれば、Dump 処理ユニットによって生成されるデフォルトのサイズ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コマンドを実行します。