重要

古いバージョンの TiDB データベース (TiDB {{ curdocVersion }}) のドキュメントを表示しています。TiDBデータベースの最新の安定バージョンを使用することをお勧めします。

重要

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

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

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

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

TiCDCでタスクを作成するときに`start-ts`を選択するにはどうすればよいですか？

レプリケーションタスクのstart-tsは、アップストリームTiDBクラスタのタイムスタンプOracle（TSO）に対応します。 TiCDCは、レプリケーションタスクでこのTSOにデータを要求します。したがって、レプリケーションタスクのstart-tsは、次の要件を満たす必要があります。

start-tsの値は、現在のTiDBクラスタのtikv_gc_safe_pointの値よりも大きくなります。そうしないと、タスクの作成時にエラーが発生します。
タスクを開始する前に、ダウンストリームにstart-tsより前のすべてのデータがあることを確認してください。メッセージキューへのデータの複製などのシナリオで、アップストリームとダウンストリーム間のデータの整合性が必要ない場合は、アプリケーションのニーズに応じてこの要件を緩和できます。

start-tsを指定しない場合、またはstart-tsを0として指定する場合、レプリケーションタスクの開始時に、TiCDCは現在のTSOを取得し、このTSOからタスクを開始します。

TiCDCでタスクを作成すると、一部のテーブルを複製できないのはなぜですか？

cdc cli changefeed createを実行してレプリケーションタスクを作成すると、TiCDCはアップストリームテーブルがレプリケーションの制限を満たしているかどうかを確認します。一部のテーブルが制限を満たしていない場合は、不適格なテーブルのリストとともにsome tables are not eligible to replicateが返されます。 Yまたはyを選択してタスクの作成を続行でき、これらのテーブルのすべての更新はレプリケーション中に自動的に無視されます。 Yまたはy以外の入力を選択した場合、レプリケーションタスクは作成されません。

TiCDCレプリケーションタスクの状態を表示するにはどうすればよいですか？

TiCDCレプリケーションタスクのステータスを表示するには、 cdc cliを使用します。例えば：

cdc cli changefeed list --pd=http://10.0.10.25:2379

期待される出力は次のとおりです。

[{
    "id": "4e24dde6-53c1-40b6-badf-63620e4940dc",
    "summary": {
      "state": "normal",
      "tso": 417886179132964865,
      "checkpoint": "2020-07-07 16:07:44.881",
      "error": null
    }
}]

checkpoint ：TiCDCは、このタイムスタンプより前のすべてのデータをダウンストリームに複製しました。
state ：このレプリケーションタスクの状態：
- normal ：タスクは正常に実行されます。
- stopped ：タスクが手動で停止されたか、エラーが発生しました。
- removed ：タスクは削除されます。

ノート：
この機能はTiCDC4.0.3で導入されました。

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 --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-tsをstart-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バージョン、および最新バージョンではすでに解決されています。

TiCDC `gc-ttl`とは何ですか？

v4.0.0-rc.1以降、PDはサービスレベルのGCセーフポイントを設定する際に外部サービスをサポートします。どのサービスでも、GCセーフポイントを登録および更新できます。 PDは、このGCセーフポイントより後のKey-ValueデータがGCによってクリーンアップされないようにします。

レプリケーションタスクが利用できないか中断されている場合、この機能により、TiCDCによって消費されるデータがGCによってクリーンアップされることなくTiKVに保持されます。

TiCDCサーバーを起動するときに、 gc-ttlを構成することにより、GCセーフポイントの存続時間（TTL）期間を指定できます。 gc-ttlもできTiUPを使用して変更する。デフォルト値は24時間です。 TiCDCでは、この値は次のことを意味します。

TiCDCサービスが停止した後、GCセーフポイントがPDに保持される最大時間。
タスクが中断または手動で停止された後、レプリケーションタスクを一時停止できる最大時間。中断されたレプリケーションタスクの時間がgc-ttlで設定された値より長い場合、レプリケーションタスクはfailedステータスになり、再開できず、GCセーフポイントの進行に影響を与え続けることができません。

上記の2番目の動作は、TiCDCv4.0.13以降のバージョンで導入されています。目的は、TiCDCのレプリケーションタスクが長時間中断され、アップストリームTiKVクラスタのGCセーフポイントが長時間継続せず、古いデータバージョンが多すぎて、アップストリームクラスタのパフォーマンスに影響を与えるのを防ぐことです。

ノート：
一部のシナリオでは、たとえば、 Dumpling/ BRを使用した完全レプリケーションの後に増分レプリケーションにTiCDCを使用する場合、デフォルトの24時間のgc-ttlでは不十分な場合があります。 TiCDCサーバーを起動するときは、 gc-ttlに適切な値を指定する必要があります。

