重要

このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

ストレージサービスへのデータのレプリケート

警告

この機能は実験的です。本番環境で使用することはお勧めしません。

v6.5.0 以降、TiCDC は Amazon S3、Azure Blob Storage、NFS などのstorageサービスへの行変更イベントの保存をサポートしています。このドキュメントでは、TiCDC を使用してそのようなstorageサービスに増分データをレプリケートする変更フィードを作成する方法と、データを保存する方法について説明します。このドキュメントの構成は次のとおりです。

データをstorageサービスにレプリケートする方法 .
storageサービスでのデータの保存方法 .

変更データをstorageサービスにレプリケートする

次のコマンドを実行して、changefeed タスクを作成します。

cdc cli changefeed create \
    --server=http://10.0.10.25:8300 \
    --sink-uri="s3://logbucket/storage_test?protocol=canal-json" \
    --changefeed-id="simple-replication-task"

出力は次のとおりです。

Info: {"upstream_id":7171388873935111376,"namespace":"default","id":"simple-replication-task","sink_uri":"s3://logbucket/storage_test?protocol=canal-json","create_time":"2023-03-10T18:52:05.566016967+08:00","start_ts":437706850431664129,"engine":"unified","config":{"case_sensitive":true,"enable_old_value":true,"force_replicate":false,"ignore_ineligible_table":false,"check_gc_safe_point":true,"enable_sync_point":false,"sync_point_interval":600000000000,"sync_point_retention":86400000000000,"filter":{"rules":["*.*"],"event_filters":null},"mounter":{"worker_num":16},"sink":{"protocol":"canal-json","schema_registry":"","csv":{"delimiter":",","quote":"\"","null":"\\N","include_commit_ts":false},"column_selectors":null,"transaction_atomicity":"none","encoder_concurrency":16,"terminator":"\r\n","date_separator":"none","enable_partition_separator":false},"consistent":{"level":"none","max_log_size":64,"flush_interval":2000,"storage":""}},"state":"normal","creator_version":"v6.5.2-master-dirty"}

--changefeed-id : 変更フィードの ID。形式は^[a-zA-Z0-9]+(\-[a-zA-Z0-9]+)*$正規表現と一致する必要があります。この ID が指定されていない場合、TiCDC は ID として UUID (バージョン 4 形式) を自動的に生成します。
--sink-uri : changefeed のダウンストリームアドレス。詳細については、シンク URI を構成するを参照してください。
--start-ts : 変更フィードの開始 TSO。 TiCDC は、この TSO からデータのプルを開始します。デフォルト値は現在の時刻です。
--target-ts : changefeed の終了 TSO。 TiCDC は、この TSO までデータのプルを停止します。デフォルト値は空です。これは、TiCDC がデータのプルを自動的に停止しないことを意味します。
--config : changefeed の構成ファイル。詳細については、 TiCDC changefeed 構成パラメーターを参照してください。

シンク URI を構成する

このセクションでは、Amazon S3、Azure Blob Storage、NFS など、changefeed URI でstorageサービスを構成する方法について説明します。

Amazon S3 または Azure Blob Storage を構成する

TiCDC の Amazon S3 と Azure Blob Storage の URI パラメーターは、 BRの URL パラメーターと同じです。詳細については、バックアップstorageのURL 形式を参照してください。

NFS の構成

次の構成では、行変更イベントが NFS に保存されます。

--sink-uri="file:///my-directory/prefix"

オプションのパラメーター

URI のその他のオプションパラメータは次のとおりです。

パラメータ	説明	デフォルト値	値の範囲
`worker-count`	データの変更をダウンストリームのクラウドstorageに保存するための同時実行性。	`16`	`[1, 512]`
`flush-interval`	データの変更をダウンストリームのクラウドstorageに保存する間隔。	`5s`	`[2s, 10m]`
`file-size`	バイト数がこのパラメータの値を超えると、データ変更ファイルがクラウドstorageに保存されます。	`67108864`	`[1048576, 536870912]`
`protocol`	ダウンストリームに送信されるメッセージのプロトコル形式。	なし	`canal-json`と`csv`

ノート：
flush-intervalまたはfile-sizeいずれかが要件を満たしている場合、データ変更ファイルはダウンストリームに保存されます。

