重要

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

TiCDC よくある質問

このドキュメントでは、TiCDC の使用時に発生する可能性のある一般的な質問について説明します。

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

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

レプリケーションタスクのstart-ts 、上流の TiDB クラスターの Timestamp 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 --server=http://127.0.0.1:8300

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

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

checkpoint : TiCDC はこのタイムスタンプより前のすべてのデータをダウンストリームに複製しました。
state : このレプリケーションタスクの状態。各状態とその意味の詳細については、チェンジフィードの状態参照してください。

注記：
この機能は TiCDC 4.0.3 で導入されました。

アップストリームが更新を停止した後、TiCDC がすべての更新を複製したかどうかを確認するにはどうすればよいですか?

アップストリーム TiDB クラスターの更新が停止したら、アップストリーム TiDB クラスターの最新のTSOのタイムスタンプと TiCDC のレプリケーションの進行状況を比較して、レプリケーションが完了したかどうかを確認できます。TiCDC のレプリケーション進行状況のタイムスタンプがアップストリーム TiDB クラスターの TSO 以上である場合、すべての更新がレプリケートされています。レプリケーションの完了を確認するには、次の手順を実行します。

アップストリーム TiDB クラスターから最新の TSO タイムスタンプを取得します。
注記：
現在の時刻を返すNOW()ような関数を使用する代わりに、 TIDB_CURRENT_TSO()関数を使用して現在の TSO を取得します。
次の例では、 TIDB_PARSE_TSO()使用して TSO を読み取り可能な時間形式に変換し、さらに比較します。
```
BEGIN;
SELECT TIDB_PARSE_TSO(TIDB_CURRENT_TSO());
ROLLBACK;
```
出力は次のようになります。
```
+------------------------------------+
| TIDB_PARSE_TSO(TIDB_CURRENT_TSO()) |
+------------------------------------+
| 2024-11-12 20:35:34.848000         |
+------------------------------------+
```
TiCDC でレプリケーションの進行状況を取得します。
次のいずれかの方法を使用して、TiCDC でレプリケーションの進行状況を確認できます。
- 方法 1 : 変更フィードのチェックポイントを照会します (推奨)。
  すべてのレプリケーションタスクのチェックポイントを表示するには、 TiCDC コマンドラインツール cdc cliを使用します。
```
cdc cli changefeed list --server=http://127.0.0.1:8300
```
  出力は次のようになります。
```
[
  {
    "id": "syncpoint",
    "namespace": "default",
    "summary": {
      "state": "normal",
      "tso": 453880043653562372,
      "checkpoint": "2024-11-12 20:36:01.447",
      "error": null
    }
  }
]
```
  出力の"checkpoint": "2024-11-12 20:36:01.447"は、TiCDC がこの時間より前にすべてのアップストリーム TiDB 変更をレプリケートしたことを示します。このタイムスタンプが、手順 1 で取得したアップストリーム TiDB クラスターの TSO 以上である場合、すべての更新がダウンストリームにレプリケートされています。
- 方法 2 : ダウンストリーム TiDB から Syncpoint をクエリします。
  ダウンストリームが TiDB クラスターであり、 TiCDC 同期ポイント機能が有効になっている場合は、ダウンストリーム TiDB の Syncpoint を照会することでレプリケーションの進行状況を取得できます。
  注記：
  同期ポイントの更新間隔は、 sync-point-interval構成項目によって制御されます。最新のレプリケーションの進行状況を取得するには、方法 1 を使用します。
  下流TiDBで次のSQL文を実行して、上流TSO（ primary_ts ）と下流TSO（ secondary_ts ）を取得します。
```
SELECT * FROM tidb_cdc.syncpoint_v1;
```
  出力は次のようになります。
