📣
TiDB Cloud Essential はパブリックプレビュー中です。このページは自動翻訳されたものです。原文はこちらからご覧ください。
TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

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 : タスクは削除されます。

ノート：

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

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

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

ノート：

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

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

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

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

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

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

アップストリーム タイム ゾーンTiCDC タイムゾーンダウンストリーム タイム ゾーン
Configuration / コンフィグレーション方法タイムゾーンのサポートを参照してくださいTiCDCサーバーの起動時に--tzパラメーターを使用して構成sink-uriのtime-zoneパラメータを使用して設定
説明タイムスタンプ型の DML 操作と、タイムスタンプ型の列に関連する DDL 操作に影響するアップストリーム TiDB のタイム ゾーン。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 出力を有効にするには、 --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

ノート：

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

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

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 Open Protocol イベント形式を参照してください。

TiCDC がデータを Kafka にレプリケートするとき、メッセージ内のデータ変更のタイムスタンプを知るにはどうすればよいですか?

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

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

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

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

詳細については、 TiCDC Open Protocol カラム タイプ コードを参照してください。

TiCDC Open Protocol の Row Changed Event がINSERTイベントなのかUPDATEイベントなのか、どうすればわかりますか?

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

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

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

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

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

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

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

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

v6.1.1 以降、TiCDC は単一テーブルのトランザクションを複数のトランザクションに分割することをサポートしています。これにより、大規模なトランザクションをレプリケートする際のレイテンシーとメモリ消費を大幅に削減できます。したがって、トランザクションのアトミシティに対する要件がアプリケーションにあまりない場合は、大きなトランザクションの分割を有効にして、レプリケーションのレイテンシーと OOM の可能性を回避することをお勧めします。分割を有効にするには、シンク 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. 古い変更フィードを削除します。

DDL ステートメントを下流のMySQL 5.7にレプリケートする場合、時間型フィールドのデフォルト値は矛盾しています。私に何ができる？

create table test (id int primary key, ts timestamp)ステートメントが上流の TiDB で実行されるとします。 TiCDC がこのステートメントをダウンストリームのMySQL 5.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の値が一致しないために発生する互換性の問題に注意してください。

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

TiCDC で changefeed が作成されると、 safe-mode設定のデフォルトはtrueになり、上流のINSERT / UPDATEステートメントに対して実行するREPLACE INTOステートメントが生成されます。

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

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

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

  • Select
  • Index
  • Insert
  • Update
  • Delete
  • Create
  • Drop
  • Alter
  • Create View

recover tableを下流の TiDB に複製する必要がある場合は、 Superの権限が必要です。

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

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

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

現在、TiCDC はまだTiDB Lightningおよび BR と完全に互換性がありません。したがって、TiCDC によって複製されたテーブルでTiDB Lightningおよび BR を使用することは避けてください。

変更フィードが一時停止から再開した後、そのレプリケーションレイテンシーはますます高くなり、数分後にのみ通常に戻ります。なんで？

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

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