TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ
🚀
新しい TiDB Labs を探索し、ブラウザから直接分散型 SQL データベースを学び、RAG アプリを構築しましょう。

TiCDC よくある質問

+6
q
O
l
d

このドキュメントでは、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 以上である場合、すべての更新がレプリケートされています。レプリケーションの完了を確認するには、次の手順を実行します。

  1. アップストリーム 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         |
+------------------------------------+

  2. 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 がレプリケーションを続行するために必要なデータを削除しません。

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

  1. cdc cli changefeed query使用してレプリケーション タスクのエラー情報を照会し、できるだけ早くエラーを修正します。
  2. 値をgc-ttlに増やすと、エラーを修正するための時間が長くなり、エラーが修正された後にレプリケーション遅延がgc-ttl超えたためにレプリケーション タスクがfailedステータスにならないようになります。
  3. システムへの影響を評価した後、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 に複製する場合、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 を使用すると、 etcdserver: mvcc: database space exceededエラーが発生する可能性があります。これは主に、TiCDC が PD で etcd を使用してメタデータを保存するメカニズムに関連しています。

etcd は、データを保存するためにマルチバージョン同時実行制御 (MVCC) を使用し、PD のデフォルトの圧縮間隔は 1 時間です。つまり、etcd は圧縮前にすべてのデータの複数のバージョンを 1 時間保持します。

v6.0.0 より前のバージョンでは、TiCDC は PD の etcd を使用して、変更フィード内のすべてのテーブルのメタデータを保存および更新していました。そのため、TiCDC が使用する PDstorageスペースは、変更フィードによって複製されるテーブルの数に比例します。TiCDC が多数のテーブルを複製している場合、etcdstorageスペースがすぐにいっぱいになり、 etcdserver: mvcc: database space exceededエラーの可能性が高くなります。

このエラーが発生した場合は、 etcd メンテナンス スペース クォータを参照して etcdstorageスペースをクリーンアップしてください。

v6.0.0 以降、TiCDC はメタデータstorageメカニズムを最適化し、前述の理由によって発生する etcdstorageスペースの問題を効果的に回避します。TiCDC のバージョンが v6.0.0 より前の場合は、v6.0.0 以降のバージョンにアップグレードすることをお勧めします。

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

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

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

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

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

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

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 がこの文を下流のMySQL 5.7に複製すると、MySQL はデフォルト設定を使用します。複製後のテーブル スキーマは次のようになります。3 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値によって発生する互換性の問題に注意してください。

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 以降のバージョンでは、デフォルト値safe-modeがfalseに変更され、TiCDC はダウンストリームに重複データがあるかどうかを自動的に判断できます。重複データが検出されない場合、TiCDC はINSERTおよびUPDATEステートメントを変換せずに直接複製します。重複データが検出されない場合、TiCDC はINSERTおよびUPDATEステートメントをREPLACE INTOステートメントに変換してから複製します。

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

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

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

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

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

  1. これらのテーブルに関連する TiCDC レプリケーション タスクを削除します。

  2. TiCDC の上流クラスターと下流クラスターでデータを個別に復元するには、 TiDB Lightning物理インポート モードまたはBRを使用します。

  3. 復元が完了し、上流クラスターと下流クラスター間のデータの整合性が検証されたら、上流バックアップのタイムスタンプ (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 は次の順序を採用しています。

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

TiCDC は DML 操作で生成された列を複製しますか?

生成された列には、仮想生成された列と保存された生成された列が含まれます。TiCDC は仮想生成された列を無視し、保存された生成された列のみをダウンストリームに複製します。ただし、ダウンストリームが MySQL または別の MySQL 互換データベース (Kafka またはその他のstorageサービスではない) である場合、保存された生成された列も無視されます。

注記：

保存された生成列を Kafka またはstorageサービスに複製し、それを MySQL に書き戻すと、 Error 3105 (HY000): The value specified for generated column 'xx' in table 'xxx' is not allowed発生する可能性があります。このエラーを回避するには、レプリケーションにオープンプロトコル使用します。このプロトコルの出力には列のビットフラグ含まれており、列が生成列であるかどうかを区別できます。

頻繁に発生するCDC:ErrMySQLDuplicateEntryCDCエラーを解決するにはどうすればよいですか?

TiCDC を使用してデータを TiDB または MySQL に複製する場合、アップストリームの SQL ステートメントが特定のパターンで実行されると、次のエラーが発生する可能性があります。

CDC:ErrMySQLDuplicateEntryCDC

エラーの原因: TiDB は、同じトランザクション内の同じ行に対するDELETE + INSERT操作を 1 つのUPDATE行の変更に結合します。TiCDC がこれらの変更を更新としてダウンストリームに複製すると、一意のキー値を交換しようとするUPDATE操作によって競合が発生する可能性があります。

次の表を例に挙げます。

CREATE TABLE data_table (
    id BIGINT(20) NOT NULL PRIMARY KEY,
    value BINARY(16) NOT NULL,
    UNIQUE KEY value_index (value)
) CHARSET=utf8mb4 COLLATE=utf8mb4_bin;

アップストリームがテーブル内の 2 つの行のvalueのフィールドを交換しようとする場合:

DELETE FROM data_table WHERE id = 1;
DELETE FROM data_table WHERE id = 2;
INSERT INTO data_table (id, value) VALUES (1, 'v3');
INSERT INTO data_table (id, value) VALUES (2, 'v1');

TiDB は 2 つのUPDATE行の変更を生成するため、TiCDC はそれを 2 つのUPDATEステートメントに変換し、ダウンストリームにレプリケーションします。

UPDATE data_table SET value = 'v3' WHERE id = 1;
UPDATE data_table SET value = 'v1' WHERE id = 2;

2 番目UPDATEステートメントを実行するときにダウンストリーム テーブルにまだv1が含まれている場合、 value列の一意キー制約に違反し、 CDC:ErrMySQLDuplicateEntryCDCエラーが発生します。

CDC:ErrMySQLDuplicateEntryCDCエラーが頻繁に発生する場合は、 sink-uri構成でsafe-mode=trueパラメータを設定することで TiCDC セーフ モードを有効にすることができます。

mysql://user:password@host:port/?safe-mode=true

セーフ モードでは、TiCDC はUPDATE操作をDELETE + REPLACE INTOに分割して実行し、一意のキーの競合エラーを回避します。

TiCDC FAQs最終更新日 3/24/2025, 8:34:15 AM: ticdc: add duplicate entry faq (#20550) (#20631)

このページは役に立ちましたか？

フィードバック募集中！

TiDBドキュメント向上のためご協力をお願いします。

アンケートへ