TiCDC のトラブルシューティング

このドキュメントでは、TiCDC の使用時に発生する可能性のある一般的なエラーと、それに対応するメンテナンスおよびトラブルシューティングの方法について説明します。

注記：

このドキュメントでは、 cdc cliコマンドで指定されているサーバーアドレスはserver=http://127.0.0.1:8300です。コマンドを使用するときは、アドレスを実際の TiCDC サーバー アドレスに置き換えてください。

TiCDC レプリケーションの中断

TiCDC レプリケーション タスクが中断されたかどうかはどうすればわかりますか?

• Grafana ダッシュボードで、レプリケーション タスクのchangefeed checkpoint監視メトリックを確認します (正しいchangefeed idを選択)。メトリック値が変更されない場合、またはcheckpoint lagメトリックが増加し続ける場合、レプリケーション タスクが中断されている可能性があります。
• exit error count監視メトリックを確認します。メトリック値が0より大きい場合、レプリケーション タスクでエラーが発生しました。
• cdc cli changefeed listとcdc cli changefeed queryを実行して、レプリケーション タスクのステータスを確認します。5 stoppedタスクが停止したことを意味し、 error項目には詳細なエラー メッセージが表示されます。エラーが発生したら、TiCDCサーバーログでerror on running processorを検索してエラー スタックを確認し、トラブルシューティングを行うことができます。
• 極端なケースでは、TiCDC サービスが再起動されます。トラブルシューティングのために、TiCDCサーバーログのFATALレベル ログを検索できます。

レプリケーション タスクが手動で停止されたかどうかを確認するにはどうすればよいですか?

cdc cliを実行すると、レプリケーション タスクが手動で停止されているかどうかを確認できます。例:

cdc cli changefeed query --server=http://127.0.0.1:8300 --changefeed-id 28c43ffc-2316-4f4f-a70b-d1a7c59ba79f

上記のコマンドの出力では、 admin-job-typeこのレプリケーション タスクの状態を示しています。各状態とその意味の詳細については、 チェンジフィードの状態を参照してください。

レプリケーションの中断をどのように処理しますか?

次の既知のシナリオでは、レプリケーション タスクが中断される可能性があります。

• ダウンストリームは引き続き異常であり、何度も再試行しても TiCDC は失敗します。

  • このシナリオでは、TiCDC はタスク情報を保存します。TiCDC は PD にサービス GC セーフポイントを設定しているため、タスク チェックポイント以降のデータは有効期間gc-ttl内に TiKV GC によってクリーンアップされません。

  • 処理方法: ダウンストリームが正常に戻った後、 cdc cli changefeed resume実行することでレプリケーション タスクを再開できます。

• ダウンストリームに互換性のない SQL ステートメントがあるため、レプリケーションを続行できません。

  • このシナリオでは、TiCDC はタスク情報を保存します。TiCDC は PD にサービス GC セーフポイントを設定しているため、タスク チェックポイント以降のデータは有効期間gc-ttl内に TiKV GC によってクリーンアップされません。
  • 取り扱い手順:
    1. cdc cli changefeed queryコマンドを使用してレプリケーション タスクのステータス情報を照会し、 checkpoint-tsの値を記録します。
    2. 新しいタスク構成ファイルを使用して、 ignore-txn-start-tsパラメータを追加し、指定されたstart-tsに対応するトランザクションをスキップします。
    3. cdc cli changefeed pause -c <changefeed-id>実行してレプリケーション タスクを一時停止します。
    4. cdc cli changefeed update -c <changefeed-id> --config <config-file-path>を実行して新しいタスク構成ファイルを指定します。
    5. cdc cli changefeed resume -c <changefeed-id>を実行してレプリケーション タスクを再開します。

タスク中断後に TiCDC を再起動した後に発生する OOM を処理するにはどうすればよいですか?