TiCDCガベージコレクション（GC）セーフポイントの完全な動作は何ですか？

TiCDCサービスの開始後にレプリケーションタスクが開始された場合、TiCDC所有者は、すべてのレプリケーションタスクの中で最小値のcheckpoint-tsでPDサービスGCセーフポイントを更新します。サービスGCセーフポイントは、TiCDCがその時点およびそれ以降に生成されたデータを削除しないことを保証します。レプリケーションタスクが中断された場合、または手動で停止された場合、このタスクのcheckpoint-tsは変更されません。一方、PDの対応するサービスGCセーフポイントも更新されません。

レプリケーションタスクがgc-ttlで指定された時間より長く中断された場合、レプリケーションタスクはfailedステータスになり、再開できません。 PDに対応するサービスGCセーフポイントは続行されます。

TiCDCがサービスGCセーフポイントに設定するTime-To-Live（TTL）は24時間です。つまり、TiCDCサービスが中断されてから24時間以内に回復できる場合、GCメカニズムはデータを削除しません。

レプリケーションタスクを作成するとき、またはデータを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-uriのtime-zoneパラメーターを使用してダウンストリームのMySQLタイムゾーンを指定する必要があります。最初に、MySQLで使用されるタイムゾーンをクエリできます。

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

show variables like '%time_zone%';

+------------------+--------+
| Variable_name    | Value  |
+------------------+--------+
| system_time_zone | CST    |
| time_zone        | SYSTEM |
+------------------+--------+

レプリケーションタスクを作成して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は通常中国標準時の略です。

TiCDCタイムゾーンとアップストリーム/ダウンストリームデータベースのタイムゾーンの関係を理解するにはどうすればよいですか？

	上流のタイムゾーン	TiCDCタイムゾーン	下流のタイムゾーン
Configuration / コンフィグレーション方法	タイムゾーンのサポートを参照	TiCDCサーバーの起動時に`--tz`パラメーターを使用して構成	`sink-uri`の`time-zone`パラメータを使用して設定
説明	アップストリームTiDBのタイムゾーン。タイムスタンプタイプのDML操作とタイムスタンプタイプの列に関連するDDL操作に影響します。	TiCDCは、アップストリームTiDBのタイムゾーンがTiCDCタイムゾーン構成と同じであると想定し、タイムスタンプ列に対して関連する操作を実行します。	ダウンストリームMySQLは、ダウンストリームタイムゾーン設定に従って、DMLおよびDDL操作のタイムスタンプを処理します。

ノート：
TiCDCサーバーのタイムゾーンを設定するときは注意してください。このタイムゾーンはタイムタイプの変換に使用されるためです。アップストリームタイムゾーン、TiCDCタイムゾーン、およびダウンストリームタイムゾーンの一貫性を保ちます。 TiCDCサーバーは、次の優先順位でタイムゾーンを選択します。
TiCDCは、最初に--tzを使用して指定されたタイムゾーンを使用します。
--tzが使用できない場合、TiCDCはTZ環境変数を使用して設定されたタイムゾーンを読み取ろうとします。
TZの環境変数が使用できない場合、TiCDCはマシンのデフォルトのタイムゾーンを使用します。

`--config`で構成ファイルを指定せずにレプリケーションタスクを作成した場合のTiCDCのデフォルトの動作は何ですか？

-configパラメータを指定せずにcdc cli changefeed createコマンドを使用すると、TiCDCは次のデフォルトの動作でレプリケーションタスクを作成します。

システムテーブルを除くすべてのテーブルを複製します
古い値機能を有効にします
有効なインデックスを含まないテーブルの複製をスキップします

TiCDCのアップグレードによって引き起こされる構成ファイルの非互換性の問題をどのように処理しますか？

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

TiCDCは、Canal形式でのデータ変更の出力をサポートしていますか？

はい。 Canal出力を有効にするには、 --sink-uriパラメーターでプロトコルをcanalとして指定します。例えば：

cdc cli changefeed create --pd=http://10.0.10.25:2379 --sink-uri="kafka://127.0.0.1:9092/cdc-test?kafka-version=2.4.0&protocol=canal" --config changefeed.toml

ノート：
この機能はTiCDC4.0.2で導入されました。
TiCDCは現在、KafkaやPulsarなどのMQシンクにのみCanal形式でデータ変更を出力することをサポートしています。

詳細については、レプリケーションタスクを作成するを参照してください。

TiCDCからKafkaまでのレイテンシーがますます高くなるのはなぜですか？

TiCDCレプリケーションタスクの状態を表示するにはどうすればよいですかを確認してください。
Kafkaの次のパラメータを調整します。
- message.max.bytesの値をserver.propertiesから1073741824 （1 GB）に増やします。
- replica.fetch.max.bytesの値をserver.propertiesから1073741824 （1 GB）に増やします。
- consumer.propertiesのfetch.message.max.bytesの値を増やして、 message.max.bytesの値より大きくします。

