TiCDC の概要

TiCDCは、TiDB の増分データを複製するために使用されるツールです。具体的には、TiCDC は TiKV 変更ログをプルし、キャプチャされたデータを並べ替え、行ベースの増分データをダウンストリーム データベースにエクスポートします。

使用シナリオ

  • データベースのディザスター リカバリー: TiCDC を同種のデータベース間のディザスター リカバリーに使用して、災害イベント後のプライマリ データベースとセカンダリ データベースの最終的なデータ整合性を確保できます。この機能は、TiDB のプライマリ クラスタとセカンダリ クラスタでのみ機能します。
  • データ統合: TiCDC は、他のシステムが TiCDC からのデータ変更をサブスクライブできるようにするTiCDC Canal- JSON プロトコルを提供します。このように、TiCDC は、監視、キャッシング、グローバル インデックス作成、データ分析、異種データベース間のプライマリ/セカンダリ レプリケーションなど、さまざまなシナリオにデータ ソースを提供します。

TiCDCアーキテクチャ

TiCDC が実行されている場合、PD で etcd を介して高可用性を実現するステートレス ノードです。 TiCDC クラスターは、複数のレプリケーション タスクの作成をサポートして、複数の異なるダウンストリーム プラットフォームにデータをレプリケートします。

TiCDC のアーキテクチャを次の図に示します。

TiCDC architecture

システムの役割

  • TiKV CDC コンポーネント: キー値 (KV) 変更ログのみを出力します。

    • 内部ロジックで KV 変更ログを収集します。
    • KV 変更ログを出力するためのインターフェイスを提供します。送信されるデータには、リアルタイム変更ログとインクリメンタル スキャン変更ログが含まれます。
  • capture : TiCDC の動作プロセス。複数のcapturesは、KV 変更ログをレプリケートする TiCDC クラスターを形成します。

    • captureごとに KV 変更ログの一部を取得します。
    • プルされた KV 変更ログを並べ替えます。
    • TiCDC オープン プロトコルに基づいて、トランザクションをダウンストリームに復元するか、ログを出力します。

レプリケーション機能

このセクションでは、TiCDC のレプリケーション機能について紹介します。

シンクサポート

現在、TiCDC シンク コンポーネントは、次のダウンストリーム プラットフォームへのデータのレプリケートをサポートしています。

  • MySQL プロトコルと互換性のあるデータベース。シンク コンポーネントは、最終的な一貫性のサポートを提供します。
  • TiCDC Open Protocol に基づく Kafka。シンク コンポーネントは、行レベルの順序、最終的な一貫性、または厳密なトランザクションの一貫性を保証します。

レプリケーションの順序と一貫性を確保する

複製順序

  • すべての DDL または DML ステートメントについて、TiCDC はそれらを少なくとも 1 回出力します。

  • TiKV または TiCDC クラスターで障害が発生すると、TiCDC は同じ DDL/DML ステートメントを繰り返し送信する場合があります。重複する DDL/DML ステートメントの場合:

    • MySQL シンクは、DDL ステートメントを繰り返し実行できます。 truncate tableなど、ダウンストリームで繰り返し実行できる DDL ステートメントの場合、ステートメントは正常に実行されます。 create tableのように繰り返し実行できないものについては、実行は失敗し、TiCDC はエラーを無視してレプリケーションを続行します。
    • Kafka シンクはメッセージを繰り返し送信しますが、メッセージの重複はResolved Tsの制約には影響しません。ユーザーは、Kafka コンシューマーからの重複メッセージをフィルタリングできます。

レプリケーションの一貫性

  • MySQL シンク

    • TiCDC は単一テーブル トランザクションを分割せず、単一テーブル トランザクションの原子性を保証します。

    • TiCDC は、ダウンストリーム トランザクションの実行順序がアップストリーム トランザクションの実行順序と同じであることを保証しません

    • TiCDC はクロステーブル トランザクションをテーブル単位で分割し、クロステーブル トランザクションの原子性を保証しません

    • TiCDC は、単一行の更新の順序がアップストリームの順序と一致することを保証します。

    ノート:

    v6.2 以降、シンク uri パラメータtransaction-atomicityを使用して、単一テーブル トランザクションを分割するかどうかを制御できます。単一テーブル トランザクションを分割すると、大規模なトランザクションをレプリケートする際のレイテンシーとメモリ消費を大幅に削減できます。

  • カフカシンク

    • TiCDC は、データ配布のためのさまざまな戦略を提供します。テーブル、主キー、またはタイムスタンプに基づいて、さまざまな Kafka パーティションにデータを分散できます。
    • さまざまな分散戦略の場合、さまざまなコンシューマーの実装によって、行レベルの一貫性、結果の一貫性、テーブル間のトランザクションの一貫性など、さまざまなレベルの一貫性を実現できます。
    • TiCDC には Kafka コンシューマーの実装はありませんが、提供されるのはTiCDC オープン プロトコルのみです。このプロトコルに従って Kafka コンシューマを実装できます。