ストレージパス構造

このセクションでは、データ変更レコード、メタデータ、および DDL イベントのstorageパス構造について説明します。

データ変更記録

データ変更レコードは次のパスに保存されます。

{scheme}://{prefix}/{schema}/{table}/{table-version-separator}/{partition-separator}/{date-separator}/CDC{num}.{extension}

scheme : データ転送プロトコルまたはstorageタイプを指定します (例: **s3** ://xxxxx )。
prefix : ユーザー定義の親ディレクトリを指定します (例: s3:// **bucket/bbb/ccc** )。
schema : スキーマ名を指定します (例: s3://bucket/bbb/ccc/ **test** 。
table : テーブル名を指定します (例: s3://bucket/bbb/ccc/test/ **table1** 。
table-version-separator : s3: s3://bucket/bbb/ccc/test/table1/ **9999**のように、パスをテーブルバージョンで区切るセパレータを指定します。
partition-separator : s3: s3://bucket/bbb/ccc/test/table1/9999/ **20**ように、パスをテーブルパーティションで区切るセパレータを指定します。
date-separator : トランザクションのコミット日によってファイルを分類します。値のオプションは次のとおりです。
- none : いいえdate-separator 。たとえば、バージョンtest.table1が9999のすべてのファイルはs3://bucket/bbb/ccc/test/table1/9999に保存されます。
- year : 区切り文字は、トランザクションのコミット日の年です (例s3://bucket/bbb/ccc/test/table1/9999/ **2022** 。
- month : 区切り文字は、トランザクションのコミット日の年と月です (例s3://bucket/bbb/ccc/test/table1/9999/ **2022-01** 。
- day : 区切り文字は、トランザクションのコミット日の年、月、日です (例s3://bucket/bbb/ccc/test/table1/9999/ **2022-01-02** 。
num : データの変更を記録するファイルのシリアル番号を保存します (例s3://bucket/bbb/ccc/test/table1/9999/2022-01-02/CDC **000005** .csv 。
extension : ファイルの拡張子を指定します。 v6.5.0 以降、TiDB は CSV および Canal-JSON 形式をサポートします。

ノート：
テーブルバージョンは、次の 2 つのケースで変更されます。
DDL 操作の実行後、アップストリームの TiDB で DDL が実行されたときのテーブルバージョンは TSO です。ただし、テーブルバージョンの変更は、テーブルスキーマの変更を意味するものではありません。たとえば、列にコメントを追加しても、 schema.jsonファイルの内容は変更されません。
changefeed プロセスが再起動します。テーブルバージョンは、プロセスの再起動時のチェックポイント TSO です。多くのテーブルがあり、プロセスが再起動すると、すべてのディレクトリを走査し、各テーブルが最後に書き込まれた位置を見つけるのに長い時間がかかります。したがって、データは、以前のディレクトリーではなく、バージョンがチェックポイント TSO である新しいディレクトリーに書き込まれます。

メタデータ

メタデータは次のパスに保存されます。

{protocol}://{prefix}/metadata

メタデータは、次のような JSON 形式のファイルです。

{
    "checkpoint-ts":433305438660591626
}

checkpoint-ts : commit-tsがcheckpoint-tsより小さいトランザクションは、ダウンストリームのターゲットstorageに書き込まれます。

DDL イベント

DDL イベントによってテーブルのバージョンが変更されると、TiCDC は新しいパスに切り替えてデータ変更レコードを書き込みます。たとえば、 test.table1のバージョンが9999から10000に変わると、パスs3://bucket/bbb/ccc/test/table1/10000/2022-01-02/CDC000001.csvにデータが書き込まれます。さらに、DDL イベントが発生すると、TiCDC はschema.jsonファイルを生成して、テーブルスキーマ情報を保存します。

テーブルスキーマ情報は、次のパスに保存されます。

{scheme}://{prefix}/{schema}/{table}/{table-version-separator}/schema.json

以下はschema.jsonファイルです。

{
    "Table":"table1",
    "Schema":"test",
    "Version":1,
    "TableVersion":10000,
    "Query": "ALTER TABLE test.table1 ADD OfficeLocation blob(20)",
    "TableColumns":[
        {
            "ColumnName":"Id",
            "ColumnType":"INT",
            "ColumnNullable":"false",
            "ColumnIsPk":"true"
        },
        {
            "ColumnName":"LastName",
            "ColumnType":"CHAR",
            "ColumnLength":"20"
        },
        {
            "ColumnName":"FirstName",
            "ColumnType":"VARCHAR",
            "ColumnLength":"30"
        },
        {
            "ColumnName":"HireDate",
            "ColumnType":"DATETIME"
        },
        {
            "ColumnName":"OfficeLocation",
            "ColumnType":"BLOB",
            "ColumnLength":"20"
        }
    ],
    "TableColumnsTotal":"5"
}

Table : テーブル名。
Schema : スキーマ名。
Version :storageシンクのプロトコルバージョン。
TableVersion : テーブルのバージョン。
Query ：DDL文。
TableColumns : 1 つ以上のマップの配列。それぞれがソーステーブルの列を記述します。
- ColumnName :カラム名。
- ColumnType :カラムのタイプ。詳細については、データ・タイプを参照してください。
- ColumnLength :カラムの長さ。詳細については、データ・タイプを参照してください。
- ColumnPrecision :カラムの精度。詳細については、データ・タイプを参照してください。
- ColumnScale : 小数点以下の桁数 (スケール)。詳細については、データ・タイプを参照してください。
- ColumnNullable : このオプションの値がtrueの場合、列は NULL にすることができます。
- ColumnIsPk : このオプションの値がtrueの場合、列は主キーの一部です。
TableColumnsTotal : TableColumns配列のサイズ。

データ・タイプ

このセクションでは、 schema.jsonファイルで使用されるデータ型について説明します。データ型はT(M[, D])として定義されています。詳細については、データ型を参照してください。

整数型

TiDB の整数型はIT[(M)] [UNSIGNED]として定義されます。

ITは整数型で、 TINYINT 、 SMALLINT 、 MEDIUMINT 、 INT 、 BIGINT 、またはBITのいずれかです。
Mは、タイプの表示幅です。

schema.jsonでは、整数型は次のように定義されています。

{
    "ColumnName":"COL1",
    "ColumnType":"{IT} [UNSIGNED]",
    "ColumnPrecision":"{M}"
}

10 進数型

TiDB の Decimal 型はDT[(M,D)][UNSIGNED]として定義されます。

DTは浮動小数点型で、 FLOAT 、 DOUBLE 、 DECIMAL 、またはNUMERICのいずれかです。
Mはデータ型の精度、または合計桁数です。
Dは小数点以下の桁数です。

Decimal 型はschema.jsonで次のように定義されています。

{
    "ColumnName":"COL1",
    "ColumnType":"{DT} [UNSIGNED]",
    "ColumnPrecision":"{M}",
    "ColumnScale":"{D}"
}

日付と時刻の種類

TiDB の日付型はDTとして定義されています。

DTは日付タイプで、 DATEまたはYEARです。

schema.jsonでは、日付型は次のように定義されています。

{
    "ColumnName":"COL1",
    "ColumnType":"{DT}"
}

TiDB の時刻型はTT[(M)]として定義されています。

TTは時間タイプで、 TIME 、 DATETIME 、またはTIMESTAMPのいずれかです。
Mは、0 ～ 6 の範囲の秒の精度です。

時間タイプは、 schema.jsonで次のように定義されています。

{
    "ColumnName":"COL1",
    "ColumnType":"{TT}",
    "ColumnScale":"{M}"
}

文字列型

TiDB の文字列型はST[(M)]として定義されています。

STは文字列型で、 CHAR 、 VARCHAR 、 TEXT 、 BINARY 、 BLOB 、またはJSONのいずれかです。
Mは文字列の最大長です。

文字列型はschema.jsonで次のように定義されています。

{
    "ColumnName":"COL1",
    "ColumnType":"{ST}",
    "ColumnLength":"{M}"
}

列挙型とセット型

Enum および Set 型は、 schema.jsonで次のように定義されています。

{
    "ColumnName":"COL1",
    "ColumnType":"{ENUM/SET}",
}

ストレージ サービスへのデータのレプリケート