TiCDCがデータをKafkaに複製するとき、トランザクション内のすべての変更を1つのメッセージに書き込みますか？そうでない場合、それはどのような基準で変更を分割しますか？

いいえ。構成されたさまざまな配布戦略に従って、 row idは、 default 、およびtableを含むさまざまなベースで変更を分割しts 。

詳細については、レプリケーションタスク構成ファイルを参照してください。

TiCDCがKafkaにデータを複製するとき、TiDBの単一メッセージの最大サイズを制御できますか？

はい。 max-message-bytesパラメーターを設定して、毎回Kafkaブローカーに送信されるデータの最大サイズを制御できます（オプション、デフォルトでは10MB ）。 max-batch-sizeを設定して、各Kafkaメッセージの変更レコードの最大数を指定することもできます。現在、この設定は、Kafkaのprotocolがopen-protocol （オプション、デフォルトでは16 ）の場合にのみ有効になります。

TiCDCがデータをKafkaに複製するとき、メッセージには複数のタイプのデータ変更が含まれていますか？

はい。 1つのメッセージに複数のupdateまたはdeleteが含まれる場合があり、 updateとdeleteが共存する場合があります。

TiCDCがデータをKafkaに複製する場合、TiCDC Open Protocolの出力でタイムスタンプ、テーブル名、およびスキーマ名を表示するにはどうすればよいですか？

この情報は、Kafkaメッセージのキーに含まれています。例えば：

{
    "ts":<TS>,
    "scm":<Schema Name>,
    "tbl":<Table Name>,
    "t":1
}

詳細については、 TiCDCOpenProtocolイベント形式を参照してください。

TiCDCがデータをKafkaに複製するとき、メッセージ内のデータ変更のタイムスタンプをどのように知ることができますか？

Unixタイムスタンプを取得するには、Kafkaメッセージのキーのtsを18ビット右に移動します。

TiCDC Open Protocolはどのように`null`を表しますか？

TiCDC Open Protocolでは、タイプコード6はnullを表します。

タイプ	コード	出力例	ノート
ヌル	6	`{"t":6,"v":null}`

詳細については、 TiCDCOpenProtocol列タイプコードを参照してください。

TiCDCタスクの`start-ts`タイムスタンプは、現在の時刻とはかなり異なります。このタスクの実行中に、レプリケーションが中断され、エラー`[CDC:ErrBufferReachLimit]`が発生します

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

TiCDC Open Protocolの行変更イベントが`INSERT`イベントなのか`UPDATE`イベントなのかはどうすればわかりますか？

Old Value機能が有効になっていない場合、TiCDCOpenProtocolの行変更イベントがINSERTイベントであるかUPDATEイベントであるかを判断できません。この機能が有効になっている場合は、含まれているフィールドによってイベントタイプを判別できます。

UPDATEイベントには"p"フィールドと"u"フィールドの両方が含まれます
INSERTイベントには"u"フィールドのみが含まれます
DELETEイベントには"d"フィールドのみが含まれます

詳細については、オープンプロトコル行変更イベント形式を参照してください。

TiCDCはどのくらいのPDストレージを使用しますか？

TiCDCはPDでetcdを使用して、メタデータを保存し、定期的に更新します。 etcdのMVCCとPDのデフォルトの圧縮の間の時間間隔は1時間であるため、TiCDCが使用するPDストレージの量は、この1時間以内に生成されるメタデータバージョンの量に比例します。ただし、v4.0.5、v4.0.6、およびv4.0.7では、TiCDCに頻繁な書き込みの問題があるため、1時間に1000個のテーブルが作成またはスケジュールされている場合、etcdストレージをすべて使用し、 etcdserver: mvcc: database space exceededのエラーを返します。。このエラーが発生した後、etcdストレージをクリーンアップする必要があります。詳細については、 etcdmaintainceスペースクォータを参照してください。クラスタをv4.0.9以降のバージョンにアップグレードすることをお勧めします。

TiCDCは大規模なトランザクションの複製をサポートしていますか？リスクはありますか？

TiCDCは、大規模なトランザクション（5 GBを超えるサイズ）を部分的にサポートします。さまざまなシナリオに応じて、次のリスクが存在する可能性があります。

TiCDCの内部処理能力が不十分な場合、レプリケーションタスクエラーErrBufferReachLimitが発生する可能性があります。
TiCDCの内部処理能力が不十分な場合、またはTiCDCのダウンストリームのスループット能力が不十分な場合、メモリ不足（OOM）が発生する可能性があります。

