データ移行を使用してMySQL互換データベースをTiDB Cloudに移行する

このドキュメントでは、TiDB Cloud のデータ移行機能を使用して、Amazon Aurora MySQL、Amazon RDS、Azure Database for MySQL - Flexible Server、Google Cloud SQL for MySQL、またはセルフマネージド MySQL インスタンスからTiDB Cloud Dedicated へ MySQL TiDB Cloudコンソールを移行する手順を説明します。

この機能により、既存のMySQLデータを移行し、MySQL互換のソースデータベースからTiDB Cloudへ進行中の変更（binlog）を継続的にレプリケートできます。これにより、同一リージョン内または異なるリージョン間でデータの一貫性が維持されます。合理化されたプロセスにより、個別のダンプおよびロード操作が不要になり、ダウンタイムが短縮され、MySQLからよりスケーラブルなプラットフォームへの移行が簡素化されます。

進行中のbinlogの変更を MySQL 互換データベースからTiDB Cloudにレプリケートするだけの場合は、 データ移行を使用して、MySQL互換データベースからTiDB Cloudへ増分データを移行する参照してください。

制限事項

可用性

• 現在、 TiDB Cloud Starterではデータ移行機能は利用できません。

• TiDB CloudコンソールにTiDB Cloud Dedicatedクラスターのデータ移行エントリーが表示されない場合、その機能はお住まいの地域で利用できない可能性があります。お住まいの地域のサポートをリクエストするには、 TiDB Cloudサポートにお問い合わせください。

• Amazon Aurora MySQL ライターインスタンスは、既存データ移行と増分データ移行の両方をサポートします。Amazon Aurora MySQL リーダーインスタンスは、既存データ移行のみをサポートし、増分データ移行はサポートしません。

移行ジョブの最大数

TiDB Cloud Dedicatedクラスターでは、組織ごとに最大 200 個の移行ジョブを作成できます。さらに移行ジョブを作成するには、サポートチケットを提出する必要があります。

フィルタリングおよび削除されたデータベース

• システムデータベースは、移行するデータベースをすべて選択した場合でも、フィルタリングされてTiDB Cloudに移行されません。つまり、 mysql 、 information_schema 、 performance_schema 、およびsysは、この機能を使用して移行されません。

• TiDB CloudでTiDB Cloud Dedicatedクラスタを削除すると、そのクラスタ内のすべての移行ジョブが自動的に削除され、復元できなくなります。

既存のデータ移行の限界

• 既存データの移行中に、移行対象のテーブルが移行先のデータベースに既に存在し、かつ重複するキーがある場合、重複するキーを持つ行は置き換えられます。

• TiDB Cloud Dedicatedの場合、データセット サイズが 1 TiB より小さい場合は、論理モード (デフォルト モード) を使用することをお勧めします。データセットのサイズが 1 TiB より大きい場合、または既存のデータをより速く移行したい場合は、物理モードを使用できます。詳細については、既存データと増分データを移行する参照してください。

増分データ移行の限界

• 増分データ移行中に、移行対象のテーブルが既にターゲットデータベースに重複キーで存在する場合、エラーが報告され、移行が中断されます。この場合、MySQLソースデータが正確であることを確認する必要があります。正確であれば、移行ジョブの「再開」ボタンをクリックすると、移行ジョブはターゲットTiDB Cloud Dedicatedクラスターで競合するレコードをMySQLソースレコードに置き換えます。

• 増分データ移行 (進行中の変更をTiDB Cloud Dedicatedクラスターに移行する) 中に、移行ジョブが突然のエラーから回復した場合、60 秒間セーフ モードが開くことがあります。セーフ モード中は、 INSERTステートメントがREPLACEとして、 UPDATEステートメントがDELETEおよびREPLACEとして移行され、その後、これらのトランザクションがターゲットのTiDB Cloud Dedicatedクラスターに移行され、突然のエラー中に発生したすべてのデータがターゲットのTiDB Cloud Dedicatedクラスターにスムーズに移行されたことが保証されます。このシナリオでは、プライマリキーやNULL値を含まない一意インデックスを持たないMySQLソーステーブルの場合、データがターゲットのTiDB Cloud Dedicatedクラスタに繰り返し挿入される可能性があるため、一部のデータがターゲットのTiDB Cloud Dedicatedクラスタで重複する可能性があります。