```
+------------------+------------+--------------------+--------------------+---------------------+
| ticdc_cluster_id | changefeed | primary_ts         | secondary_ts       | created_at          |
+------------------+------------+--------------------+--------------------+---------------------+
| default          | syncpoint  | 453879870259200000 | 453879870545461257 | 2024-11-12 20:25:01 |
| default          | syncpoint  | 453879948902400000 | 453879949214351361 | 2024-11-12 20:30:01 |
| default          | syncpoint  | 453880027545600000 | 453880027751907329 | 2024-11-12 20:35:00 |
+------------------+------------+--------------------+--------------------+---------------------+
```
  出力では、各行は、上流の TiDB スナップショットprimary_tsが下流の TiDB スナップショットsecondary_tsと一致していることを示しています。
  レプリケーションの進行状況を表示するには、最新のprimary_ts読み取り可能な時間形式に変換します。
```
SELECT TIDB_PARSE_TSO(453880027545600000);
```
  出力は次のようになります。
```
+------------------------------------+
| TIDB_PARSE_TSO(453880027545600000) |
+------------------------------------+
| 2024-11-12 20:35:00                |
+------------------------------------+
```
  最新のprimary_tsに対応する時間が、手順 1 で取得した上流 TiDB クラスターの TSO 以上である場合、TiCDC はすべての更新を下流に複製しています。

TiCDC の`gc-ttl`とは何ですか?

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

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

TiCDCサーバーを起動するときに、 gc-ttl設定して GC セーフポイントの Time To Live (TTL) 期間を指定できます。 TiUPを使用して変更する gc-ttlも指定できます。デフォルト値は 24 時間です。TiCDC では、この値は次の意味を持ちます。

TiCDC サービスが停止された後、GC セーフポイントが PD に保持される最大時間。
TiKV の GC が TiCDC の GC セーフポイントによってブロックされている場合、 gc-ttl TiCDC レプリケーションタスクの最大レプリケーション遅延を示します。レプリケーションタスクの遅延がgc-ttlで設定された値を超えると、レプリケーションタスクはfailed状態になり、 ErrGCTTLExceededエラーが報告されます。回復できず、GC セーフポイントの進行をブロックしなくなります。

上記の 2 番目の動作は、TiCDC v4.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 メカニズムは TiCDC がレプリケーションを続行するために必要なデータを削除しません。

レプリケーションタスクが失敗した後に回復するにはどうすればよいですか?

cdc cli changefeed query使用してレプリケーションタスクのエラー情報を照会し、できるだけ早くエラーを修正します。
値をgc-ttlに増やすと、エラーを修正するための時間が長くなり、エラーが修正された後にレプリケーション遅延がgc-ttl超えたためにレプリケーションタスクがfailedステータスにならないようになります。
システムへの影響を評価した後、TiDB の値をtidb_gc_life_time増やして GC をブロックし、データを保持して、エラーが修正された後に GC によるデータのクリーニングによってレプリケーションタスクがfailedステータスにならないようにします。

TiCDC タイムゾーンと上流/下流データベースのタイムゾーンの関係を理解するにはどうすればよいでしょうか?

	上流タイムゾーン	TiCDC タイムゾーン	下流タイムゾーン
コンフィグレーション方法	タイムゾーンのサポート参照	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 は Canal プロトコルでのデータ変更の出力をサポートしていますか?

はい。Canal プロトコルの場合、TiCDC は JSON 出力形式のみをサポートしており、protobuf 形式はまだ正式にサポートされていないことに注意してください。Canal 出力を有効にするには、 --sink-uri構成でprotocol canal-jsonに指定します。例:

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

注記：
この機能は TiCDC 4.0.2 で導入されました。
TiCDC は現在、Kafka などの MQ シンクにのみ、Canal-JSON 形式でのデータ変更の出力をサポートしています。

詳細についてはTiCDC チェンジフィード構成を参照してください。

TiCDC から Kafka へのレイテンシーがどんどん高くなるのはなぜですか?

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

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

protocol avroまたはcanal-jsonに設定すると、行の変更ごとにメッセージが送信されます。1 つの Kafka メッセージには 1 つの行の変更のみが含まれ、通常は Kafka の制限を超えることはありません。したがって、1 つのメッセージのサイズを制限する必要はありません。1 つの Kafka メッセージのサイズが Kafka の制限を超える場合は、 TiCDC から Kafka へのレイテンシーがどんどん高くなるのはなぜですか?を参照してください。

