TiCDC オープン プロトコル
TiCDC Open Protocol は、監視、キャッシング、フルテキスト インデックス作成、分析エンジン、および異なるデータベース間のプライマリ/セカンダリ レプリケーションのためのデータ ソースを提供する、行レベルのデータ変更通知プロトコルです。 TiCDC は TiCDC Open Protocol に準拠し、TiDB のデータ変更を MQ (Message Queue) などのサードパーティのデータ媒体に複製します。
TiCDC Open Protocol は、イベントを基本単位として使用して、データ変更イベントをダウンストリームに複製します。イベントは次の 3 つのカテゴリに分類されます。
- 行変更イベント: 行のデータ変更を表します。行が変更されると、このイベントが送信され、変更された行に関する情報が含まれます。
- DDL イベント: DDL の変更を表します。このイベントは、DDL ステートメントがアップストリームで正常に実行された後に送信されます。 DDL イベントはすべての MQ パーティションにブロードキャストされます。
- 解決済みイベント: 受信したイベントが完了する前の特別な時点を表します。
制限
- ほとんどの場合、バージョンの Row Changed Event は 1 回だけ送信されますが、ノード障害やネットワーク パーティションなどの特殊な状況では、同じバージョンの Row Changed Event が複数回送信されることがあります。
- 同じテーブルで、最初に送信された各バージョンの行変更イベントは、イベント ストリームのタイムスタンプ (TS) の順序で増加します。
- 解決済みイベントは、各 MQ パーティションに定期的にブロードキャストされます。 Resolved Event は、Resolved Event TS より前の TS を持つイベントがダウンストリームに送信されたことを意味します。
- DDL イベントは各 MQ パーティションにブロードキャストされます。
- 行の複数の行変更イベントが同じ MQ パーティションに送信されます。
メッセージ形式
メッセージには、次の形式で配置された 1 つ以上のイベントが含まれます。
鍵：
価値：
LengthNN番目のキー/値の長さを表します。- 長さとプロトコルバージョンはビッグエンディアンの
int64型です。 - 現在のプロトコルのバージョンは
1です。
イベント形式
このセクションでは、行変更イベント、DDL イベント、および解決イベントの形式を紹介します。
行変更イベント
鍵：
{ "ts":<TS>, "scm":<Schema Name>, "tbl":<Table Name>, "t":1 }価値：
Insertイベント。新たに追加された行データが出力されます。{ "u":{ <Column Name>:{ "t":<Column Type>, "h":<Where Handle>, "f":<Flag>, "v":<Column Value> }, <Column Name>:{ "t":<Column Type>, "h":<Where Handle>, "f":<Flag>, "v":<Column Value> } } }Updateイベント。新たに追加された行データ（「u」）と更新前の行データ（「p」）が出力されます。後者 (「p」) は、古い値機能が有効になっている場合にのみ出力されます。{ "u":{ <Column Name>:{ "t":<Column Type>, "h":<Where Handle>, "f":<Flag>, "v":<Column Value> }, <Column Name>:{ "t":<Column Type>, "h":<Where Handle>, "f":<Flag>, "v":<Column Value> } }, "p":{ <Column Name>:{ "t":<Column Type>, "h":<Where Handle>, "f":<Flag>, "v":<Column Value> }, <Column Name>:{ "t":<Column Type>, "h":<Where Handle>, "f":<Flag>, "v":<Column Value> } } }Deleteイベント。削除された行データが出力されます。古い値機能が有効になっている場合、Deleteイベントには、削除された行データのすべての列が含まれます。この機能が無効になっている場合、Deleteイベントにはハンドルキー列のみが含まれます。{ "d":{ <Column Name>:{ "t":<Column Type>, "h":<Where Handle>, "f":<Flag>, "v":<Column Value> }, <Column Name>:{ "t":<Column Type>, "h":<Where Handle>, "f":<Flag>, "v":<Column Value> } } }
DDL イベント
鍵：
{ "ts":<TS>, "scm":<Schema Name>, "tbl":<Table Name>, "t":2 }価値：
{ "q":<DDL Query>, "t":<DDL Type> }
解決済みのイベント
鍵：
{ "ts":<TS>, "t":3 }値:なし
イベント ストリーム出力の例
このセクションには、イベント ストリームの出力ログが表示されます。
アップストリームで次の SQL ステートメントを実行し、MQ パーティション番号が 2 であるとします。
CREATE TABLE test.t1(id int primary key, val varchar(16));
次のログ 1 とログ 3 から、DDL イベントがすべての MQ パーティションにブロードキャストされ、解決済みイベントが各 MQ パーティションに定期的にブロードキャストされていることがわかります。
1. [partition=0] [key="{\"ts\":415508856908021766,\"scm\":\"test\",\"tbl\":\"t1\",\"t\":2}"] [value="{\"q\":\"CREATE TABLE test.t1(id int primary key, val varchar(16))\",\"t\":3}"]
2. [partition=0] [key="{\"ts\":415508856908021766,\"t\":3}"] [value=]
3. [partition=1] [key="{\"ts\":415508856908021766,\"scm\":\"test\",\"tbl\":\"t1\",\"t\":2}"] [value="{\"q\":\"CREATE TABLE test.t1(id int primary key, val varchar(16))\",\"t\":3}"]
4. [partition=1] [key="{\"ts\":415508856908021766,\"t\":3}"] [value=]
アップストリームで次の SQL ステートメントを実行します。
BEGIN;
INSERT INTO test.t1(id, val) VALUES (1, 'aa');
INSERT INTO test.t1(id, val) VALUES (2, 'aa');
UPDATE test.t1 SET val = 'bb' WHERE id = 2;
INSERT INTO test.t1(id, val) VALUES (3, 'cc');
COMMIT;
- 次のログ 5 とログ 6 から、同じテーブルの行変更イベントが主キーに基づいて異なるパーティションに送信される可能性があることがわかりますが、同じ行への変更は同じパーティションに送信されるため、ダウンストリームは簡単に変更できます。イベントを同時に処理します。
- ログ 6 以降、トランザクション内の同じ行に対する複数の変更は、1 つの行変更イベントでのみ送信されます。
- ログ 8 はログ 7 の繰り返しイベントです。行変更イベントは繰り返される可能性がありますが、各バージョンの最初のイベントは順番に送信されます。
5. [partition=0] [key="{\"ts\":415508878783938562,\"scm\":\"test\",\"tbl\":\"t1\",\"t\":1}"] [value="{\"u\":{\"id\":{\"t\":3,\"h\":true,\"v\":1},\"val\":{\"t\":15,\"v\":\"YWE=\"}}}"]
6. [partition=1] [key="{\"ts\":415508878783938562,\"scm\":\"test\",\"tbl\":\"t1\",\"t\":1}"] [value="{\"u\":{\"id\":{\"t\":3,\"h\":true,\"v\":2},\"val\":{\"t\":15,\"v\":\"YmI=\"}}}"]
7. [partition=0] [key="{\"ts\":415508878783938562,\"scm\":\"test\",\"tbl\":\"t1\",\"t\":1}"] [value="{\"u\":{\"id\":{\"t\":3,\"h\":true,\"v\":3},\"val\":{\"t\":15,\"v\":\"Y2M=\"}}}"]
8. [partition=0] [key="{\"ts\":415508878783938562,\"scm\":\"test\",\"tbl\":\"t1\",\"t\":1}"] [value="{\"u\":{\"id\":{\"t\":3,\"h\":true,\"v\":3},\"val\":{\"t\":15,\"v\":\"Y2M=\"}}}"]
アップストリームで次の SQL ステートメントを実行します。
BEGIN;
DELETE FROM test.t1 WHERE id = 1;
UPDATE test.t1 SET val = 'dd' WHERE id = 3;
UPDATE test.t1 SET id = 4, val = 'ee' WHERE id = 2;
COMMIT;
- ログ 9 は、
Deleteタイプの行変更イベントです。このタイプのイベントには、主キー列または一意のインデックス列のみが含まれます。 - ログ 13 とログ 14 は解決済みイベントです。 Resolved Event は、このパーティションで Resolved TS より小さいイベント (Row Changed Event および DDL Event を含む) が送信されたことを意味します。
9. [partition=0] [key="{\"ts\":415508881418485761,\"scm\":\"test\",\"tbl\":\"t1\",\"t\":1}"] [value="{\"d\":{\"id\":{\"t\":3,\"h\":true,\"v\":1}}}"]
10. [partition=1] [key="{\"ts\":415508881418485761,\"scm\":\"test\",\"tbl\":\"t1\",\"t\":1}"] [value="{\"d\":{\"id\":{\"t\":3,\"h\":true,\"v\":2}}}"]
11. [partition=0] [key="{\"ts\":415508881418485761,\"scm\":\"test\",\"tbl\":\"t1\",\"t\":1}"] [value="{\"u\":{\"id\":{\"t\":3,\"h\":true,\"v\":3},\"val\":{\"t\":15,\"v\":\"ZGQ=\"}}}"]
12. [partition=0] [key="{\"ts\":415508881418485761,\"scm\":\"test\",\"tbl\":\"t1\",\"t\":1}"] [value="{\"u\":{\"id\":{\"t\":3,\"h\":true,\"v\":4},\"val\":{\"t\":15,\"v\":\"ZWU=\"}}}"]
13. [partition=0] [key="{\"ts\":415508881038376963,\"t\":3}"] [value=]
14. [partition=1] [key="{\"ts\":415508881038376963,\"t\":3}"] [value=]
コンシューマー向けのプロトコル解析
現在、TiCDC は TiCDC Open Protocol の標準解析ライブラリを提供していませんが、解析例のGolangバージョンとJavaバージョンが提供されています。このドキュメントで提供されているデータ形式と次の例を参照して、コンシューマー向けのプロトコル解析を実装できます。
カラムタイプ コード
Column Type Code行変更イベントの列データ型を表します。
DDL タイプ コード
DDL Type Code DDL イベントの DDL ステートメント タイプを表します。
列のビット フラグ
ビット フラグは、列の特定の属性を表します。
例：
列フラグの値が85の場合、その列は null 許容列、一意のインデックス列、生成された列、およびバイナリ エンコードされた列です。
85 == 0b_101_0101
== NullableFlag | UniqueKeyFlag | GeneratedColumnFlag | BinaryFlag
列の値が46の場合、その列は複合インデックス列、主キー列、生成列、およびハンドル キー列です。
46 == 0b_010_1110
== MultipleKeyFlag | PrimaryKeyFlag | GeneratedColumnFlag | HandleKeyFlag
ノート：
BinaryFlag列の型が BLOB/ TEXT (TINYBLOB/TINYTEXT および BINARY/CHAR を含む) の場合のみ意味があります。上流の列が BLOB 型の場合、BinaryFlag値は1に設定されます。上流列がTEXTタイプの場合、BinaryFlag値は0に設定されます。- アップストリームからテーブルを複製するために、TiCDC はハンドル インデックスとして有効なインデックスを選択します。ハンドル インデックス列の
HandleKeyFlag値は1に設定されます。