制限

TiCDC を使用する場合、いくつかの制限があります。

有効なインデックスの要件

TiCDC は、少なくとも 1 つの有効なインデックスを持つテーブルのみを複製します。有効なインデックスは次のように定義されます。

  • 主キー ( PRIMARY KEY ) は有効なインデックスです。
  • 次の条件を同時に満たす一意のインデックス ( UNIQUE INDEX ) は、有効なインデックスです。
    • インデックスのすべての列は、null 非許容 ( NOT NULL ) として明示的に定義されています。
    • 索引には、仮想生成列 ( VIRTUAL GENERATED COLUMNS ) がありません。

v4.0.8 以降、TiCDC は、タスク構成を変更することにより、有効なインデックスなしでテーブルを複製することをサポートします。ただし、これにより、データの一貫性の保証がある程度損なわれます。詳細については、 有効なインデックスのないテーブルをレプリケートするを参照してください。

サポートされていないシナリオ

現在、次のシナリオはサポートされていません。

  • RawKV のみを使用する TiKV クラスター。
  • TiDB のDDL 操作CREATE SEQUENCESEQUENCE関数 。アップストリームの TiDB がSEQUENCEを使用する場合、TiCDC はアップストリームで実行されたSEQUENCEの DDL 操作/関数を無視します。ただし、 SEQUENCEの関数を使用する DML 操作は正しくレプリケートできます。

TiCDC は、アップストリームでの大規模なトランザクションのシナリオに対して部分的なサポートのみを提供します。詳細については、 FAQ: TiCDC は大規模なトランザクションの複製をサポートしていますか?リスクはありますか?を参照してください。

ノート:

v5.3.0 以降、TiCDC は循環レプリケーション機能をサポートしなくなりました。

TiCDC をインストールしてデプロイする

TiCDC を新しい TiDB クラスターと共にデプロイするか、TiCDC コンポーネントを既存の TiDB クラスターに追加することができます。詳細については、 TiCDC をデプロイを参照してください。

TiCDCクラスタとレプリケーション タスクの管理

現在、 cdc cliのツールを使用して、TiCDC クラスターのステータスとデータ レプリケーション タスクを管理できます。詳細については、次を参照してください。

TiCDC オープン プロトコル

TiCDC Open Protocol は、監視、キャッシング、フルテキスト インデックス作成、分析エンジン、および異なるデータベース間のプライマリ/セカンダリ レプリケーションのためのデータ ソースを提供する、行レベルのデータ変更通知プロトコルです。 TiCDC は TiCDC Open Protocol に準拠し、TiDB のデータ変更を MQ (Message Queue) などのサードパーティのデータ媒体に複製します。詳細については、 TiCDC オープン プロトコルを参照してください。

互換性に関する注意事項

TiCDC v5.0.0-rc cdc cliツールを使用して v4.0.x クラスターを操作することによって引き起こされる非互換性の問題

TiCDC v5.0.0-rc のcdc cliツールを使用して v4.0.x の TiCDC クラスターを操作すると、次の異常な状況が発生する場合があります。

  • TiCDC クラスターが v4.0.8 以前のバージョンである場合、v5.0.0-rc cdc cliツールを使用してレプリケーション タスクを作成すると、クラスターの異常が発生し、レプリケーション タスクがスタックする可能性があります。

  • TiCDC クラスターが v4.0.9 以降のバージョンの場合、v5.0.0-rc cdc cliツールを使用してレプリケーション タスクを作成すると、古い値と統合ソーター機能が予期せずデフォルトで有効になります。

