データをMySQL互換データベースに複製する

このドキュメントでは、TiCDCを使用して増分データを下流のTiDBデータベースまたはその他のMySQL互換データベースにレプリケートする方法について説明します。また、災害発生時のシナリオで結果整合性レプリケーション機能を使用する方法についても紹介します。

レプリケーションタスクを作成する

次のコマンドを実行して、レプリケーションタスクを作成します。

cdc cli changefeed create \
    --server=http://10.0.10.25:8300 \
    --sink-uri="mysql://root:123456@127.0.0.1:3306/" \
    --changefeed-id="simple-replication-task"

Create changefeed successfully!
ID: simple-replication-task
Info: {"sink-uri":"mysql://root:123456@127.0.0.1:3306/","opts":{},"create-time":"2023-11-28T22:04:08.103600025+08:00","start-ts":415241823337054209,"target-ts":0,"admin-job-type":0,"sort-engine":"unified","sort-dir":".","config":{"case-sensitive":false,"filter":{"rules":["*.*"],"ignore-txn-start-ts":null,"ddl-allow-list":null},"mounter":{"worker-num":16},"sink":{"dispatchers":null},"scheduler":{"type":"table-number","polling-time":-1}},"state":"normal","history":null,"error":null}

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

注記：

• TiCDCは増分データのみを複製します。完全なデータを初期化するには、 Dumpling/ TiDB LightningまたはBRを使用してください。
• 完全なデータ初期化が完了したら、アップストリームバックアップを実行する際にstart-tsをTSOとして指定する必要があります。例えば、 Dumplingディレクトリ内のメタデータファイルにあるposの値、またはBRがバックアップを完了した後のログ出力にあるbackupTSの値などです。

MySQLまたはTiDBのシンクURIを設定します

シンクURIは、TiCDCターゲットシステムの接続情報を指定するために使用されます。フォーマットは以下のとおりです。

[scheme]://[userinfo@][host]:[port][/path]?[query_parameters]

注記：

/pathは MySQL シンクには使用されません。

MySQLの設定例：

--sink-uri="mysql://root:12345678@127.0.0.1:3306"

以下は、MySQLまたはTiDB用に構成可能なシンクURIパラメータとパラメータ値の説明です。

注記：

• time-zoneはmysqlおよびtidbシンクでのみ有効です。TiCDC がダウンストリームとの接続を確立した後、セッションのtime_zoneを設定します。このtime_zoneは、ダウンストリームが DDL および DML ステートメントを実行する際に、 TIMESTAMPなどのタイムゾーンの影響を受ける時間値を解析するために使用されます。 DATETIME 、 DATE 、およびTIMEデータ型は、タイムゾーン設定の影響を受けません。
• タイムゾーン設定の不一致によって発生するデータの不整合を回避するために、 time-zone明示的に設定し、その値が TiCDC サーバーの--tzパラメータおよび下流データベースのタイムゾーンと一致していることを確認することをお勧めします。

シンクURI内のデータベースパスワードをBase64でエンコードするには、次のコマンドを使用します。

echo -n '12345678' | base64   # '12345678' is the password to be encoded.

エンコードされたパスワードは以下のとおりです。

MTIzNDU2Nzg=

注記：

シンク URI パラメータに! * ' ( ) ; : @ & = + $ , / ? % # [ ]などの特殊文字が含まれている場合は、 URIエンコーダーのように特殊文字をエスケープする必要があります。

例えば、ダウンストリームデータベースへの接続に使用するユーザー名がR&D (2)で、証明書ファイルのパスが/data1/R&D (2).pemの場合、これらのパラメータを次のようにエスケープする必要があります。

--sink-uri="mysql://R%26D%20%282%29:MTIzNDU2Nzg%3D@127.0.0.1:3306/?ssl-cert=/data1/R%26D%20%282%29.pem"
#                    ^~~ ^~~^~~ ^~~            ^~~                                  ^~~ ^~~^~~ ^~~

下流データベースユーザーに必要な権限

TiDBまたはその他のMySQL互換データベースにデータを複製するには、下流のデータベースユーザーに以下の権限が必要です。

• Select
• Index
• Insert
• Update
• Delete
• Create
• References
• Drop
• Alter
• Create View

RECOVER TABLE下流の TiDB に複製するには、下流のデータベース ユーザーはSuper権限も必要とします。

ダウンストリーム TiDB クラスターで読み取り専用モードが有効になっている場合、ダウンストリーム データベース ユーザーにはRESTRICTED_REPLICA_WRITER_ADMIN権限も必要です。