• 以下のシナリオでは、移行ジョブに24時間以上かかる場合、ソースデータベースのバイナリログを削除しないでください。これにより、データ移行ツールは増分データ移行のために連続したバイナリログを取得できます。

  • 既存のデータ移行中に。
  • 既存のデータ移行が完了し、増分データ移行が初めて開始された後、レイテンシーは0msになりません。

前提条件

移行する前に、データソースがサポートされているかどうかを確認し、MySQL互換データベースでバイナリログを有効にし、ネットワーク接続を確保し、ソースデータベースとターゲットTiDB Cloud DedicatedクラスターとTiDB Cloud Essentialの両方に必要な権限を付与してくださいデータベース。

データソースとバージョンがサポートされていることを確認してください。

TiDB Cloud Dedicated のデータ移行機能は、以下のデータソースとバージョンをサポートしています。

レプリケーションのために、ソースのMySQL互換データベースでバイナリログを有効にする

DM を使用して、ソースの MySQL 互換データベースからターゲットのTiDB Cloud Dedicatedクラスターに増分変更を継続的にレプリケートするには、ソース データベースでバイナリ ログを有効にするために次の構成が必要です。

現在の値を確認し、ソースのMySQLインスタンスを設定します。

現在の設定を確認するには、ソースのMySQLインスタンスに接続し、次のステートメントを実行します。

SHOW VARIABLES WHERE Variable_name IN
('log_bin','server_id','binlog_format','binlog_row_image',
'binlog_expire_logs_seconds','expire_logs_days','binlog_transaction_compression');

必要に応じて、ソースのMySQLインスタンスの設定を変更して、必要な値と一致するようにしてください。

ネットワーク接続を確保する

移行ジョブを作成する前に、ソース MySQL インスタンス、 TiDB Cloudデータ マイグレーション (DM) サービス、およびターゲットTiDB Cloud Dedicatedクラスターの間の適切なネットワーク接続を計画し、設定する必要があります。

TiDB Cloud Dedicatedで利用可能な接続方法は以下のとおりです。

ご利用のクラウドプロバイダー、ネットワーク構成、およびセキュリティ要件に最適な接続方法を選択し、その方法の設定手順に従ってください。

TLS/SSLによるエンドツーエンド暗号化

接続方法に関わらず、エンドツーエンド暗号化にはTLS/SSLの使用を強く推奨します。プライベートエンドポイントおよびVPCピアリングネットワークパスを保護しますが、TLS/SSLはデータ自体を保護し、コンプライアンス要件を満たすのに役立ちます。

公開エンドポイントまたはIPアドレス

パブリックエンドポイントを使用する場合、ネットワーク接続とアクセスは、DMジョブ作成プロセス中、現在と後の両方で確認できます。TiDB Cloudは、その時点で特定の送信IPアドレスと指示を提供します。

注記：

ファイアウォールの送信側IPアドレス範囲は、データ移行タスクの作成時にのみ利用可能です。このIPアドレス範囲を事前に取得することはできません。開始する前に、以下の点を確認してください。

• ファイアウォールルールを変更する権限が必要です。
• セットアッププロセス中に、クラウドプロバイダーのコンソールにアクセスできます。
• タスク作成ワークフローを一時停止して、ファイアウォールを設定できます。

1. ソースとなるMySQLインスタンスのエンドポイントホスト名（FQDN）またはパブリックIPアドレスを特定し、記録します。

2. データベースのファイアウォールまたはセキュリティグループのルールを変更するには、必要な権限が付与されていることを確認してください。詳細については、クラウドプロバイダーのドキュメントを参照してください。

   • Amazon Aurora MySQL または Amazon RDS MySQL: セキュリティグループによるアクセス制御。
   • Azure Database for MySQL - フレキシブル サーバー: 公共ネットワークアクセス
   • Google Cloud SQL for MySQL: 認証済みネットワーク。

3. オプション：適切な証明書を使用して転送中の暗号化を行い、パブリックインターネットアクセスを備えたマシンからソースデータベースへの接続を確認します。

   mysql -h <public-host> -P <port> -u <user> -p --ssl-ca=<path-to-provider-ca.pem> -e "SELECT version();"
   

