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を実行してレプリケーションタスクの状態を確認します。 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. チェンジフィードの設定を変更し、 ignore-txn-start-ts設定項目に上記start-tsを追加します。
5. 一時停止した変更フィードを再開します。

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

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

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 以前のバージョンの場合、シンク 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 ステートメントの実行に失敗すると、レプリケーション タスク (変更フィード) が自動的に停止します。チェックポイント ts は、DDL ステートメントの終了 ts から 1 を引いたものです。 TiCDC がダウンストリームでこのステートメントの実行を再試行するようにするには、 cdc cli changefeed resumeを使用してレプリケーション タスクを再開します。例えば：

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

問題が発生したこの DDL ステートメントをスキップしたい場合は、変更フィードの start-ts をチェックポイント ts (DDL ステートメントが失敗した時点のタイムスタンプ) に 1 を加えた値に設定し、 cdc cli changefeed createコマンドを実行して新しい変更フィードを作成します。タスク。たとえば、DDL ステートメントが失敗する Checkpoint-ts が415241823337054209の場合、次のコマンドを実行してこの DDL ステートメントをスキップします。

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

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"