重要

TiDB v6.2 (DMR) のドキュメントを表示しています。PingCap は v6.2 のバグ修正を提供していません。バグは将来のリリースで修正される予定です。

一般的な目的では、TiDBデータベースの最新の安定バージョンを使用してください。
重要
このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

TiDB から MySQL 互換データベースにデータを移行する

このドキュメントでは、TiDB クラスターからAurora、MySQL、MariaDB などの MySQL 互換データベースにデータを移行する方法について説明します。プロセス全体には、次の 4 つのステップが含まれます。

  1. 環境をセットアップします。
  2. 完全なデータを移行します。
  3. 増分データを移行します。
  4. サービスを MySQL 互換クラスターに移行します。

ステップ 1. 環境をセットアップする

  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 status
    
  2. MySQL インスタンスをダウンストリームにデプロイします。

    • ラボ環境では、次のコマンドを実行することで、Docker を使用して MySQL インスタンスをすばやくデプロイできます。

      docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -p 3306:3306 -d mysql
      
    • 本番環境では、 MySQL のインストールの手順に従って MySQL インスタンスをデプロイできます。

  3. サービスのワークロードをシミュレートします。

    ラボ環境では、 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 300s
    

    go-tpcの詳細については、 TiDB で TPC-C テストを実行する方法を参照してください。

ステップ 2. 完全なデータを移行する

環境をセットアップしたら、 Dumplingを使用してアップストリームの TiDB クラスターから完全なデータをエクスポートできます。

ノート:

実稼働クラスターでは、GC を無効にしてバックアップを実行すると、クラスターのパフォーマンスに影響を与える可能性があります。この手順は、オフピーク時に完了することをお勧めします。

  1. ガベージ コレクション (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)
    
  2. バックアップデータ。

    1. Dumplingを使用して SQL 形式でデータをエクスポートします。

      tiup dumpling -u root -P 4000 -h 127.0.0.1 --filetype sql -t 8 -o ./dumpling_output -r 200000 -F256MiB
      
    2. データのエクスポートが完了したら、次のコマンドを実行してメタデータを確認します。メタデータのPosは、エクスポート スナップショットの TSO であり、BackupTS として記録できます。

      cat dumpling_output/metadata
      
      Started 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
      
  3. データを復元します。

    MyLoader (オープンソース ツール) を使用して、ダウンストリームの MySQL インスタンスにデータをインポートします。 MyLoader のインストール方法と使用方法の詳細については、 マイダンプラー/マイローダーを参照してください。 Dumplingによって MySQL にエクスポートされた完全なデータをインポートするには、次のコマンドを実行します。

    myloader -h 127.0.0.1 -P 3306 -d ./dumpling_output/
    
  4. (オプション) データを検証します。

    同期差分インスペクターを使用して、特定の時点で上流と下流の間のデータの整合性を確認できます。

    sync_diff_inspector -C ./config.yaml
    

    sync-diff-inspector の構成方法の詳細については、 Configuration / コンフィグレーションファイルの説明を参照してください。このドキュメントでは、構成は次のとおりです。

    # 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. 増分データを移行する

  1. TiCDC をデプロイします。

    完全なデータ移行が完了したら、TiCDC クラスターをデプロイして構成し、増分データをレプリケートします。本番環境では、 TiCDC をデプロイの指示に従って TiCDC をデプロイします。このドキュメントでは、テスト クラスターの作成時に TiCDC ノードが開始されています。したがって、TiCDC をデプロイするステップをスキップして、次のステップに進んで変更フィードを作成できます。

  2. チェンジフィードを作成します。

    アップストリーム クラスターで、次のコマンドを実行して、アップストリーム クラスターからダウンストリーム クラスターへの変更フィードを作成します。

    tiup ctl:v6.1.0 cdc changefeed create --pd=http://127.0.0.1:2379 --sink-uri="mysql://root:@127.0.0.1:3306" --changefeed-id="upstream-to-downstream" --start-ts="434217889191428107"
    

    このコマンドでは、パラメーターは次のとおりです。

    • --pd : アップストリーム クラスタの PD アドレス
    • --sink-uri : ダウンストリーム クラスターの URI
    • --changefeed-id : 変更フィード ID。正規表現の形式にする必要があります^[a-zA-Z0-9]+(\-[a-zA-Z0-9]+)*$
    • --start-ts : 変更フィードの開始タイムスタンプ。バックアップ時間 (またはステップ 2. 完全なデータを移行するの「データのバックアップ」セクションの BackupTS) である必要があります。

    changefeed 構成の詳細については、 タスク構成ファイルを参照してください。

  3. 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. サービスを移行する

変更フィードの作成後、アップストリーム クラスターに書き込まれたデータは、低レイテンシーでダウンストリーム クラスターにレプリケートされます。読み取りトラフィックをダウンストリーム クラスターに段階的に移行できます。一定期間、読み取りトラフィックを観察します。ダウンストリーム クラスターが安定している場合は、次の手順で書き込みトラフィックをダウンストリーム クラスターに移行することもできます。

  1. アップストリーム クラスタの書き込みサービスを停止します。変更フィードを停止する前に、すべてのアップストリーム データがダウンストリームに複製されていることを確認してください。

    # 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
        }
      }
    ]
    
  2. 書き込みサービスをダウンストリーム クラスターに移行した後、しばらく観察します。ダウンストリーム クラスターが安定している場合は、アップストリーム クラスターを破棄できます。