4. 後ほど、データ移行ジョブの設定時に、 TiDB Cloud送信元IPアドレス範囲が提供されます。その際、上記と同じ手順に従って、このIPアドレス範囲をデータベースのファイアウォールまたはセキュリティグループのルールに追加する必要があります。

プライベートリンクまたはプライベートエンドポイント

プロバイダーネイティブのプライベートリンクまたはプライベートエンドポイントを使用する場合は、ソースのMySQLインスタンス（RDS、 Aurora、またはAzure Database for MySQL）用のプライベートエンドポイントを作成します。

VPCピアリング

AWS VPCピアリングまたはGoogle Cloud VPCネットワークピアリングを使用する場合は、以下の手順に従ってネットワークを設定してください。

移行に必要な権限を付与する

移行を開始する前に、ソースデータベースとターゲットデータベースの両方で、必要な権限を持つ適切なデータベースユーザーを設定する必要があります。これらの権限、 TiDB Cloud DM は MySQL からデータを読み取り、変更を複製し、 TiDB Cloud Dedicatedクラスターに安全に書き込むことができます。移行には、既存データの完全なデータダンプと増分変更のbinlog複製の両方が含まれるため、移行ユーザーには基本的な読み取りアクセス以外の特定の権限が必要です。

ソースMySQLデータベースで、移行ユーザーに必要な権限を付与します。

テスト目的では、ソースの MySQL データベースで管理者ユーザー ( rootなど) を使用できます。

本番のワークロードでは、ソースのMySQLデータベースにデータダンプとレプリケーション専用のユーザーを用意し、必要な権限のみを付与することをお勧めします。

例えば、ソースのMySQLインスタンスで次のGRANTステートメントを使用すると、対応する権限を付与できます。

GRANT SELECT, RELOAD, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'dm_source_user'@'%';

対象に必要な権限を付与するTiDB Cloud DedicatedクラスターTiDB Cloud Essentialインスタンス

テスト目的では、 TiDB Cloud Dedicatedクラスターインスタンスのrootアカウントを使用できます。

本番ワークロードの場合は、ターゲットTiDB Cloud Dedicatedクラスターでレプリケーション専用のユーザーを用意し、必要な権限のみを付与することをお勧めします。

たとえば、ターゲットのTiDB Cloud Dedicatedクラスターインスタンスで次のGRANTステートメントを実行して、対応する権限を付与できます。

GRANT CREATE, SELECT, INSERT, UPDATE, DELETE, ALTER, DROP, INDEX ON *.* TO 'dm_target_user'@'%';

ステップ1：データ移行ページに移動します

1. TiDB Cloudコンソールにログインし、私のTiDBページに移動します。

2. ターゲットのTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで[データ] > [データ移行]をクリックします。

3. データ移行ページで、右上隅にある「移行ジョブの作成」をクリックします。移行ジョブの作成ページが表示されます。

ステップ2：ソース接続とターゲット接続を設定する

「移行ジョブの作成」ページで、ソースとターゲットの接続を設定します。

1. 職名を入力してください。職名は文字で始まり、60文字以内である必要があります。文字（AZ、az）、数字（0～9）、アンダースコア（_）、ハイフン（-）が使用可能です。