• TiDB クラスターと TiCDC クラスターを最新バージョンに更新します。OOM の問題は、v4.0.14 以降の v4.0 バージョン、v5.0.2 以降の v5.0 バージョン、および最新バージョンではすでに解決されています。

レプリケーション タスクを作成するとき、またはデータを MySQL にレプリケートするときに発生するError 1298: Unknown or incorrect time zone: 'UTC'エラーをどのように処理すればよいですか?

このエラーは、ダウンストリーム MySQL がタイムゾーンをロードしない場合に返されます。 mysql_tzinfo_to_sql実行すると、タイムゾーンをロードできます。タイムゾーンをロードした後は、タスクを作成してデータを正常にレプリケートできます。

mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql -p

上記のコマンドの出力が次のようなものであれば、インポートは成功しています。

Enter password:
Warning: Unable to load '/usr/share/zoneinfo/iso3166.tab' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo/leap-seconds.list' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo/zone.tab' as time zone. Skipping it.
Warning: Unable to load '/usr/share/zoneinfo/zone1970.tab' as time zone. Skipping it.

ダウンストリームが特殊な MySQL 環境 (パブリック クラウド RDS または一部の MySQL 派生バージョン) であり、前述の方法を使用したタイム ゾーンのインポートが失敗した場合は、 time-zone time-zone=""などの空の値に設定することで、ダウンストリームのデフォルトのタイム ゾーンを使用できます。

TiCDC でタイムゾーンを使用する場合は、 time-zone="Asia/Shanghai"などのタイムゾーンを明示的に指定することをお勧めします。また、TiCDCサーバー構成で指定されたtzとシンク URI で指定されたtime-zone 、ダウンストリーム データベースのタイムゾーン構成と一致していることを確認してください。これにより、タイムゾーンの不一致によるデータの不一致を防ぐことができます。

TiCDC のアップグレードによって発生した構成ファイルの非互換性の問題をどのように処理すればよいですか?

互換性に関する注意事項を参照してください。

TiCDC タスクのstart-tsタイムスタンプが現在の時刻と大きく異なります。このタスクの実行中にレプリケーションが中断され、エラー[CDC:ErrBufferReachLimit]が発生します。どうすればよいでしょうか?

v4.0.9 以降では、レプリケーション タスクで統合ソート機能を有効にするか、 BRツールを使用して増分バックアップと復元を実行し、新しい時間から TiCDC レプリケーション タスクを開始することができます。

変更フィードのダウンストリームが MySQL に似たデータベースであり、TiCDC が時間のかかる DDL ステートメントを実行すると、他のすべての変更フィードがブロックされます。どうすればよいでしょうか?

1. 時間のかかる DDL ステートメントを含む変更フィードの実行を一時停止します。すると、他の変更フィードがブロックされなくなったことがわかります。
2. TiCDC ログでapply jobフィールドを検索し、時間のかかる DDL ステートメントのstart-tsを確認します。
3. ダウンストリームで DDL ステートメントを手動で実行します。実行が完了したら、次の操作を実行します。
4. changefeed 設定を変更し、上記のstart-ts ignore-txn-start-ts構成項目に追加します。
5. 一時停止した変更フィードを再開します。

TiCDC を使用して変更フィードを作成すると[tikv:9006]GC life time is shorter than transaction duration, transaction starts at xx, GC safe point is yyエラーが報告されます。どうすればよいですか?

現在の GC セーフポイントとサービス GC セーフポイントを照会するには、 pd-ctl service-gc-safepoint --pd <pd-addrs>コマンドを実行する必要があります。GC セーフポイントが TiCDC レプリケーション タスク (changefeed) のstart-tsより小さい場合は、 cdc cli create changefeedコマンドに--disable-gc-checkオプションを直接追加して changefeed を作成できます。

pd-ctl service-gc-safepoint --pd <pd-addrs>の結果にgc_worker service_idがない場合:

• PD バージョンが v4.0.8 以前の場合、詳細についてはPD 号 #3128を参照してください。
• PD を v4.0.8 以前のバージョンからそれ以降のバージョンにアップグレードする場合は、詳細についてはPD 号 #3366を参照してください。