上記のエラーが発生した場合は、BRを使用して大規模なトランザクションの増分データを復元することをお勧めします。詳細な操作は次のとおりです。

大規模なトランザクションのために終了したチェンジフィードのcheckpoint-tsを記録し、このTSOをBR増分バックアップの--lastbackuptsとして使用して、増分データバックアップを実行します。
インクリメンタルデータをバックアップした後、BRログ出力に["Full backup Failed summary : total backup ranges: 0, total success: 0, total failed: 0"] [BackupTS=421758868510212097]に類似したログレコードを見つけることができます。このログにBackupTSを記録します。
インクリメンタルデータを復元する。
新しいチェンジフィードを作成し、 BackupTSからレプリケーションタスクを開始します。
古いチェンジフィードを削除します。

チェンジフィードのダウンストリームがMySQLと同様のデータベースであり、TiCDCが時間のかかるDDLステートメントを実行する場合、他のすべてのチェンジフィードはブロックされます。問題をどのように処理する必要がありますか？

時間のかかるDDLステートメントを含むチェンジフィードの実行を一時停止します。次に、他のチェンジフィードがブロックされなくなったことがわかります。
TiCDCログでapply jobのフィールドを検索し、時間のかかるDDLステートメントのstart-tsを確認します。
ダウンストリームでDDLステートメントを手動で実行します。実行終了後、以下の操作を行ってください。
チェンジフィード構成を変更し、上記のstart-tsをignore-txn-start-ts構成項目に追加します。
一時停止したチェンジフィードを再開します。

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使用し、古い値の機能が無効になっていると、このエラーが報告されます。

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

チェンジフィード構成ファイルの値enable-old-valueをtrueに設定します。
cdc cli changefeed pauseを実行して、レプリケーションタスクを一時停止します。
```
cdc cli changefeed pause -c test-cf --pd=http://10.0.10.25:2379
```

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

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を使用してチェンジフィードを作成すると、エラーが報告されます。

解決策： 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レプリケーションタスクを作成すると、 `enable-old-value`が`true`に設定されますが、アップストリームからの`INSERT` / `UPDATE`ステートメントは、ダウンストリームにレプリケートされた後、 `REPLACE INTO`になります。

TiCDCでチェンジフィードが作成されると、 safe-modeの設定はデフォルトでtrueになり、アップストリームのINSERTステートメントに対して実行するREPLACE INTOステートメントが生成されUPDATE 。

現在、ユーザーはsafe-modeの設定を変更できないため、この問題は現在解決策がありません。

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

DDLステートメントをダウンストリームのMySQL5.7に複製する場合、時間タイプフィールドのデフォルト値に一貫性がありません。私に何ができる？

create table test (id int primary key, ts timestamp)ステートメントがアップストリームTiDBで実行されると仮定します。 TiCDCがこのステートメントをダウンストリームのMySQL5.7に複製する場合、MySQLはデフォルト構成を使用します。レプリケーション後のテーブルスキーマは次のとおりです。 timestampフィールドのデフォルト値はCURRENT_TIMESTAMPになります：

mysql root@127.0.0.1:test> show create table test;
+-------+----------------------------------------------------------------------------------+
| Table | Create Table                                                                     |
+-------+----------------------------------------------------------------------------------+
| test  | CREATE TABLE `test` (                                                            |
|       |   `id` int(11) NOT NULL,                                                         |
|       |   `ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, |
|       |   PRIMARY KEY (`id`)                                                             |
|       | ) ENGINE=InnoDB DEFAULT CHARSET=latin1                                           |
+-------+----------------------------------------------------------------------------------+
1 row in set

結果から、レプリケーションの前後のテーブルスキーマに一貫性がないことがわかります。これは、TiDBのデフォルト値explicit_defaults_for_timestampがMySQLのデフォルト値と異なるためです。詳細については、 MySQLの互換性を参照してください。

v5.0.1またはv4.0.13以降、MySQLへのレプリケーションごとに、TiCDCは自動的にexplicit_defaults_for_timestamp = ONを設定して、時間タイプがアップストリームとダウンストリームの間で一貫していることを確認します。 v5.0.1またはv4.0.13より前のバージョンでは、TiCDCを使用して時間タイプデータを複製するときに、一貫性のないexplicit_defaults_for_timestamp値によって引き起こされる互換性の問題に注意してください。

ダウンストリームのレプリケーションのシンクがTiDBまたはMySQLの場合、ダウンストリームデータベースのユーザーにはどのような権限が必要ですか？

シンクがTiDBまたはMySQLの場合、ダウンストリームデータベースのユーザーには次の権限が必要です。

Select
Index
Insert
Update
Delete
Create
Drop
Alter
Create View

recover tableをダウンストリームTiDBに複製する必要がある場合は、 Superの権限が必要です。