TiCDCの概要
TiCDCは、TiDBの増分データを複製するために使用されるツールです。具体的には、TiCDCはTiKV変更ログをプルし、キャプチャされたデータを並べ替え、行ベースの増分データをダウンストリームデータベースにエクスポートします。
使用シナリオ
- データベースのディザスタリカバリ：TiCDCを同種データベース間のディザスタリカバリに使用して、ディザスタイベント後のプライマリデータベースとセカンダリデータベースの最終的なデータの一貫性を確保できます。この関数は、TiDBプライマリおよびセカンダリクラスターでのみ機能します。
- データ統合：TiCDCはTiCDC運河-JSONプロトコルを提供します。これにより、他のシステムがTiCDCからのデータ変更をサブスクライブできます。このように、TiCDCは、監視、キャッシング、グローバルインデックス作成、データ分析、異種データベース間のプライマリ-セカンダリレプリケーションなどのさまざまなシナリオのデータソースを提供します。
TiCDCアーキテクチャ
TiCDCが実行されている場合、PDのetcdを介して高可用性を実現するステートレスノードです。 TiCDCクラスタは、複数の異なるダウンストリームプラットフォームにデータを複製するための複数の複製タスクの作成をサポートします。
TiCDCのアーキテクチャを次の図に示します。
システムの役割
TiKV CDCコンポーネント：Key-Value（KV）変更ログのみを出力します。
- KV変更ログを内部ロジックにアセンブルします。
- KV変更ログを出力するためのインターフェースを提供します。送信されるデータには、リアルタイムの変更ログと増分スキャンの変更ログが含まれます。
capture：TiCDCの操作プロセス。複数capturesは、KV変更ログを複製するTiCDCクラスタを形成します。- 各
captureは、KV変更ログの一部をプルします。 - プルされたKV変更ログをソートします。
- トランザクションをダウンストリームに復元するか、TiCDCオープンプロトコルに基づいてログを出力します。
- 各
レプリケーション機能
このセクションでは、TiCDCのレプリケーション機能を紹介します。
シンクサポート
現在、TiCDCシンクコンポーネントは、次のダウンストリームプラットフォームへのデータの複製をサポートしています。
- MySQLプロトコルと互換性のあるデータベース。シンクコンポーネントは、最終的な整合性サポートを提供します。
- TiCDCオープンプロトコルに基づく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シンクはDDLステートメントを繰り返し実行できます。
レプリケーションの一貫性
MySQLシンク
- TiCDCは、単一テーブルトランザクションを分割せず、単一テーブルトランザクションの原子性を保証します。
- TiCDCは、ダウンストリームトランザクションの実行順序がアップストリームトランザクションの実行順序と同じであることを保証しません。
- TiCDCは、クロステーブルトランザクションをテーブルの単位で分割し、クロステーブルトランザクションの原子性を保証しません。
- TiCDCは、単一行の更新の順序がアップストリームの順序と一致することを保証します。
カフカシンク
- TiCDCは、データ配布のためのさまざまな戦略を提供します。テーブル、主キー、またはタイムスタンプに基づいて、さまざまなKafkaパーティションにデータを配布できます。
- さまざまな配布戦略の場合、さまざまなコンシューマー実装は、行レベルの一貫性、結果整合性、またはクロステーブルトランザクションの一貫性など、さまざまなレベルの一貫性を実現できます。
- TiCDCにはKafkaコンシューマーの実装はありませんが、提供するのはTiCDCオープンプロトコルだけです。このプロトコルに従って、Kafkaコンシューマーを実装できます。
制限
TiCDCを使用する場合、いくつかの制限があります。
有効なインデックスの要件
TiCDCは、少なくとも1つの有効なインデックスを持つテーブルのみを複製します。有効なインデックスは次のように定義されます。
- 主キー（
PRIMARY KEY）は有効なインデックスです。 - 次の条件を満たす一意のインデックス（
UNIQUE INDEX）は、有効なインデックスです。- インデックスのすべての列は、null許容ではないものとして明示的に定義されています（
NOT NULL）。 - インデックスには、仮想的に生成された列（
VIRTUAL GENERATED COLUMNS）がありません。
- インデックスのすべての列は、null許容ではないものとして明示的に定義されています（
v4.0.8以降、TiCDCは、タスク構成を変更することにより、有効なインデックスなしでテーブルを複製することをサポートしています。ただし、これにより、データの一貫性の保証がある程度損なわれます。詳細については、 有効なインデックスなしでテーブルを複製するを参照してください。
サポートされていないシナリオ
現在、次のシナリオはサポートされていません。
- RawKVのみを使用するTiKVクラスタ。
- TiDBのDDL操作
CREATE SEQUENCEとSEQUENCE関数 。アップストリーム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はTiCDCOpenProtocolに準拠し、TiDBのデータ変更をMQ（メッセージキュー）などのサードパーティのデータメディアに複製します。詳細については、 TiCDCオープンプロトコルを参照してください。
互換性に関する注意事項
TiCDC v5.0.0- cdc cliツールを使用してv4.0.xクラスタを操作することによって引き起こされる非互換性の問題
TiCDCv5.0.0-rcのcdc cliツールを使用してv4.0.xTiCDCクラスタを操作すると、次の異常な状況が発生する可能性があります。
TiCDCクラスタがv4.0.8以前のバージョンの場合、v5.0.0-rc
cdc cliツールを使用してレプリケーションタスクを作成すると、クラスタの異常が発生し、レプリケーションタスクがスタックする可能性があります。TiCDCクラスタがv4.0.9以降のバージョンの場合、v5.0.0-rc
cdc cliツールを使用してレプリケーションタスクを作成すると、デフォルトで古い値と統合ソーター機能が予期せず有効になります。
解決策：TiCDCクラスタバージョンに対応するcdcの実行可能ファイルを使用して、次の操作を実行します。
- v5.0.0-
cdc cliツールを使用して作成されたチェンジフィードを削除します。たとえば、tiup cdc:v4.0.9 cli changefeed remove -c xxxx --pd=xxxxx --forceコマンドを実行します。 - レプリケーションタスクがスタックしている場合は、TiCDCクラスタを再起動します。たとえば、
tiup cluster restart <cluster_name> -R cdcコマンドを実行します。 - チェンジフィードを再作成します。たとえば、
tiup cdc:v4.0.9 cli changefeed create --sink-uri=xxxx --pd=xxxコマンドを実行します。
ノート：
上記の問題は、
cdc cliがv5.0.0-rcの場合にのみ発生します。他のcdc cliツールは、v4.0.xクラスターと互換性があります。
sort-dirとdata-dirの互換性に関する注意
sort-dir構成は、TiCDCソーターの一時ファイルディレクトリを指定するために使用されます。その機能はバージョンによって異なる場合があります。次の表に、バージョン間のsort-dirの互換性の変更を示します。
| バージョン | sort-engine機能 | ノート | おすすめ |
|---|---|---|---|
| v4.0.11またはそれ以前のv4.0バージョン、v5.0.0-rc | これはチェンジフィード構成アイテムであり、 fileソーターとunifiedソーターの一時ファイルディレクトリを指定します。 | これらのバージョンでは、 fileのソーターとunifiedのソーターは実験的機能であり、実稼働環境には推奨されません。複数のチェンジフィードが unifiedソーターをsort-engineとして使用する場合、実際の一時ファイルディレクトリはチェンジフィードのsort-dir構成である可能性があり、各TiCDCノードに使用されるディレクトリは異なる可能性があります。 | 実稼働環境でunifiedのソーターを使用することはお勧めしません。 |
| v4.0.12、v4.0.13、v5.0.0、およびv5.0.1 | チェンジフィードまたはcdc serverの構成項目です。 | デフォルトでは、チェンジフィードのsort-dirの構成は有効にならず、 cdc serverつのsort-dirの構成はデフォルトで/tmp/cdc_sortになります。実稼働環境ではcdc serverのみを構成することをお勧めします。TiUPを使用してTiCDCを展開する場合は、最新のTiUPバージョンを使用し、TiCDCサーバー構成で sorter.sort-dirを設定することをお勧めします。unifiedソーターは、v4.0.13、v5.0.0、およびv5.0.1ではデフォルトで有効になっています。クラスタをこれらのバージョンにアップグレードする場合は、TiCDCサーバー構成でsorter.sort-dirが正しく構成されていることを確認してください。 | cdc serverコマンドラインパラメータ（またはTiUP）を使用してsort-dirを設定する必要があります。 |
| v4.0.14以降のv4.0バージョン、v5.0.3以降のv5.0バージョン、それ以降のTiDBバージョン | sort-dirは非推奨です。 data-dirを構成することをお勧めします。 | 最新バージョンのTiUPを使用してdata-dirを構成できます。これらのTiDBバージョンでは、 unifiedソーターがデフォルトで有効になっています。クラスタをアップグレードするときは、 data-dirが正しく構成されていることを確認してください。それ以外の場合は、デフォルトで/tmp/cdc_dataが一時ファイルディレクトリとして使用されます。ディレクトリが配置されているデバイスのストレージ容量が不足している場合、ハードディスク容量が不足しているという問題が発生する可能性があります。この状況では、変更フィードの以前の sort-dirの構成は無効になります。 | cdc serverコマンドラインパラメータ（またはTiUP）を使用してdata-dirを設定する必要があります。 |
一時テーブルとの互換性
v5.3.0以降、TiCDCはグローバル一時テーブルをサポートします。 v5.3.0より前のバージョンのTiCDCを使用してグローバル一時テーブルをダウンストリームに複製すると、テーブル定義エラーが発生します。
アップストリームクラスタにグローバル一時テーブルが含まれている場合、ダウンストリームTiDBクラスタはv5.3.0以降のバージョンであると予想されます。そうしないと、レプリケーションプロセス中にエラーが発生します。
TiCDCのトラブルシューティング
詳しくはTiCDCのトラブルシューティングをご覧ください。