2. ソース接続プロファイルを入力してください。

   • データソース：データソースの種類。

   • 接続方法：セキュリティ要件とクラウドプロバイダーに基づいて、データソースの接続方法を選択してください。

     • パブリックIP ：すべてのクラウドプロバイダーで利用可能（テストおよび概念実証移行に推奨）。
     • プライベートリンク：AWSおよびAzureでのみ利用可能（プライベート接続を必要とする本番ワークロードに推奨）。
     • VPCピアリング：AWSとGoogle Cloudでのみ利用可能です（低遅延でリージョン内接続が必要で、VPC/VNet CIDRが重複しない本番ロードに推奨されます）。

   • 選択した接続方法に基づいて、以下の手順を実行してください。

     • パブリックIPまたはVPCピアリングを選択した場合は、ホスト名またはIPアドレスのフィールドにデータソースのホスト名またはIPアドレスを入力してください。
     • 「プライベートリンク」を選択した場合は、以下の情報を入力してください。
       • エンドポイント サービス名(データ ソースがAWS の場合に利用可能): RDS またはAuroraインスタンス用に作成した VPC エンドポイント サービス名 (形式: com.amazonaws.vpce-svc-xxxxxxxxxxxxxxxxx ) を入力します。
       • プライベートエンドポイントリソースID （データソースがAzureの場合に利用可能）：MySQL Flexible ServerインスタンスのリソースIDを入力します（形式： /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.DBforMySQL/flexibleServers/<server> ）。

   • ポート：データソースのポート番号。

   • ユーザー名：データソースのユーザー名。

   • パスワード：ユーザー名のパスワード。

   • SSL/TLS ：エンドツーエンドのデータ暗号化のためにSSL/TLSを有効にします（すべての移行作業で強く推奨）。MySQLサーバーのSSL構成に基づいて、適切な証明書をアップロードしてください。

     SSL/TLS設定オプション：

     • オプション1：サーバー認証のみ

       • MySQLサーバーがサーバー認証のみに設定されている場合は、 CA証明書のみをアップロードしてください。
       • このオプションでは、MySQLサーバーが自身の証明書を提示して身元を証明し、 TiDB Cloudが認証局（CA）に対してサーバー証明書を検証します。
       • CA証明書は中間者攻撃から保護し、MySQLサーバーをrequire_secure_transport = ONで起動する場合に必要です。

     • オプション2：クライアント証明書認証

       • MySQLサーバーがクライアント証明書認証用に構成されている場合は、クライアント証明書とクライアント秘密鍵をアップロードしてください。
       • このオプションでは、 TiDB Cloudは認証のためにMySQLサーバーに証明書を提示しますが、 TiDB Cloudサーバーの証明書を検証しません。
       • このオプションは通常、MySQLサーバーがREQUIRE SUBJECT '...'やREQUIRE ISSUER '...'などのオプションで構成されているが、 REQUIRE X509含まれていない場合に使用され、クライアント証明書の完全な CA 検証を行わずに、クライアント証明書の特定の属性をチェックできるようにします。
       • このオプションは、MySQLサーバーが自己署名証明書またはカスタムPKI環境でクライアント証明書を受け入れる場合によく使用されます。ただし、この構成は中間者攻撃に対して脆弱であるため、他のネットワークレベルの制御によってサーバーの信頼性が保証されない限り、本番環境での本番は推奨されません。

     • オプション3：相互TLS（mTLS） - 最高レベルのセキュリティ

       • MySQLサーバーが相互TLS（mTLS）認証用に構成されている場合は、 CA証明書、クライアント証明書、およびクライアント秘密鍵をアップロードしてください。
       • このオプションでは、MySQLサーバーはクライアント証明書を使用してTiDB Cloudの身元を検証し、 TiDB CloudはCA証明書を使用してMySQLサーバーの身元を検証します。
       • このオプションは、MySQLサーバーで移行ユーザーに対してREQUIRE X509またはREQUIRE SSLが設定されている場合に必要です。
       • このオプションは、MySQLサーバーが認証のためにクライアント証明書を必要とする場合に使用されます。
       • 証明書は以下の情報源から入手できます。
         • クラウド プロバイダーからダウンロードします ( TLS証明書リンクを参照)。
         • 組織の内部認証局証明書を使用してください。
         • 自己署名証明書（開発／テスト専用）。

3. ターゲット接続プロファイルを入力してください。

   • ユーザー名: TiDB Cloud DedicatedクラスターTiDB Cloudのユーザー名を入力します。
   • パスワード： TiDB Cloudのユーザー名のパスワードを入力してください。

4. 入力した情報を検証するには、 「接続を検証」をクリックし、「次へ」をクリックしてください。

