TiDB から MySQL 互換データベースにデータを移行する
このドキュメントでは、TiDB クラスターからAurora、MySQL、MariaDB などの MySQL 互換データベースにデータを移行する方法について説明します。プロセス全体には、次の 4 つのステップが含まれます。
- 環境を設定します。
- 全データを移行します。
- 増分データを移行します。
- サービスを MySQL 互換クラスターに移行します。
ステップ1. 環境を設定する
TiDB クラスターをアップストリームにデプロイ。
TiUP Playground を使用して TiDB クラスターをデプロイ。詳細については、 TiUPを使用してオンライン TiDBクラスタをデプロイおよび管理を参照してください。
# Create a TiDB cluster tiup playground --db 1 --pd 1 --kv 1 --tiflash 0 --ticdc 1 # View cluster status tiup statusMySQL インスタンスをダウンストリームにデプロイ。
ラボ環境では、Docker を使用して次のコマンドを実行することで、MySQL インスタンスをすばやくデプロイできます。
docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -p 3306:3306 -d mysql本番環境では、 MySQLのインストール手順に従って MySQL インスタンスをデプロイできます。
サービスのワークロードをシミュレートします。
ラボ環境では、
go-tpc使用して TiDB クラスターのアップストリームにデータを書き込むことができます。これは、TiDB クラスターでイベントの変更を生成するためです。次のコマンドを実行して、TiDB クラスターにtpccという名前のデータベースを作成し、 TiUPベンチを使用してこのデータベースにデータを書き込みます。tiup bench tpcc -H 127.0.0.1 -P 4000 -D tpcc --warehouses 4 prepare tiup bench tpcc -H 127.0.0.1 -P 4000 -D tpcc --warehouses 4 run --time 300sgo-tpcの詳細についてはTiDB で TPC-C テストを実行する方法を参照してください。
ステップ2. 全データを移行する
環境を設定したら、 Dumpling使用して上流の TiDB クラスターから完全なデータをエクスポートできます。
注記：
本番クラスターでは、GC を無効にしてバックアップを実行すると、クラスターのパフォーマンスに影響する可能性があります。この手順は、オフピーク時に完了することをお勧めします。
ガベージコレクション (GC) を無効にします。
増分移行中に新しく書き込まれたデータが削除されないようにするには、完全なデータをエクスポートする前に、アップストリーム クラスターの GC を無効にする必要があります。この方法では、履歴データは削除されません。TiDB v4.0.0 以降のバージョンでは、 Dumpling がGC時間を自動的に延長するなる可能性があります。ただし、 Dumplingの終了後に 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)バックアップデータ。
Dumplingを使用して SQL 形式でデータをエクスポートします。
tiup dumpling -u root -P 4000 -h 127.0.0.1 --filetype sql -t 8 -o ./dumpling_output -r 200000 -F256MiBデータのエクスポートが完了したら、次のコマンドを実行してメタデータを確認します。メタデータの
Posエクスポート スナップショットの TSO であり、BackupTS として記録できます。cat dumpling_output/metadataStarted dump at: 2022-06-28 17:49:54 SHOW MASTER STATUS: Log: tidb-binlog Pos: 434217889191428107 GTID: Finished dump at: 2022-06-28 17:49:57
データを復元します。
MyLoader (オープンソース ツール) を使用して、ダウンストリーム MySQL インスタンスにデータをインポートします。MyLoader のインストール方法と使用方法の詳細については、 マイダンプラー/マイローダーを参照してください。MyLoader v0.10 以前のバージョンを使用する必要があることに注意してください。それ以降のバージョンでは、 Dumplingによってエクスポートされたメタデータ ファイルを処理できません。
Dumplingによってエクスポートされた完全なデータを MySQL にインポートするには、次のコマンドを実行します。
myloader -h 127.0.0.1 -P 3306 -d ./dumpling_output/(オプション) データを検証します。
同期差分インスペクター使用すると、特定の時点でのアップストリームとダウンストリーム間のデータの一貫性をチェックできます。
sync_diff_inspector -C ./config.yamlsync-diff-inspector の設定方法の詳細については、 コンフィグレーションファイルの説明参照してください。このドキュメントでは、設定は次のとおりです。
# Diff Configuration. ######################### Datasource config ######################### [data-sources] [data-sources.upstream] host = "127.0.0.1" # Replace the value with the IP address of your upstream cluster port = 4000 user = "root" password = "" snapshot = "434217889191428107" # Set snapshot to the actual backup time (BackupTS in the "Back up data" section in [Step 2. Migrate full data](#step-2-migrate-full-data)) [data-sources.downstream] host = "127.0.0.1" # Replace the value with the IP address of your downstream cluster port = 3306 user = "root" password = "" ######################### Task config ######################### [task] output-dir = "./output" source-instances = ["upstream"] target-instance = "downstream" target-check-tables = ["*.*"]
ステップ3. 増分データを移行する
TiCDC をデプロイ。
完全なデータ移行が完了したら、増分データをレプリケートするための TiCDC クラスターをデプロイして構成します。本番環境では、 TiCDC をデプロイ手順に従って TiCDC をデプロイします。このドキュメントでは、テスト クラスターの作成時に TiCDC ノードが起動されています。したがって、TiCDC をデプロイする手順をスキップして、次の手順に進み、変更フィードを作成できます。
変更フィードを作成します。
アップストリーム クラスターで次のコマンドを実行して、アップストリーム クラスターからダウンストリーム クラスターへの変更フィードを作成します。
tiup cdc:v<CLUSTER_VERSION> cli changefeed create --server=http://127.0.0.1:8300 --sink-uri="mysql://root:@127.0.0.1:3306" --changefeed-id="upstream-to-downstream" --start-ts="434217889191428107"このコマンドのパラメータは次のとおりです。
--server: TiCDC クラスター内の任意のノードの IP アドレス--sink-uri: ダウンストリーム クラスターの URI--changefeed-id: チェンジフィードID、正規表現の形式でなければなりません、^[a-zA-Z0-9]+(\-[a-zA-Z0-9]+)*$--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. サービスを移行する
チェンジフィードを作成すると、アップストリーム クラスターに書き込まれたデータは、低レイテンシーでダウンストリーム クラスターにレプリケートされます。読み取りトラフィックをダウンストリーム クラスターに徐々に移行できます。一定期間、読み取りトラフィックを観察します。ダウンストリーム クラスターが安定している場合は、次の手順で書き込みトラフィックもダウンストリーム クラスターに移行できます。
アップストリーム クラスターの書き込みサービスを停止します。変更フィードを停止する前に、すべてのアップストリーム データがダウンストリームに複製されていることを確認してください。
# Stop the changefeed from the upstream cluster to the downstream cluster tiup cdc cli changefeed pause -c "upstream-to-downstream" --pd=http://172.16.6.122:2379 # View the changefeed status tiup cdc cli changefeed list[ { "id": "upstream-to-downstream", "summary": { "state": "stopped", # Ensure that the status is stopped "tso": 434218657561968641, "checkpoint": "2022-06-28 18:38:45.685", # This time should be later than the time of stopping writing "error": null } } ]書き込みサービスをダウンストリーム クラスターに移行した後、しばらく観察します。ダウンストリーム クラスターが安定している場合は、アップストリーム クラスターを破棄できます。