TiCDC を使用してメッセージを Kafka に複製すると、Kafka はMessage was too largeエラーを返します。なぜでしょうか?

TiCDC v4.0.8 以前のバージョンでは、Sink URI で Kafka にmax-message-bytes設定を構成するだけでは、Kafka に出力されるメッセージのサイズを効果的に制御することはできません。メッセージ サイズを制御するには、Kafka が受信するメッセージのバイト制限も増やす必要があります。このような制限を追加するには、Kafkaサーバー構成に次の構成を追加します。

# The maximum byte number of a message that the broker receives
message.max.bytes=2147483648
# The maximum byte number of a message that the broker copies
replica.fetch.max.bytes=2147483648
# The maximum message byte number that the consumer side reads
fetch.message.max.bytes=2147483648

TiCDC レプリケーション中に、ダウンストリームで DDL ステートメントの実行が失敗したかどうかを確認するにはどうすればよいでしょうか? レプリケーションを再開するにはどうすればよいでしょうか?

DDL ステートメントの実行に失敗した場合、レプリケーション タスク (changefeed) は自動的に停止します。チェックポイント ts は、DDL ステートメントの終了 ts です。TiCDC にこのステートメントの実行をダウンストリームで再試行させたい場合は、 cdc cli changefeed resume使用してレプリケーション タスクを再開します。例:

cdc cli changefeed resume -c test-cf --server=http://127.0.0.1:8300

この間違った DDL ステートメントをスキップする場合は、changefeed の start-ts を checkpoint-ts (DDL ステートメントが間違ったタイムスタンプ) に 1 を加えた値に設定し、 cdc cli changefeed createコマンドを実行して新しい changefeed タスクを作成します。たとえば、DDL ステートメントが間違った checkpoint-ts が415241823337054209の場合、以下のコマンドを実行してこの DDL ステートメントをスキップします。

この間違った DDL ステートメントをスキップするには、 ignore-txn-start-tsパラメータを設定して、指定されたstart-tsに対応するトランザクションをスキップします。例:

1. TiCDC ログでapply jobフィールドを検索し、時間がかかっているstart-tsの DDL を特定します。
2. changefeed 設定を変更します。上記のstart-ts ignore-txn-start-ts構成項目に追加します。
3. 中断された変更フィードを再開します。

注記：

changefeed start-ts checkpoint-ts (エラー発生時) に 1 を加えた値に設定してタスクを再作成すると、DDL ステートメントをスキップできますが、TiCDC がcheckpointTs+1の時点での DML データ変更を失う可能性もあります。したがって、この操作は本番環境では厳重に禁止されています。

cdc cli changefeed remove --server=http://127.0.0.1:8300 --changefeed-id simple-replication-task
cdc cli changefeed create --server=http://127.0.0.1:8300 --sink-uri="mysql://root:123456@127.0.0.1:3306/" --changefeed-id="simple-replication-task" --sort-engine="unified" --start-ts 415241823337054210

TiCDC を使用してメッセージを Kafka に複製するとKafka: client has run out of available brokers to talk to: EOFエラーが報告されます。どうすればよいでしょうか?

このエラーは通常、TiCDC と Kafka クラスター間の接続障害によって発生します。トラブルシューティングするには、Kafka ログとネットワーク ステータスを確認します。考えられる原因の 1 つは、レプリケーション タスクの作成時に正しいkafka-versionパラメータを指定しなかったため、TiCDC 内の Kafka クライアントが Kafkaサーバーにアクセスするときに間違った Kafka API バージョンを使用していることです。この問題を解決するには、 --sink-uri構成で正しいkafka-versionパラメータを指定します。例:

cdc cli changefeed create --server=http://127.0.0.1:8300 --sink-uri "kafka://127.0.0.1:9092/test?topic=test&protocol=open-protocol&kafka-version=2.4.0"