重要
このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

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

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

ノート:

このドキュメントでは、 cdc cliコマンドで指定されたPDアドレスは--pd=http://10.0.10.25:2379です。コマンドを使用するときは、アドレスを実際のPDアドレスに置き換えてください。

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

TiCDCレプリケーションタスクが中断されているかどうかを確認するにはどうすればよいですか?

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

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

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

cdc cli changefeed query --pd=http://10.0.10.25:2379 --changefeed-id 28c43ffc-2316-4f4f-a70b-d1a7c59ba79f

上記のコマンドの出力で、 admin-job-typeはこのレプリケーションタスクの状態を示しています。

  • 0 :進行中です。これは、タスクが手動で停止されていないことを意味します。
  • 1 :一時停止しました。タスクが一時停止されると、複製されたすべてのprocessorが終了します。タスクの構成とレプリケーションステータスは保持されるため、 checkpiont-tsからタスクを再開できます。
  • 2 :再開しました。レプリケーションタスクはcheckpoint-tsから再開します。
  • 3 :削除されました。タスクが削除されると、複製されたprocessorがすべて終了し、複製タスクの構成情報がクリアされます。レプリケーションステータスは、後のクエリでのみ保持されます。

レプリケーションの中断を処理するにはどうすればよいですか?

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

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

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

    • 処理方法:ダウンストリームが通常に戻った後、HTTPインターフェースを介してレプリケーションタスクを再開できます。

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

    • このシナリオでは、TiCDCはタスク情報を保存します。 TiCDCはPDにサービスGCセーフポイントを設定しているため、タスクチェックポイント後のデータは有効期間gc-ttl以内にTiKVGCによってクリーンアップされません。
    • 取り扱い手順:
      1. cdc cli changefeed queryコマンドを使用してレプリケーションタスクのステータス情報を照会し、値checkpoint-tsを記録します。
      2. 新しいタスク構成ファイルを使用し、 ignore-txn-start-tsパラメーターを追加して、指定したstart-tsに対応するトランザクションをスキップします。
      3. HTTPAPIを介して古いレプリケーションタスクを停止します。 cdc cli changefeed createを実行して新しいタスクを作成し、新しいタスク構成ファイルを指定します。手順1で記録したcheckpoint-tsstart-tsとして指定し、新しいタスクを開始してレプリケーションを再開します。
  • TiCDC v4.0.13以前のバージョンでは、TiCDCがパーティションテーブルを複製するときに、複製の中断につながるエラーが発生する場合があります。

    • このシナリオでは、TiCDCはタスク情報を保存します。 TiCDCはPDにサービスGCセーフポイントを設定しているため、タスクチェックポイント後のデータは有効期間gc-ttl以内にTiKVGCによってクリーンアップされません。
    • 取り扱い手順:
      1. cdc cli changefeed pause -c <changefeed-id>を実行して、レプリケーションタスクを一時停止します。
      2. 約1つのムナイトを待ってから、 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派生バージョン)であり、上記の方法を使用したタイムゾーンのインポートが失敗した場合は、 sink-uritime-zoneパラメーターを使用してダウンストリームのMySQLタイムゾーンを指定する必要があります。最初に、MySQLで使用されるタイムゾーンを照会できます。

  1. MySQLで使用されるタイムゾーンをクエリします。

    show variables like '%time_zone%';
    
    +------------------+--------+
    | Variable_name    | Value  |
    +------------------+--------+
    | system_time_zone | CST    |
    | time_zone        | SYSTEM |
    +------------------+--------+
    
  2. レプリケーションタスクを作成してTiCDCサービスを作成するときにタイムゾーンを指定します。

    cdc cli changefeed create --sink-uri="mysql://root@127.0.0.1:3306/?time-zone=CST" --pd=http://10.0.10.25:2379
    

    ノート:

    CSTは、次の4つの異なるタイムゾーンの略語である可能性があります。

    • 中部標準時(米国)UT-6:00
    • 中部標準時(オーストラリア)UT + 9:30
    • 中国標準時UT+8:00
    • キューバ標準時UT-4:00

    中国では、CSTは通常ChinaStandardTimeの略です。

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. チェンジフィード構成を変更し、上記のstart-tsignore-txn-start-ts構成項目に追加します。
  5. 一時停止したチェンジフィードを再開します。

TiCDCクラスタをv4.0.8にアップグレードした後、チェンジフィードを実行すると、 [CDC:ErrKafkaInvalidConfig]Canal requires old value to be enabledますエラーが報告されます

v4.0.8以降、チェンジフィードの出力にcanal-json 、またはcanalプロトコルが使用されている場合、 maxwellは古い値機能を自動的に有効にします。ただし、TiCDCを以前のバージョンからmaxwell canal-json canal使用し、古い値機能が無効になっていると、このエラーが報告されます。

エラーを修正するには、次の手順を実行します。

  1. チェンジフィード構成ファイルの値enable-old-valuetrueに設定します。

  2. cdc cli changefeed pauseを実行して、レプリケーションタスクを一時停止します。

    cdc cli changefeed pause -c test-cf --pd=http://10.0.10.25:2379
    
  3. cdc cli changefeed updateを実行して、元のチェンジフィード構成を更新します。

    cdc cli changefeed update -c test-cf --pd=http://10.0.10.25:2379 --sink-uri="mysql://127.0.0.1:3306/?max-txn-row=20&worker-number=8" --config=changefeed.toml
    
  4. cdc cli changfeed resumeを実行して、レプリケーションタスクを再開します。

    cdc cli changefeed resume -c test-cf --pd=http://10.0.10.25:2379
    

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

現在のGCセーフポイントとサービスGCセーフポイントを照会するには、 pd-ctl service-gc-safepoint --pd <pd-addrs>コマンドを実行する必要があります。 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ステートメントの実行に失敗すると、レプリケーションタスク(changefeed)は自動的に停止します。 checkpoint-tsは、DDLステートメントのfinish-tsから1を引いたものです。 TiCDCがダウンストリームでこのステートメントの実行を再試行する場合は、 cdc cli changefeed resumeを使用してレプリケーションタスクを再開します。例えば:

cdc cli changefeed resume -c test-cf --pd=http://10.0.10.25:2379

失敗するこのDDLステートメントをスキップする場合は、changefeedのstart-tsをcheckpoint-ts(DDLステートメントが失敗するタイムスタンプ)に1を加えた値に設定します。たとえば、DDLステートメントが失敗するチェックポイント-tsが415241823337054209の場合、次のコマンドを実行して、このDDLステートメントをスキップします。

cdc cli changefeed update -c test-cf --pd=http://10.0.10.25:2379 --start-ts 415241823337054210
cdc cli changefeed resume -c test-cf --pd=http://10.0.10.25:2379
このページの内容