解決策: TiCDC クラスターのバージョンに対応するcdcの実行可能ファイルを使用して、次の操作を実行します。

  1. v5.0.0-rc cdc cliツールを使用して作成された変更フィードを削除します。たとえば、 tiup cdc:v4.0.9 cli changefeed remove -c xxxx --pd=xxxxx --forceコマンドを実行します。
  2. レプリケーション タスクがスタックしている場合は、TiCDC クラスターを再起動します。たとえば、 tiup cluster restart <cluster_name> -R cdcコマンドを実行します。
  3. 変更フィードを再作成します。たとえば、 tiup cdc:v4.0.9 cli changefeed create --sink-uri=xxxx --pd=xxxコマンドを実行します。

ノート:

上記の問題は、 cdc cliが v5.0.0-rc の場合にのみ存在します。その他の v5.0.x cdc cliツールは、v4.0.x クラスターと互換性があります。

sort-dirdata-dirの互換性に関する注意事項

sort-dir構成は、TiCDC ソーターの一時ファイル ディレクトリを指定するために使用されます。その機能は、バージョンによって異なる場合があります。次の表は、バージョン間のsort-dirの互換性の変更を示しています。

バージョンsort-engine機能ノートおすすめ
v4.0.11 またはそれ以前の v4.0 バージョン、v5.0.0-rcこれは changefeed 設定項目で、 fileソーターとunifiedソーターの一時ファイル ディレクトリを指定します。これらのバージョンでは、 fileのソーターとunifiedのソーターは実験的機能であり、実稼働環境には推奨されません

複数のチェンジフィードがunifiedソーターをsort-engineとして使用する場合、実際の一時ファイル ディレクトリはいずれかのチェンジフィードのsort-dir構成である可能性があり、各 TiCDC ノードに使用されるディレクトリは異なる可能性があります。
本番環境でunifiedのソーターを使用することはお勧めしません。
v4.0.12、v4.0.13、v5.0.0、および v5.0.1changefeed またはcdc serverの設定項目です。デフォルトでは、changefeed のsort-dir構成は有効にならず、 cdc serversort-dir構成はデフォルトで/tmp/cdc_sortになります。実稼働環境ではcdc serverのみを構成することをお勧めします。

TiUP を使用して TiCDC をデプロイする場合は、最新の TiUP バージョンを使用し、TiCDCサーバー構成でsorter.sort-dirを設定することをお勧めします。

v4.0.13、v5.0.0、および v5.0.1 では、 unifiedソーターがデフォルトで有効になっています。クラスターをこれらのバージョンにアップグレードする場合は、TiCDCサーバー構成でsorter.sort-dirが正しく構成されていることを確認してください。
cdc serverコマンドライン パラメータ (または TiUP) を使用してsort-dirを構成する必要があります。
v4.0.14 以降の v4.0 バージョン、v5.0.3 以降の v5.0 バージョン、以降の TiDB バージョンsort-dirは非推奨です。 data-dirを設定することをお勧めします。data-dirは、最新バージョンの TiUP を使用して構成できます。これらの TiDB バージョンでは、デフォルトでunifiedのソーターが有効になっています。クラスターをアップグレードするときは、 data-dirが正しく構成されていることを確認してください。それ以外の場合、一時ファイル ディレクトリとしてデフォルトで/tmp/cdc_dataが使用されます。

ディレクトリが配置されているデバイスのストレージ容量が不足している場合、ハードディスク容量が不足する問題が発生する可能性があります。この状況では、changefeed の以前のsort-dirの構成は無効になります。
cdc serverコマンドライン パラメータ (または TiUP) を使用してdata-dirを構成する必要があります。

一時テーブルとの互換性

v5.3.0 以降、TiCDC はグローバル一時テーブルをサポートしています。 v5.3.0 より前のバージョンの TiCDC を使用してグローバル一時テーブルをダウンストリームに複製すると、テーブル定義エラーが発生します。

アップストリーム クラスターにグローバル一時テーブルが含まれている場合、ダウンストリーム TiDB クラスターは v5.3.0 以降のバージョンであると予想されます。そうしないと、レプリケーション プロセス中にエラーが発生します。

TiCDC の FAQ とトラブルシューティング

エコシステム
TiDB
TiKV
TiSpark
Chaos Mesh
© 2022 PingCAP. All Rights Reserved.