protocol open-protocolに設定すると、メッセージはバッチで送信されます。そのため、1 つの Kafka メッセージは大きすぎる可能性があります。この状況を回避するには、 max-message-bytesパラメータを設定して、Kafka ブローカーに毎回送信されるデータの最大サイズを制御できます (オプション、デフォルトは10MB )。また、 max-batch-sizeパラメータを設定して (オプション、デフォルトは16 )、各 Kafka メッセージの変更レコードの最大数を指定することもできます。

トランザクションで行を複数回変更した場合、TiCDC は複数の行変更イベントを出力しますか?

いいえ。1 つのトランザクションで同じ行を複数回変更した場合、TiDB は最新の変更のみを TiKV に送信します。したがって、TiCDC は最新の変更の結果のみを取得できます。

TiCDC がデータを Kafka に複製する場合、メッセージには複数の種類のデータ変更が含まれますか?

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

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

情報は Kafka メッセージのキーに含まれます。例:

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

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

TiCDC がデータを Kafka に複製する場合、メッセージ内のデータ変更のタイムスタンプをどのように確認すればよいですか?

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

TiCDC オープンプロトコルは`null`どのように表現しますか?

TiCDC オープンプロトコルでは、タイプコード6はnull表します。

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

詳細についてはTiCDC オープンプロトコル列タイプコードを参照してください。

TiCDC オープンプロトコルの行変更イベントが`INSERT`イベントなのか`UPDATE`イベントなのかをどのように判断すればよいですか?

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

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

TiCDC はどのくらいの PDstorageを使用しますか?

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

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

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

プライマリ - セカンダリレプリケーションのレイテンシーが大幅に増加する可能性があります。
TiCDC の内部処理能力が不足すると、レプリケーションタスクエラーErrBufferReachLimitが発生する可能性があります。
TiCDC の内部処理能力が不足している場合、または TiCDC のダウンストリームのスループット能力が不足している場合、メモリ不足 (OOM) が発生する可能性があります。

v6.2 以降、TiCDC は単一テーブルトランザクションを複数のトランザクションに分割することをサポートしています。これにより、大規模なトランザクションをレプリケートする際のレイテンシーとメモリ消費を大幅に削減できます。したがって、アプリケーションでトランザクションの原子性に対する要件が高くない場合は、レプリケーションのレイテンシーと OOM を回避するために、大規模なトランザクションの分割を有効にすることをお勧めします。分割を有効にするには、sink uri パラメータの値をtransaction-atomicityからnoneに設定します。

上記のエラーが引き続き発生する場合は、 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から開始します。
古い変更フィードを削除します。

TiCDC は、損失のある DDL 操作によって発生したデータの変更をダウンストリームに複製しますか?

非可逆 DDL とは、TiDB で実行されたときにデータの変更を引き起こす可能性がある DDL を指します。一般的な非可逆 DDL 操作には次のようなものがあります。

列の型を変更する（例：INT -> VARCHAR）
列の長さを変更する。例：VARCHAR(20) -> VARCHAR(10)
列の精度を変更する。例: DECIMAL(10, 3) -> DECIMAL(10, 2)
列の UNSIGNED または SIGNED 属性の変更 (例: INT UNSIGNED -> INT SIGNED)

TiDB v7.1.0 より前では、TiCDC は、古いデータと新しいデータが同一の DML イベントをダウンストリームに複製します。ダウンストリームが MySQL の場合、ダウンストリームが DDL ステートメントを受信して実行するまで、これらの DML イベントによってデータが変更されることはありません。ただし、ダウンストリームが Kafka またはクラウドstorageサービスの場合、TiCDC は冗長データの行をダウンストリームに書き込みます。

TiDB v7.1.0 以降、TiCDC はこれらの冗長な DML イベントを排除し、ダウンストリームに複製しなくなりました。

DDL ステートメントをダウンストリームMySQL 5.7に複製するときに、時間型フィールドのデフォルト値が一致しません。どうすればよいでしょうか?

上流の TiDB でcreate table test (id int primary key, ts timestamp)文が実行されたとします。TiCDC がこの文timestamp下流のMySQL 5.7に複製すると、MySQL はデフォルト設定を使用します。複製後のテーブルスキーマは次のようになります。3 フィールドのデフォルト値はCURRENT_TIMESTAMPになります。

