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 の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-uritime-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構成でprotocolcanal-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 へのレイテンシーがどんどん高くなるのはなぜですか?を参照してください。

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

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

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

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

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

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を使用して大規模トランザクションの増分データを復元することをお勧めします。詳細な操作は次のとおりです。

  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にtimestampすると、MySQL はデフォルト設定を使用します。複製後のテーブル スキーマは次のようになります。3 フィールドのデフォルト値は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-modetrueに設定すると、アップストリームからのINSERT / UPDATEステートメントがダウンストリームにレプリケートされた後にREPLACE INTOになるのはなぜですか?

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

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

レプリケーション ダウンストリームのシンクが 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 レプリケーションが停止したり、レプリケーションレイテンシーが著しく増加したり、データが失われたりといった不明なエラーが発生する可能性があります。

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

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

Playground
登録なしで TiDB の機能をワンストップでインタラクティブに体験できます。
製品
TiDB Dedicated
TiDB Serverless
TiDB
価格
PoC お問い合わせ
エコシステム
TiKV
TiFlash
OSS Insight
© 2024 PingCAP. All Rights Reserved.
Privacy Policy.