5. 表示されたメッセージに従って行動してください。

   • 接続方法としてパブリックIPまたはVPCピアリングを使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。
   • 接続方法としてプライベートリンクを使用する場合、エンドポイント要求を承認するよう求められます。
     • AWSの場合： AWS VPCコンソールに移動し、エンドポイントサービスをクリックして、 TiDB Cloudからのエンドポイントリクエストを承認します。
     • Azure の場合: Azureポータルに移動し、MySQL Flexible Server を名前で検索し、左側のナビゲーション ペインで[設定] > [ネットワーク]をクリックし、右側の[プライベート エンドポイント]セクションを見つけて、 TiDB Cloudからの保留中の接続要求を承認します。

ステップ3：移行ジョブの種類を選択する

「移行ジョブタイプの選択」ステップでは、既存データと増分データの両方を移行するか、既存データのみを移行するか、増分データのみを移行するかを選択できます。

既存データと増分データを移行する

TiDB Cloudへのデータ移行を一度で完了させるには、 「既存データ移行」と「増分データ移行」の両方を選択してください。これにより、ソースデータベースとターゲットデータベース間のデータの一貫性が確保されます。

既存データと増分データの移行には、物理​​モードまたは論理モードを使用できます。

• デフォルトモードは論理モードです。このモードでは、MySQLソースデータベースからSQLステートメントとしてデータをエクスポートし、TiDB上で実行します。このモードでは、移行前のターゲットテーブルは空でも空でなくても構いません。ただし、物理モードよりもパフォーマンスは低下します。

• 大規模なデータセットの場合は、物理モードの使用をお勧めします。このモードでは、MySQLソースデータベースからデータをエクスポートし、KVペアとしてエンコードしてTiKVに直接書き込むことで、パフォーマンスを向上させます。このモードでは、移行前にターゲットテーブルが空である必要があります。16 RCU（レプリケーション容量ユニット）の仕様の場合、パフォーマンスは論理モードの約2.5倍高速です。その他の仕様では、論理モードと比較してパフォーマンスが20%～50%向上する可能性があります。なお、パフォーマンスデータは参考値であり、シナリオによって異なる場合がありますのでご注意ください。

注記：

• 物理モードを使用する場合、既存のデータ移行が完了する前に、 TiDB Cloud Dedicatedクラスターの 2 番目の移行ジョブまたはインポート タスクを作成することはできません。
• 物理モードを使用し、移行ジョブが開始されたら、 TiDB Cloud Dedicatedクラスターで PITR (ポイントインタイムリカバリ) を有効にしたり、変更フィードを設定したりしないでくださいそうしないと、移行ジョブが停止します。PITR を有効にしたり、変更フィードを設定したりする必要がある場合は、代わりに論理モードを使用してデータを移行してください。

物理モードでは、MySQLソースデータを可能な限り高速にエクスポートするため、 異なる仕様データエクスポート時のMySQLソースデータベースのQPSとTPSに対するパフォーマンスへの影響が異なります。以下の表は、各仕様のパフォーマンス低下を示しています。

既存データのみを移行する

ソースデータベースの既存データのみをTiDB Cloudに移行するには、 「既存データの移行」を選択します。

物理モードまたは論理モードを使用して、既存のデータを移行できます。詳細については、既存データと増分データを移行する参照してください。

増分データのみを移行する

ソースデータベースの増分データのみをTiDB Cloudに移行するには、 「増分データ移行」を選択します。この場合、移行ジョブはソースデータベースの既存データをTiDB Cloudに移行せず、移行ジョブで明示的に指定されたソースデータベースの進行中の変更のみを移行します。

増分データ移行の詳細な手順については、 データ移行を使用して、MySQL互換データベースからTiDB Cloudへ増分データのみを移行する参照してください。

ステップ4：移行するオブジェクトを選択する

1. 「移行するオブジェクトの選択」ページで、移行するオブジェクトを選択します。 「すべて」をクリックするとすべてのオブジェクトを選択できます。 「カスタマイズ」をクリックしてから、オブジェクト名の横にあるチェックボックスをクリックしてオブジェクトを選択することもできます。

   • 「すべて」をクリックすると、移行ジョブはソースデータベースインスタンス全体から既存のデータをTiDB Cloudに移行し、完全移行後に進行中の変更も移行します。ただし、これは前の手順で「既存データの移行」と「増分データの移行」のチェックボックスを選択した場合にのみ実行されます。
   • 「カスタマイズ」をクリックしてデータベースを選択すると、移行ジョブによって既存のデータと選択したデータベースの進行中の変更がTiDB Cloudに移行されます。ただし、これは前の手順で「既存データの移行」と「増分データの移行」のチェックボックスを選択した場合にのみ実行されます。
   • 「カスタマイズ」をクリックしてデータベース名の下のテーブルを選択すると、移行ジョブは既存のデータと選択したテーブルの進行中の変更のみを移行します。同じデータベースで後から作成されたテーブルは移行されません。

