📣

TiDB Cloud Serverless が
Starter
に変わりました!このページは自動翻訳されたものです。
原文はこちらからご覧ください。

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 : レプリケーションタスクのダウンストリームアドレス。詳細はmysql / tidbでシンクURIを設定する参照してください。
  • --start-ts : チェンジフィードの開始TSOを指定します。このTSOから、TiCDCクラスターはデータのプルを開始します。デフォルト値は現在時刻です。
  • --target-ts : チェンジフィードの終了TSOを指定します。このTSOまで、TiCDCクラスターはデータのプルを停止します。デフォルト値は空で、TiCDCはデータのプルを自動的に停止しません。
  • --config : changefeed設定ファイルを指定します。詳細はTiCDC Changefeedコンフィグレーションパラメータ参照してください。

注記:

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

MySQL または TiDB のシンク URI を構成する

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

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

注記:

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

MySQL のサンプル構成:

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

以下は、MySQL または TiDB に対して構成できるシンク URI パラメータとパラメータ値の説明です。

パラメータ/パラメータ値説明
rootダウンストリームデータベースのユーザー名。TiDBまたはその他のMySQL互換データベースにデータを複製するには、ダウンストリームデータベースのユーザーに特定の権限あることを確認してください。
123456ダウンストリーム データベースのパスワード (Base64 を使用してエンコードできます)。
127.0.0.1ダウンストリーム データベースの IP アドレス。
3306ダウンストリーム データベースのポート。
worker-countダウンストリームに対して同時に実行できる SQL 文の数 (オプション、デフォルト値は16 、最大値は1024 )。
cache-prep-stmtsダウンストリームで SQL を実行するときに準備済みステートメントを使用するかどうか、およびクライアント側でプリペアドステートメントキャッシュを有効にするかどうかを制御します (オプション、デフォルトはtrue )。
max-txn-rowダウンストリームに対して実行される SQL ステートメントのバッチ サイズ (オプション、デフォルト値は256 、最大値は2048 )。
max-multi-update-rowバッチ書き込み( batch-dml-enable )が有効な場合に下流に実行されるUPDATE ROWS SQL文のバッチサイズ。常にmax-txn-row未満です(オプション、デフォルト値は40 、最大値は256 )。
max-multi-update-row-sizeバッチ書き込み( batch-dml-enable )が有効な場合、下流に実行されるSQL文のサイズ制限UPDATE ROWS 。このサイズ制限を超えると、各行は個別のSQL文として実行されます(オプション、デフォルト値は1024 、最大値は8192 )。
ssl-caダウンストリーム MySQL インスタンスに接続するために必要な CA 証明書ファイルのパス (オプション)。
ssl-certダウンストリーム MySQL インスタンスに接続するために必要な証明書ファイルのパス (オプション)。
ssl-keyダウンストリーム MySQL インスタンスに接続するために必要な証明書キー ファイルのパス (オプション)。
time-zone下流のMySQLインスタンスへの接続時に使用するタイムゾーン。v4.0.8以降で有効です。これはオプションパラメータです。このパラメータが指定されていない場合は、TiCDCサービスプロセスのタイムゾーンが使用されます。このパラメータが空の値(例: time-zone="" )に設定されている場合、TiCDCが下流のMySQLインスタンスに接続する際にタイムゾーンは指定されず、下流のデフォルトのタイムゾーンが使用されます。
transaction-atomicityトランザクションのアトミック性レベル。これはオプションのパラメータで、デフォルト値はnoneです。値がtable場合、TiCDC は単一テーブルトランザクションのアトミック性を保証します。値がnoneの場合、TiCDC は単一テーブルトランザクションを分割します。
batch-dml-enableバッチ書き込み (batch-dml) 機能を有効にします (オプション、デフォルト値はtrue )。
read-timeoutgo-sql-driver パラメータ、 I/O読み取りタイムアウト (オプション、デフォルト値は2m )。
write-timeoutgo-sql-driver パラメータ、 I/O書き込みタイムアウト (オプション、デフォルト値は2m )。
timeoutgo-sql-driver パラメータ接続を確立するためのタイムアウトはダイヤル タイムアウトとも呼ばれます (オプション、デフォルト値は2m )。
tidb-txn-modetidb_txn_mode環境変数を指定します (オプション、デフォルト値はoptimistic )。
safe-modeTiCDC がダウンストリームにデータを複製するときにINSERTおよびUPDATEステートメントを処理する方法を指定します。 trueの場合、 TiCDC はアップストリームのINSERTステートメントすべてをREPLACE INTOステートメントに変換し、 UPDATEステートメントすべてをDELETE + REPLACE INTOステートメントに変換します。 v6.1.3 より前では、このパラメーターのデフォルト値はtrueです。 v6.1.3 以降では、デフォルト値はfalseに変更されます。 TiCDC が起動すると、現在のタイムスタンプThresholdTs取得します。 CommitTsThresholdTsより小さいINSERTおよびUPDATEステートメントの場合、 TiCDC はそれらをそれぞれREPLACE INTOステートメントとDELETE + REPLACE INTOステートメントに変換します。 CommitTsThresholdTs以上であるINSERTおよびUPDATEステートメントの場合、 INSERTステートメントはダウンストリームに直接複製されますが、 UPDATEステートメントの動作はTiCDC の UPDATE イベントの分割動作に従います。

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

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

エンコードされたパスワードはMTIzNDU2です:

MTIzNDU2

注記:

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

ダウンストリームデータベースユーザーに必要な権限

TiDB またはその他の MySQL 互換データベースにデータを複製するには、ダウンストリーム データベース ユーザーに次の権限が必要です。

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

RECOVER TABLEダウンストリーム TiDB に複製するには、ダウンストリーム データベース ユーザーにSuper権限も必要です。

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

災害シナリオにおける最終的に一貫性のあるレプリケーション

この機能はv6.1.1以降でGAとなります。v5.3.0以降、TiCDCは上流TiDBクラスターから下流クラスターのオブジェクトstorageまたはNFSへの増分データのバックアップをサポートします。上流クラスターが災害に見舞われて利用できなくなった場合でも、TiCDCは下流データを最新の結果整合性のある状態に復元できます。これは、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のみに指定できます。

このページは役に立ちましたか?