プライマリ クラスタとセカンダリ クラスタの間でデータをレプリケートする
このドキュメントでは、TiDB プライマリ (アップストリーム) クラスターと TiDB または MySQL セカンダリ (ダウンストリーム) クラスターを構成し、プライマリ クラスターからセカンダリ クラスターに増分データをレプリケートする方法について説明します。このプロセスには、次の手順が含まれます。
- TiDB プライマリ クラスタと TiDB または MySQL セカンダリ クラスタを構成します。
- プライマリ クラスタからセカンダリ クラスタに増分データをレプリケートします。
- プライマリ クラスタがダウンしている場合は、REDO ログを使用してデータを一貫して回復します。
実行中の TiDB クラスターからその二次クラスターに増分データを複製するには、バックアップと復元ブラジルおよびTiCDCを使用できます。
ステップ 1. 環境をセットアップする
TiDB クラスターをデプロイします。
デプロイ Playground を使用して、2 つの TiDB クラスター (1 つはアップストリーム、もう 1 つはダウンストリーム) をデプロイします。本番環境の場合は、 TiUP を使用してオンライン TiDBクラスタをデプロイおよび管理するを参照してクラスターをデプロイします。
このドキュメントでは、2 つのクラスターを 2 台のマシンにデプロイします。
ノード A: 172.16.6.123、上流の TiDB クラスターをデプロイするため
ノード B: 172.16.6.124、ダウンストリーム TiDB クラスターのデプロイ用
# Create an upstream cluster on Node A tiup --tag upstream playground --host 0.0.0.0 --db 1 --pd 1 --kv 1 --tiflash 0 --ticdc 1 # Create a downstream cluster on Node B tiup --tag downstream playground --host 0.0.0.0 --db 1 --pd 1 --kv 1 --tiflash 0 --ticdc 0 # View cluster status tiup statusデータを初期化します。
デフォルトでは、新しくデプロイされたクラスターにテスト データベースが作成されます。したがって、 シスベンチを使用してテスト データを生成し、実際のシナリオでデータをシミュレートできます。
sysbench oltp_write_only --config-file=./tidb-config --tables=10 --table-size=10000 prepareこのドキュメントでは、sysbench を使用して
oltp_write_onlyスクリプトを実行します。このスクリプトは、アップストリーム データベースに、それぞれ 10,000 行の 10 個のテーブルを生成します。 tidb-config は次のとおりです。mysql-host=172.16.6.122 # Replace it with the IP address of your upstream cluster mysql-port=4000 mysql-user=root mysql-password= db-driver=mysql # Set database driver to MySQL mysql-db=test # Set the database as a test database report-interval=10 # Set data collection period to 10s threads=10 # Set the number of worker threads to 10 time=0 # Set the time required for executing the script. O indicates time unlimited rate=100 # Set average TPS to 100サービスのワークロードをシミュレートします。
実際のシナリオでは、サービス データはアップストリーム クラスターに継続的に書き込まれます。このドキュメントでは、sysbench を使用してこのワークロードをシミュレートします。具体的には、次のコマンドを実行して、合計 TPS が 100 を超えないように、10 人のワーカーが sbtest1、sbtest2、および sbtest3 の 3 つのテーブルに連続してデータを書き込むことができるようにします。
sysbench oltp_write_only --config-file=./tidb-config --tables=3 run外部ストレージを準備します。
フル データ バックアップでは、アップストリーム クラスタとダウンストリーム クラスタの両方がバックアップ ファイルにアクセスする必要があります。 外部記憶装置を使用してバックアップ ファイルを保存することをお勧めします。この例では、Minio を使用して S3 互換のストレージ サービスをシミュレートします。
wget https://dl.min.io/server/minio/release/linux-amd64/minio chmod +x minio # Configure access-key access-screct-id to access minio export HOST_IP='172.16.6.123' # Replace it with the IP address of your upstream cluster export MINIO_ROOT_USER='minio' export MINIO_ROOT_PASSWORD='miniostorage' # Create the redo and backup directories. `backup` and `redo` are bucket names. mkdir -p data/redo mkdir -p data/backup # Start minio at port 6060 nohup ./minio server ./data --address :6060 &上記のコマンドは、S3 サービスをシミュレートするために、1 つのノードで minioサーバーを開始します。コマンドのパラメーターは次のように構成されます。
- エンドポイント:
http://${HOST_IP}:6060/ - アクセスキー:
minio - シークレット アクセス キー:
miniostorage - バケツ:
redo
リンクは次のとおりです。
s3://backup?access-key=minio&secret-access-key=miniostorage&endpoint=http://${HOST_IP}:6060&force-path-style=true- エンドポイント:
ステップ 2. 完全なデータを移行する
環境をセットアップした後、 ブラジル ) のバックアップおよび復元関数を使用して、完全なデータを移行できます。 BRは3つの方法で起動できます。このドキュメントでは、SQL ステートメントBACKUPとRESTOREを使用します。
ノート：
実稼働クラスターでは、GC を無効にしてバックアップを実行すると、クラスターのパフォーマンスに影響を与える可能性があります。オフピーク時にデータをバックアップし、パフォーマンスの低下を避けるために RATE_LIMIT を適切な値に設定することをお勧めします。
上流と下流のクラスターのバージョンが異なる場合は、 BR互換性を確認する必要があります。このドキュメントでは、アップストリーム クラスタとダウンストリーム クラスタは同じバージョンであると想定しています。
GC を無効にします。
増分移行中に新しく書き込まれたデータが削除されないようにするには、バックアップの前にアップストリーム クラスターの GC を無効にする必要があります。このように、履歴データは削除されません。
次のコマンドを実行して、GC を無効にします。
MySQL [test]> SET GLOBAL tidb_gc_enable=FALSE;Query OK, 0 rows affected (0.01 sec)変更が有効であることを確認するには、
tidb_gc_enableの値をクエリします。MySQL [test]> SELECT @@global.tidb_gc_enable;+-------------------------+ | @@global.tidb_gc_enable | +-------------------------+ | 0 | +-------------------------+ 1 row in set (0.00 sec)バックアップデータ。
アップストリーム クラスターで
BACKUPステートメントを実行して、データをバックアップします。MySQL [(none)]> BACKUP DATABASE * TO 's3://backup?access-key=minio&secret-access-key=miniostorage&endpoint=http://${HOST_IP}:6060&force-path-style=true' RATE_LIMIT = 120 MB/SECOND;+----------------------+----------+--------------------+---------------------+---------------------+ | Destination | Size | BackupTS | Queue Time | Execution Time | +----------------------+----------+--------------------+---------------------+---------------------+ | local:///tmp/backup/ | 10315858 | 431434047157698561 | 2022-02-25 19:57:59 | 2022-02-25 19:57:59 | +----------------------+----------+--------------------+---------------------+---------------------+ 1 row in set (2.11 sec)BACKUPコマンドの実行後、TiDB はバックアップ データに関するメタデータを返します。バックアップされる前に生成されたデータであるため、BackupTSに注意してください。このドキュメントでは、データ チェックの終了とTiCDC による増分移行スキャンの開始としてBackupTSを使用します。データを復元します。
ダウンストリーム クラスターで
RESTOREコマンドを実行して、データを復元します。mysql> RESTORE DATABASE * FROM 's3://backup?access-key=minio&secret-access-key=miniostorage&endpoint=http://${HOST_IP}:6060&force-path-style=true';+----------------------+----------+--------------------+---------------------+---------------------+ | Destination | Size | BackupTS | Queue Time | Execution Time | +----------------------+----------+--------------------+---------------------+---------------------+ | local:///tmp/backup/ | 10315858 | 431434141450371074 | 2022-02-25 20:03:59 | 2022-02-25 20:03:59 | +----------------------+----------+--------------------+---------------------+---------------------+ 1 row in set (41.85 sec)(オプション) データを検証します。
特定の時点で上流と下流の間のデータの整合性をチェックするには、 同期差分インスペクターを使用します。前の
BACKUPの出力は、上流のクラスターがRESTOREでバックアップを終了したことを示しています。sync_diff_inspector -C ./config.yamlsync-diff-inspector の構成方法の詳細については、 Configuration / コンフィグレーションファイルの説明を参照してください。このドキュメントでは、構成は次のとおりです。
# Diff Configuration. ######################### Global config ######################### check-thread-count = 4 export-fix-sql = true check-struct-only = false ######################### Datasource config ######################### [data-sources] [data-sources.upstream] host = "172.16.6.123" # Replace it with the IP address of your upstream cluster port = 4000 user = "root" password = "" snapshot = "431434047157698561" # Set snapshot to the actual backup time [data-sources.downstream] host = "172.16.6.124" # Replace the value with the IP address of your downstream cluster port = 4000 user = "root" password = "" snapshot = "431434141450371074" # Set snapshot to the actual restore time ######################### Task config ######################### [task] output-dir = "./output" source-instances = ["upstream"] target-instance = "downstream" target-check-tables = ["*.*"]
ステップ 3. 増分データを移行する
TiCDC をデプロイします。
完全なデータ移行が完了したら、TiCDC を展開して構成し、増分データをレプリケートします。本番環境では、 TiCDC をデプロイの指示に従って TiCDC をデプロイします。このドキュメントでは、テスト クラスターの作成時に TiCDC ノードが開始されています。したがって、TiCDC をデプロイするステップをスキップして、changefeed 構成に進みます。
チェンジフィードを作成します。
changefeed 構成ファイルを作成します
changefeed.toml。[consistent] # Consistency level, eventual means enabling consistent replication level = "eventual" # Use S3 to store redo logs. Other options are local and nfs. storage = "s3://redo?access-key=minio&secret-access-key=miniostorage&endpoint=http://172.16.6.125:6060&force-path-style=true"アップストリーム クラスターで、次のコマンドを実行して、アップストリーム クラスターからダウンストリーム クラスターへの変更フィードを作成します。
tiup cdc cli changefeed create --pd=http://172.16.6.122:2379 --sink-uri="mysql://root:@172.16.6.125:4000" --changefeed-id="primary-to-secondary" --start-ts="431434047157698561"このコマンドでは、パラメーターは次のとおりです。
--pd: アップストリーム クラスタの PD アドレス--sink-uri: ダウンストリーム クラスターの URI--start-ts: 変更フィードの開始タイムスタンプ。バックアップ時刻 (またはステップ 2. 完全なデータを移行するで説明した BackupTS) である必要があります。
changefeed 構成の詳細については、 タスク構成ファイルを参照してください。
GC を有効にします。
TiCDC を使用した増分移行では、GC はレプリケートされた履歴データのみを削除します。したがって、変更フィードを作成した後、次のコマンドを実行して GC を有効にする必要があります。詳細については、 TiCDC ガベージ コレクション (GC) セーフポイントの完全な動作は何ですか?を参照してください。
GC を有効にするには、次のコマンドを実行します。
MySQL [test]> SET GLOBAL tidb_gc_enable=TRUE;Query OK, 0 rows affected (0.01 sec)変更が有効であることを確認するには、
tidb_gc_enableの値をクエリします。MySQL [test]> SELECT @@global.tidb_gc_enable;+-------------------------+ | @@global.tidb_gc_enable | +-------------------------+ | 1 | +-------------------------+ 1 row in set (0.00 sec)
ステップ 4.アップストリーム クラスターで災害をシミュレートする
実行中にアップストリーム クラスタで悲惨なイベントを作成します。たとえば、Ctrl+C を押すと、tiup プレイグラウンド プロセスを終了できます。
ステップ 5. REDO ログを使用してデータの整合性を確保する
通常、TiCDC はトランザクションを同時にダウンストリームに書き込み、スループットを向上させます。変更フィードが予期せず中断された場合、ダウンストリームはアップストリームのように最新のデータを持っていない可能性があります。不整合に対処するには、次のコマンドを実行して、ダウンストリーム データがアップストリーム データと一致していることを確認します。
tiup cdc redo apply --storage "s3://redo?access-key=minio&secret-access-key=miniostorage&endpoint=http://172.16.6.123:6060&force-path-style=true" --tmp-dir /tmp/redo --sink-uri "mysql://root:@172.16.6.124:4000"
--storage: S3 の REDO ログの場所と資格情報--tmp-dir: S3 からダウンロードした REDO ログのキャッシュ ディレクトリ--sink-uri: ダウンストリーム クラスターの URI
ステップ 6. 主クラスターとそのサービスをリカバリーする
前のステップの後、ダウンストリーム (セカンダリ) クラスターには、特定の時点でアップストリーム (プライマリ) クラスターと一致するデータがあります。データの信頼性を確保するために、新しいプライマリ クラスタとセカンダリ クラスタを設定する必要があります。
ノード A に新しい TiDB クラスターを新しい主クラスターとしてデプロイします。
tiup --tag upstream playground v5.4.0 --host 0.0.0.0 --db 1 --pd 1 --kv 1 --tiflash 0 --ticdc 1BR を使用して、二次クラスターから一次クラスターにデータを完全にバックアップおよび復元します。
# Back up full data of the secondary cluster tiup br --pd http://172.16.6.124:2379 backup full --storage ./backup # Restore full data of the secondary cluster tiup br --pd http://172.16.6.123:2379 restore full --storage ./backupプライマリ クラスタからセカンダリ クラスタにデータをバックアップするための新しい変更フィードを作成します。
# Create a changefeed tiup cdc cli changefeed create --pd=http://172.16.6.122:2379 --sink-uri="mysql://root:@172.16.6.125:4000" --changefeed-id="primary-to-secondary"