TiCDC よくある質問

このドキュメントでは、TiCDC を使用する際に遭遇する可能性のある一般的な質問を紹介します。

ノート:

このドキュメントでは、 cdc cliコマンドで指定されたサーバーアドレスは--server=http://127.0.0.1:8300です。コマンドを使用するときは、アドレスを実際の 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-ts0として指定した場合、レプリケーション タスクの開始時に、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 : このレプリケーション タスクの状態:
    • 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 タイムゾーンダウンストリーム タイム ゾーン
コンフィグレーション方法タイムゾーンのサポートを参照してくださいTiCDCサーバーの起動時に--tzパラメーターを使用して構成sink-uritime-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 --server=http://127.0.0.1:8300 --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 などの MQ シンクへの Canal 形式でのデータ変更の出力のみをサポートしています。

詳細については、 TiCDC 変更フィード構成を参照してください。

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

  • TiCDC レプリケーション タスクの状態を表示する方法を確認してください。

  • Kafka の次のパラメーターを調整します。

    • server.properties message.max.bytes値を1073741824 (1 GB) に増やします。
    • server.properties replica.fetch.max.bytes値を1073741824 (1 GB) に増やします。
    • consumer.propertiesfetch.message.max.bytes値を増やしてmessage.max.bytes値よりも大きくします。

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

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

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

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

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

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

タイプコード出力例ノート
ヌル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 はどのくらいの PDstorageを使用しますか?

TiCDC は PD で etcd を使用してメタデータを保存し、定期的に更新します。 etcd の MVCC と PD のデフォルトの圧縮の間の時間間隔は 1 時間であるため、TiCDC が使用する PDstorageの量は、この時間内に生成されたメタデータ バージョンの量に比例します。ただし、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 の可能性を回避することをお勧めします。分割を有効にするには、シンク 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 レプリケーション タスクを作成するときにsafe-modetrueに設定すると、アップストリームからの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-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 は TiKV 内のデータの履歴バージョンをスキャンして、一時停止中に生成された増分データ ログに追いつく必要があります。レプリケーション プロセスは、スキャンが完了した後にのみ続行されます。スキャン処理には数分から数十分かかる場合があります。

異なるリージョンにある 2 つの TiDB クラスター間でデータをレプリケートするには、TiCDC をデプロイする方法を教えてください。

ダウンストリームの TiDB クラスターに TiCDC をデプロイすることをお勧めします。アップストリームとダウンストリーム間のネットワークレイテンシーが大きい場合 (たとえば、100 ミリ秒を超える場合)、TiCDC がダウンストリームに対して SQL ステートメントを実行するときに生成されるレイテンシーは、MySQL 伝送プロトコルの問題により劇的に増加する可能性があります。これにより、システムのスループットが低下します。ただし、TiCDC をダウンストリームにデプロイすると、この問題を大幅に緩和できます。

DML および DDL ステートメントを実行する順序は?

実行順序は、DML -> DDL -> DML です。データ レプリケーション中に DML イベントがダウンストリームで実行されるときにテーブル スキーマが正しいことを確認するには、DDL ステートメントと DML ステートメントの実行順序を調整する必要があります。現在、TiCDC は単純なアプローチを採用しています。DDL ts の前にすべての DML ステートメントを最初にダウンストリームに複製し、次に DDL ステートメントを複製します。

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

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

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

この機能は現在サポートされていません。将来のリリースでサポートされる可能性があります。それまでに、TiCDC は TiKVリージョンにデータ変更ログをレプリケートする可能性があります。これは、スケーラブルな処理能力を意味します。

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

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

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

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