2. 「次へ」をクリックしてください。

ステップ5：事前チェック

事前チェックページでは、事前チェックの結果を確認できます。事前チェックが失敗した場合は、 「失敗」または「警告」の詳細に従って問題を解決し、再度「チェック」をクリックして再チェックしてください。

チェック項目の一部にのみ警告が表示されている場合は、リスクを評価し、警告を無視するかどうかを検討できます。すべての警告を無視した場合、移行ジョブは自動的に次のステップに進みます。

エラーと解決策の詳細については、 事前チェックのエラーと解決策を参照してください。

事前チェック項目の詳細については、 移行タスクの事前チェック参照してください。

すべてのチェック項目が「合格」と表示されたら、 「次へ」をクリックしてください。

ステップ6：仕様を選択して移行を開始する

「仕様を選択して移行を開始」ページで、パフォーマンス要件に応じて適切な移行仕様を選択します。仕様の詳細については、 データ移行の仕様参照してください。

仕様を選択したら、 「ジョブの作成」をクリックし、「開始」をクリックして移行を開始します。

ステップ7：移行の進捗状況をビュー

移行ジョブが作成されると、移行ジョブの詳細ページで移行の進行状況を確認できます。移行の進行状況は、 「ステージ」と「ステータス」の領域に表示されます。

移行ジョブは、実行中でも一時停止または削除できます。

移行ジョブが失敗した場合は、問題を解決した後で再開できます。

移行ジョブはどのステータスでも削除できます。

移行中に問題が発生した場合は、 移行エラーとその解決策参照してください。

移行ジョブ仕様を拡張する

TiDB Cloud Dedicatedは、さまざまなシナリオにおけるパフォーマンスとコストの要件を満たすために、移行ジョブの仕様をスケールアップまたはスケールダウンすることをサポートします。

移行仕様によってパフォーマンスは異なります。パフォーマンス要件は、移行の段階によっても変化する可能性があります。例えば、既存データの移行中は、可能な限り高速なパフォーマンスが求められるため、8 RCUといった大規模な仕様の移行ジョブを選択します。既存データの移行が完了すると、増分移行ではそれほど高いパフォーマンスは必要ないため、例えば8 RCUから2 RCUへとジョブ仕様を縮小することでコストを削減できます。

移行ジョブの仕様を拡張する際には、以下の点に注意してください。

• 移行ジョブの仕様を拡張するには、約5～10分かかります。
• スケーリングが失敗した場合、ジョブの仕様はスケーリング前と同じままになります。

制限事項

• 移行ジョブの仕様をスケーリングできるのは、ジョブが「実行中」または「一時停止中」の状態にある場合のみです。
• TiDB Cloudは、既存のデータエクスポート段階における移行ジョブ仕様のスケーリングをサポートしていません。
• 移行ジョブの仕様を拡張すると、ジョブが再起動されます。ジョブのソーステーブルに主キーがない場合、重複データが挿入される可能性があります。
• スケーリング中は、ソースデータベースのバイナリログをパージしたり、MySQLソースデータベースのexpire_logs_daysを一時的に増やしたりしないでください。そうしないと、連続したバイナリログの位置を取得できず、ジョブが失敗する可能性があります。

スケーリング手順

1. TiDB Cloudコンソールにログインし、私のTiDBページに移動します。

2. ターゲットのTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで[データ] > [データ移行]をクリックします。

3. データ移行ページで、スケールアップする移行ジョブを探します。アクション列で、 [...] > [スケールアップ/スケールダウン]をクリックします。

4. 「スケールアップ／スケールダウン」ウィンドウで、使用する新しい仕様を選択し、 「送信」をクリックします。ウィンドウの下部に、その仕様の新しい価格が表示されます。