mysql root@127.0.0.1:test> show create table test;
+-------+----------------------------------------------------------------------------------+
| Table | Create Table                                                                     |
+-------+----------------------------------------------------------------------------------+
| test  | CREATE TABLE `test` (                                                            |
|       |   `id` int 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値によって発生する互換性の問題に注意してください。

TiCDC レプリケーションタスクを作成するときに`safe-mode` `true`に設定すると、アップストリームからの`INSERT` / `UPDATE`ステートメントがダウンストリームにレプリケートされた後に`REPLACE INTO`になるのはなぜですか?

TiCDC は、すべてのデータが少なくとも 1 回は複製されることを保証します。ダウンストリームに重複データがあると、書き込み競合が発生します。この問題を回避するために、TiCDC はINSERTおよびUPDATEステートメントをREPLACE INTOステートメントに変換します。この動作はsafe-modeパラメータによって制御されます。

v6.1.3 より前のバージョンでは、 safe-modeデフォルトでtrueに設定され、 INSERTとUPDATEのステートメントはすべてREPLACE INTOステートメントに変換されます。v6.1.3 以降のバージョンでは、TiCDC はダウンストリームに重複データがあるかどうかを自動的に判断し、デフォルト値のsafe-modeはfalseに変更されます。重複データが検出されない場合、TiCDC はINSERTとUPDATEステートメントを変換せずに複製します。

TiCDC がディスクを使用するのはなぜですか? TiCDC はいつディスクに書き込みますか? TiCDC はレプリケーションパフォーマンスを向上させるためにメモリバッファーを使用しますか?

アップストリームの書き込みトラフィックがピーク時になると、ダウンストリームがすべてのデータをタイムリーに消費できず、データが蓄積される可能性があります。TiCDC は、蓄積されたデータを処理するためにディスクを使用します。TiCDC は通常の動作中にディスクにデータを書き込む必要があります。ただし、ディスクへの書き込みでは 100 ミリ秒以内のレイテンシーしか発生しないため、これは通常、レプリケーションスループットとレプリケーションレイテンシーのボトルネックにはなりません。TiCDC は、メモリを使用してディスクからのデータの読み取りを高速化し、レプリケーションパフォーマンスを向上させます。

TiDB Lightning物理インポートモードとアップストリームからのBR を使用してデータを復元した後、TiCDC を使用したレプリケーションが停止したり、停止したりするのはなぜですか?

現在、TiCDC はTiDB Lightning物理インポートモードおよびBRとまだ完全に互換性がありません。したがって、TiCDC によってレプリケートされるテーブルでは、 TiDB Lightning物理インポートモードとBR を使用しないでください。そうしないと、TiCDC レプリケーションが停止したり、レプリケーションレイテンシーが著しく増加したり、データが失われたりといった不明なエラーが発生する可能性があります。

TiCDC によってレプリケートされた一部のテーブルのデータを復元するためにTiDB Lightning物理インポートモードまたはBR を使用する必要がある場合は、次の手順を実行します。

これらのテーブルに関連する TiCDC レプリケーションタスクを削除します。
TiCDC の上流クラスターと下流クラスターでデータを個別に復元するには、 TiDB Lightning物理インポートモードまたはBR を使用します。
復元が完了し、上流クラスターと下流クラスター間のデータの整合性が検証されたら、上流バックアップのタイムスタンプ (TSO) をタスクのstart-tsとして、増分レプリケーション用の新しい TiCDC レプリケーションタスクを作成します。たとえば、上流クラスターのBRバックアップのスナップショットタイムスタンプが431434047157698561であると仮定すると、次のコマンドを使用して新しい TiCDC レプリケーションタスクを作成できます。
```
cdc cli changefeed create -c "upstream-to-downstream-some-tables" --start-ts=431434047157698561 --sink-uri="mysql://root@127.0.0.1:4000? time-zone="
```

変更フィードが一時停止から再開すると、レプリケーションのレイテンシーがどんどん長くなり、数分後にようやく正常に戻ります。なぜでしょうか?

変更フィードが再開されると、TiCDC は、一時停止中に生成された増分データログに追いつくために、TiKV 内のデータの履歴バージョンをスキャンする必要があります。レプリケーションプロセスは、スキャンが完了した後にのみ続行されます。スキャンプロセスには数分から数十分かかる場合があります。

異なるリージョンにある 2 つの TiDB クラスター間でデータを複製するには、TiCDC をどのようにデプロイすればよいですか?

v6.5.2 より前のバージョンの TiCDC の場合、ダウンストリーム TiDB クラスターに TiCDC をデプロイすることをお勧めします。アップストリームとダウンストリーム間のネットワークレイテンシーが高い場合 (たとえば、100 ミリ秒を超える場合)、MySQL 転送プロトコルの問題により、TiCDC がダウンストリームに対して SQL ステートメントを実行するときに発生するレイテンシーが大幅に増加する可能性があります。これにより、システムスループットが低下します。ただし、ダウンストリームに TiCDC をデプロイすると、この問題が大幅に軽減されます。最適化後、TiCDC v6.5.2 以降では、アップストリーム TiDB クラスターに TiCDC をデプロイすることをお勧めします。

DML および DDL ステートメントの実行順序は何ですか?

現在、TiCDC は次の順序を採用しています。

TiCDC は、DDL commitTSまで、DDL ステートメントの影響を受けるテーブルのレプリケーションの進行をブロックします。これにより、DDL commitTSより前に実行された DML ステートメントがダウンストリームに正常にレプリケートされることが保証されます。
TiCDC は DDL ステートメントのレプリケーションを続行します。複数の DDL ステートメントがある場合、TiCDC はそれらを順番にレプリケートします。
DDL ステートメントがダウンストリームで実行された後、TiCDC は DDL commitTSの後に実行された DML ステートメントのレプリケーションを続行します。

アップストリームデータとダウンストリームデータが一貫しているかどうかをどのように確認すればよいですか?

ダウンストリームが TiDB クラスターまたは MySQL インスタンスの場合は、同期差分インスペクター使用してデータを比較することをお勧めします。

単一テーブルのレプリケーションは、単一の TiCDC ノードでのみ実行できます。複数の TiCDC ノードを使用して複数のテーブルのデータをレプリケートすることは可能ですか?

v7.1.0 以降、TiCDC は、TiKV リージョンの粒度でデータ変更ログをレプリケートする MQ シンクをサポートしています。これにより、スケーラブルな処理能力が実現され、TiCDC は多数のリージョンで単一のテーブルをレプリケートできます。この機能を有効にするには、 TiCDC 構成ファイルで次のパラメータを設定します。

[scheduler]
enable-table-across-nodes = true

アップストリームに長時間実行されているコミットされていないトランザクションがある場合、TiCDC レプリケーションは停止しますか?

TiDB にはトランザクションタイムアウトメカニズムがあります。トランザクションがmax-txn-ttlより長い期間実行されると、TiDB はそれを強制的にロールバックします。TiCDC は、レプリケーションを続行する前にトランザクションがコミットされるのを待つため、レプリケーションの遅延が発生します。

TiDB Operatorによってデプロイされた TiCDC クラスターを`cdc cli`コマンドを使用して操作できないのはなぜですか?

これは、 TiDB Operatorによってデプロイされた TiCDC クラスターのデフォルトのポート番号が8301であるのに対し、 TiCDCサーバーに接続するためのcdc cliコマンドのデフォルトのポート番号が8300であるためです。 TiDB Operatorによってデプロイされた TiCDC クラスターをcdc cliコマンドを使用して操作する場合は、次のように--serverパラメータを明示的に指定する必要があります。

./cdc cli changefeed list --server "127.0.0.1:8301"
[
  {
    "id": "4k-table",
    "namespace": "default",
    "summary": {
      "state": "stopped",
      "tso": 441832628003799353,
      "checkpoint": "2023-05-30 22:41:57.910",
      "error": null
    }
  },
  {
    "id": "big-table",
    "namespace": "default",
    "summary": {
      "state": "normal",
      "tso": 441872834546892882,
      "checkpoint": "2023-06-01 17:18:13.700",
      "error": null
    }
  }
]