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

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

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

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

制限事項

可用性

• データ移行機能は、TiDB Cloud Dedicatedクラスターでのみ使用できます。

• TiDB CloudコンソールにTiDB Cloud Dedicated クラスターのデータ移行エントリが表示されない場合、この機能はお客様のリージョンではご利用いただけない可能性があります。お客様のリージョンでのサポートをご希望の場合は、 TiDB Cloudサポートお問い合わせください。

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

移行ジョブの最大数

組織ごとに最大200件の移行ジョブを作成できます。それ以上の移行ジョブを作成するには、 サポートチケットを提出する .

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

• すべてのデータベースperformance_schema移行対象として選択した場合でもsysシステムデータベースは除外され、 TiDB Cloudに移行されません。つまり、 mysql information_schemaこの機能では移行されません。

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

既存のデータ移行の制限

• 既存のデータの移行中に、ターゲット データベースに移行対象のテーブルがすでに含まれていて、重複キーがある場合は、重複キーを持つ行が置き換えられます。

• データセットのサイズが1 TiB未満の場合は、論理モード（デフォルトモード）の使用をお勧めします。データセットのサイズが1 TiBを超える場合、または既存のデータをより速く移行したい場合は、物理モードを使用できます。詳細については、 既存データと増分データを移行するご覧ください。

増分データ移行の制限

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

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

• 次のシナリオでは、移行ジョブに 24 時間以上かかる場合は、ソース データベースのバイナリ ログを消去せず、Data Migration が増分レプリケーション用の連続したバイナリ ログを取得できるようにします。

  • 既存のデータの移行中。
  • 既存のデータ移行が完了し、増分データ移行が初めて開始されたとき、レイテンシーは0 ミリ秒ではありません。

前提条件

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

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

データ移行では、次のデータ ソースとバージョンがサポートされます。

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

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

現在の値を確認し、ソースMySQLインスタンスを構成する

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

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

必要に応じて、必要な値に合わせてソース MySQL インスタンスの構成を変更します。

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

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

利用可能な接続方法は次のとおりです。

クラウド プロバイダー、ネットワーク トポロジ、セキュリティ要件に最適な接続方法を選択し、その方法のセットアップ手順に従います。

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

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

パブリックエンドポイントまたはIPアドレス

パブリックエンドポイントを使用する場合、ネットワーク接続とアクセスを、DMジョブ作成プロセス中にも、すぐにでも検証できます。その際、 TiDB Cloud具体的な出力IPアドレスと指示が表示されます。

1. ソース MySQL インスタンスのエンドポイント ホスト名 (FQDN) またはパブリック IP アドレスを識別して記録します。

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

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

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クラスタに安全に書き込むことができます。移行には、既存データの完全なデータダンプと増分変更のbinlogレプリケーションの両方が含まれるため、移行ユーザーには基本的な読み取りアクセスに加えて、特定の権限が必要です。

ソースMySQLデータベースの移行ユーザーに必要な権限を付与する

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

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

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

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

ターゲットTiDB Cloudクラスタに必要な権限を付与する

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

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

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

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

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

1. TiDB Cloudコンソールにログインし、プロジェクトのクラスターページに移動します。

   ヒント：

   左上隅のコンボ ボックスを使用して、組織、プロジェクト、クラスターを切り替えることができます。

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

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 フレキシブル サーバー インスタンスのリソース ID を入力します (形式: /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.DBforMySQL/flexibleServers/<server> )。

   • ポート: データ ソースのポート。

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

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

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

     SSL/TLS 構成オプション:

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

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

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

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

     • オプション3: 相互TLS (mTLS) - 最高のセキュリティ

       • MySQLサーバーが相互 TLS (mTLS) 認証用に構成されている場合は、 CA 証明書、クライアント証明書、およびクライアント秘密キーをアップロードします。
       • このオプションでは、MySQLサーバーはクライアント証明書を使用して TiDB Cloud の ID を検証し、 TiDB Cloud はCA 証明書を使用して MySQL サーバーの ID を検証します。
       • このオプションは、MySQLサーバーに移行ユーザーに対してREQUIRE X509またはREQUIRE SSL構成されている場合に必要です。
       • このオプションは、MySQLサーバーが認証にクライアント証明書を必要とする場合に使用されます。
       • 証明書は次のソースから取得できます。
         • クラウド プロバイダーからダウンロードします ( TLS証明書リンク参照)。
         • 組織の内部 CA 証明書を使用します。
         • 自己署名証明書 (開発/テスト専用)。

3. ターゲット接続プロファイルを入力します。

   • ユーザー名: TiDB Cloudのターゲット クラスターのユーザー名を入力します。
   • パスワード: TiDB Cloudユーザー名のパスワードを入力します。

4. 入力した情報を検証するには、 「接続の検証」と「次へ」をクリックします。

5. 表示されるメッセージに従ってアクションを実行します。

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

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

移行するオブジェクトの選択手順では、既存のデータの移行、増分データの移行、またはその両方を選択できます。

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

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

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

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

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

注記：

• 物理モードを使用する場合、既存のデータ移行が完了する前に、TiDB クラスターの 2 番目の移行ジョブまたはインポート タスクを作成することはできません。
• 物理モードを使用し、移行ジョブが開始された場合は、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 は、さまざまなシナリオでのパフォーマンスとコストの要件を満たすために、移行ジョブ仕様のスケールアップまたはスケールダウンをサポートしています。

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

移行ジョブの仕様をスケーリングする場合は、次の点に注意してください。

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

制限事項

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

スケーリング手順

1. TiDB Cloudコンソールにログインし、プロジェクトのクラスターページに移動します。

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

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

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