TiCDC Avro プロトコル
Avro は、 アパッチ アブロ™によって定義され、デフォルトのデータ交換フォーマットとしてコンフルエントなプラットフォームによって選択されたデータ交換フォーマット プロトコルです。このドキュメントでは、TiDB 拡張フィールド、Avro データ形式の定義、および Avro とコンフルエント スキーマ レジストリの間の相互作用を含む、TiCDC での Avro データ形式の実装について説明します。
アブロを使用
Message Queue (MQ) をダウンストリーム シンクとして使用する場合、 Avro をsink-uri
で指定できます。 TiCDC は TiDB DML イベントをキャプチャし、これらのイベントから Avro メッセージを作成して、メッセージをダウンストリームに送信します。 Avro は、スキーマの変更を検出すると、最新のスキーマをスキーマ レジストリに登録します。
以下は、Avro を使用した構成例です。
cdc cli changefeed create --pd=http://127.0.0.1:2379 --changefeed-id="kafka-avro" --sink-uri="kafka://127.0.0.1:9092/topic-name?protocol=avro" --schema-registry=http://127.0.0.1:8081 --config changefeed_config.toml
[sink]
dispatchers = [
{matcher = ['*.*'], topic = "tidb_{schema}_{table}"},
]
値--schema-registry
はhttps
プロトコルとusername:password
認証をサポートします (例: --schema-registry=https://username:password@schema-registry-uri.com
)。ユーザー名とパスワードは URL エンコードする必要があります。
TiDB 拡張フィールド
デフォルトでは、Avro は DML イベントで変更された行のデータのみを収集し、データ変更のタイプや TiDB 固有の CommitTS (トランザクションの一意の識別子) は収集しません。この問題に対処するために、TiCDC は次の 3 つの TiDB 拡張フィールドを Avro プロトコル メッセージに導入します。 sink-uri
でenable-tidb-extension
がtrue
(デフォルトではfalse
) に設定されている場合、TiCDC はメッセージ生成中にこれら 3 つのフィールドを Avro メッセージに追加します。
_tidb_op
: DML タイプ。 「c」は挿入を示し、「u」は更新を示します。_tidb_commit_ts
: トランザクションの一意の識別子。_tidb_commit_physical_time
: トランザクション ID の物理タイムスタンプ。
次に設定例を示します。
cdc cli changefeed create --pd=http://127.0.0.1:2379 --changefeed-id="kafka-avro-enable-extension" --sink-uri="kafka://127.0.0.1:9092/topic-name?protocol=avro&enable-tidb-extension=true" --schema-registry=http://127.0.0.1:8081 --config changefeed_config.toml
[sink]
dispatchers = [
{matcher = ['*.*'], topic = "tidb_{schema}_{table}"},
]
データ形式の定義
TiCDC は DML イベントを Kafka イベントに変換し、イベントのキーと値は Avro プロトコルに従ってエンコードされます。
鍵データ形式
{
"name":"{{TableName}}",
"namespace":"{{Namespace}}",
"type":"record",
"fields":[
{{ColumnValueBlock}},
{{ColumnValueBlock}},
]
}
{{TableName}}
は、イベントが発生したテーブルの名前を示します。{{Namespace}}
は Avro の名前空間です。{{ColumnValueBlock}}
は、データの各列の形式を定義します。
キーのfields
には、主キー列または一意のインデックス列のみが含まれます。
値のデータ形式
{
"name":"{{TableName}}",
"namespace":"{{Namespace}}",
"type":"record",
"fields":[
{{ColumnValueBlock}},
{{ColumnValueBlock}},
]
}
デフォルトでは、Value のデータ形式は Key と同じです。ただし、値のfields
には、主キー列だけでなく、すべての列が含まれます。
enable-tidb-extension
を有効にすると、値のデータ形式は次のようになります。
{
"name":"{{TableName}}",
"namespace":"{{Namespace}}",
"type":"record",
"fields":[
{{ColumnValueBlock}},
{{ColumnValueBlock}},
{
"name":"_tidb_op",
"type":"string"
},
{
"name":"_tidb_commit_ts",
"type":"long"
},
{
"name":"_tidb_commit_physical_time",
"type":"long"
}
]
}
enable-tidb-extension
が無効になっている値のデータ形式と比較すると、3 つの新しいフィールドが追加されています: _tidb_op
、 _tidb_commit_ts
、および_tidb_commit_physical_time
。
カラムデータ形式
カラムデータは、キー/値データ形式の{{ColumnValueBlock}}
の部分です。 TiCDC は、SQL タイプに基づいてカラムデータ形式を生成します。基本的なカラムデータ形式は次のとおりです。
{
"name":"{{ColumnName}}",
"type":{
"connect.parameters":{
"tidb_type":"{{TIDB_TYPE}}"
},
"type":"{{AVRO_TYPE}}"
}
}
1 つの列が NULL になる可能性がある場合、カラムのデータ形式は次のようになります。
{
"default":null,
"name":"{{ColumnName}}",
"type":[
"null",
{
"connect.parameters":{
"tidb_type":"{{TIDB_TYPE}}"
},
"type":"{{AVRO_TYPE}}"
}
]
}
{{ColumnName}}
は列名を示します。{{TIDB_TYPE}}
は、TiDB の型を示します。これは、SQL 型との 1 対 1 のマッピングではありません。{{AVRO_TYPE}}
はアブロスペックのタイプを示します。
SQL タイプ | TIDB_TYPE | AVRO_TYPE | 説明 |
---|---|---|---|
ブール | INT | 整数 | |
TINYINT | INT | 整数 | unsigned の場合、TIDB_TYPE は INT UNSIGNED です。 |
SMALLINT | INT | 整数 | unsigned の場合、TIDB_TYPE は INT UNSIGNED です。 |
ミディアムミント | INT | 整数 | unsigned の場合、TIDB_TYPE は INT UNSIGNED です。 |
INT | INT | 整数 | unsigned の場合、TIDB_TYPE は INT UNSIGNED で、AVRO_TYPE は long です。 |
BIGINT | BIGINT | 長いです | 署名されていない場合、TIDB_TYPE は BIGINT UNSIGNED です。 avro-bigint-unsigned-handling-mode が文字列の場合、AVRO_TYPE は文字列です。 |
小さな塊 | BLOB | バイト | |
BLOB | BLOB | バイト | |
ミディアムブロブ | BLOB | バイト | |
ロングブロブ | BLOB | バイト | |
バイナリ | BLOB | バイト | |
VARBINARY | BLOB | バイト | |
小さなテキスト | 文章 | ストリング | |
文章 | 文章 | ストリング | |
中文 | 文章 | ストリング | |
ロングテキスト | 文章 | ストリング | |
CHAR | 文章 | ストリング | |
VARCHAR | 文章 | ストリング | |
浮く | 浮く | ダブル | |
ダブル | ダブル | ダブル | |
日にち | 日にち | ストリング | |
日付時刻 | 日付時刻 | ストリング | |
タイムスタンプ | タイムスタンプ | ストリング | |
時間 | 時間 | ストリング | |
年 | 年 | 整数 | |
少し | 少し | バイト | |
JSON | JSON | ストリング | |
列挙型 | 列挙型 | ストリング | |
設定 | 設定 | ストリング | |
小数 | 小数 | バイト | avro-decimal-handling-mode が文字列の場合、AVRO_TYPE は文字列です。 |
Avro プロトコルでは、他の 2 つのsink-uri
パラメーター ( avro-decimal-handling-mode
およびavro-bigint-unsigned-handling-mode
) もカラムデータ形式に影響を与える可能性があります。
avro-decimal-handling-mode
は、Avro が以下を含む小数フィールドを処理する方法を制御します。- string: Avro は 10 進数フィールドを文字列として処理します。
- 正確: Avro は 10 進数フィールドをバイトとして処理します。
avro-bigint-unsigned-handling-mode
は、次のような BIGINT UNSIGNED フィールドを Avro が処理する方法を制御します。- string: Avro は BIGINT UNSIGNED フィールドを文字列として処理します。
- long: Avro は BIGINT UNSIGNED フィールドを 64 ビット符号付き整数として処理します。値が
9223372036854775807
より大きい場合、オーバーフローが発生します。
次に設定例を示します。
cdc cli changefeed create --pd=http://127.0.0.1:2379 --changefeed-id="kafka-avro-string-option" --sink-uri="kafka://127.0.0.1:9092/topic-name?protocol=avro&avro-decimal-handling-mode=string&avro-bigint-unsigned-handling-mode=string" --schema-registry=http://127.0.0.1:8081 --config changefeed_config.toml
[sink]
dispatchers = [
{matcher = ['*.*'], topic = "tidb_{schema}_{table}"},
]
ほとんどの SQL タイプは、基本カラムデータ形式にマップされます。他の一部の SQL タイプは、基本データ形式を拡張して、より多くの情報を提供します。
ビット(64)
{
"name":"{{ColumnName}}",
"type":{
"connect.parameters":{
"tidb_type":"BIT",
"length":"64"
},
"type":"bytes"
}
}
ENUM/SET(a,b,c)
{
"name":"{{ColumnName}}",
"type":{
"connect.parameters":{
"tidb_type":"ENUM/SET",
"allowed":"a,b,c"
},
"type":"string"
}
}
DECIMAL(10, 4)
{
"name":"{{ColumnName}}",
"type":{
"connect.parameters":{
"tidb_type":"DECIMAL",
},
"logicalType":"decimal",
"precision":10,
"scale":4,
"type":"bytes"
}
}
DDL イベントとスキーマの変更
Avro はダウンストリームの DDL イベントを生成しません。 DML イベントが発生するたびにスキーマが変更されているかどうかを確認します。スキーマが変更されると、Avro は新しいスキーマを生成し、スキーマ レジストリに登録します。スキーマの変更が互換性チェックに合格しない場合、登録は失敗します。 Avro はスキーマの互換性の問題を解決しません。
スキーマの変更が互換性チェックに合格し、新しいバージョンが登録された場合でも、データのプロデューサーとコンシューマーは、システムを正常に実行するためにアップグレードを実行する必要があることに注意してください。
Confluent Schema Registry のデフォルトの互換性ポリシーがBACKWARD
であると仮定し、ソース テーブルに空でない列を追加します。この状況では、Avro は新しいスキーマを生成しますが、互換性の問題によりスキーマ レジストリへの登録に失敗します。このとき、changefeed はエラー状態になります。
スキーマの詳細については、 スキーマ レジストリ関連ドキュメントを参照してください。
トピックの配布
スキーマ レジストリは、TopicNameStrategy、RecordNameStrategy、および TopicRecordNameStrategy の 3 つサブジェクト名戦略をサポートします。現在、TiCDC Avro は TopicNameStrategy のみをサポートしています。つまり、Kafka トピックは 1 つのデータ形式でしかデータを受信できません。したがって、TiCDC Avro では、複数のテーブルを同じトピックにマッピングすることを禁止しています。変更フィードを作成するときに、構成された配布ルールにトピック ルールに{schema}
と{table}
のプレースホルダーが含まれていない場合、エラーが報告されます。