最終的には災害シナリオにおける一貫した再現

TiCDC の最終整合性レプリケーション機能は、リドゥ ログを使用して、アップストリームで障害が発生した場合でもデータの一貫性を確保します。この機能は、バージョン 6.1.1 から一般提供 (GA) となります。バージョン 5.3.0 から、TiCDC は、アップストリーム TiDB クラスタからダウンストリーム クラスタのオブジェクトstorageまたは NFS への増分データのバックアップをサポートします。アップストリーム クラスタで障害が発生して利用できなくなった場合、TiCDC はダウンストリーム データを最新の最終整合性状態に復元できます。この機能により、アプリケーションをダウンストリーム クラスタに迅速に切り替えることができ、長時間のダウンタイムを回避し、サービスの継続性を向上させることができます。

現在、TiCDCは、TiDBクラスタから別のTiDBクラスタまたはMySQL互換データベースシステム（ Aurora、MySQL、MariaDBを含む）へ増分データを複製できます。上流クラスタがクラッシュした場合、TiCDCがクラッシュ前に正常にデータを複製し、複製遅延が小さいという条件を満たせば、TiCDCは下流クラスタで5分以内にデータを復元できます。データ損失は最大10秒まで許容され、RTOは5分以下、P95 RPOは10秒以下となります。

TiCDCのレプリケーション遅延は、以下のシナリオで増加します。

• TPSは短時間で大幅に増加する。
• 上流工程では、大規模または長時間の取引が発生する。
• アップストリームのTiKVまたはTiCDCクラスタが再ロードまたはアップグレードされます。
• add indexのような時間のかかる DDL ステートメントは、上流で実行されます。
• PDは積極的なスケジューリング戦略で構成されており、その結果、リージョンリーダーの頻繁な異動、あるいはリージョンの統合や分割が頻繁に発生します。

注記：

バージョン6.1.1以降、TiCDCの最終整合性レプリケーション機能はAmazon S3互換のオブジェクトstorageをサポートしています。バージョン6.1.4以降、この機能はGCSおよびAzure互換のオブジェクトstorageもサポートしています。

前提条件

• TiCDCのリアルタイム増分データバックアップファイルを保存するために、高可用性のオブジェクトstorageまたはNFSを準備してください。これらのファイルは、上流側で災害が発生した場合にアクセスできます。
• 災害発生時に最終的な整合性が必要な変更フィードに対して、この機能を有効にしてください。有効にするには、変更フィードの設定ファイルに以下の設定を追加します。

[consistent]
# Consistency level. Options include:
# - none: the default value. In a non-disaster scenario, eventual consistency is only guaranteed if and only if finished-ts is specified.
# - eventual: Uses redo log to guarantee eventual consistency in case of the primary cluster disasters.
level = "eventual"

# Individual redo log file size, in MiB. By default, it's 64. It is recommended to be no more than 128.
max-log-size = 64

# The interval for flushing or uploading redo logs to Amazon S3, in milliseconds. It is recommended that this configuration be equal to or greater than 2000.
flush-interval = 2000

# The path under which redo log backup is stored. The scheme can be nfs (NFS directory), or Amazon S3, GCS, and Azure (uploaded to object storage).
storage = "$SCHEME://logbucket/test-changefeed?endpoint=http://$ENDPOINT/"

災害リカバリ

プライマリクラスタで障害が発生した場合は、 cdc redoコマンドを実行してセカンダリクラスタで手動で復旧する必要があります。リカバリ手順は以下のとおりです。

1. TiCDCのすべてのプロセスが終了していることを確認してください。これは、データリカバリ中にプライマリクラスタがサービスを再開したり、TiCDCがデータ同期を再開したりするのを防ぐためです。
2. データリカバリにはcdcバイナリを使用してください。以下のコマンドを実行してください。

cdc redo apply --tmp-dir="/tmp/cdc/redo/apply" \
    --storage="s3://logbucket/test-changefeed?endpoint=http://10.0.10.25:24927/" \
    --sink-uri="mysql://normal:123456@10.0.10.55:3306/"

このコマンドでは：

• tmp-dir : TiCDC増分データバックアップファイルをダウンロードするための一時ディレクトリを指定します。
• storage : TiCDC増分データバックアップファイルを保存するアドレスを指定します。オブジェクトstorageのURIまたはNFSディレクトリのいずれかを指定します。
• sink-uri : データを復元するセカンダリクラスタアドレスを指定します。スキームはmysqlのみ可能です。