title

Migrate MySQL-Compatible Databases to TiDB Cloud Using Data Migration

summary

データ移行機能を使用して、Amazon Aurora MySQL、Amazon RDS、Azure Database for MySQL - Flexible Server、Google Cloud SQL for MySQL、またはSelf-ManagedのMySQLインスタンスから、ダウンタイムを最小限に抑えながらMySQLデータベースをTiDB Cloudにシームレスに移行する方法を学びましょう。

aliases

/ja/tidbcloud/migrate-data-into-tidb

/ja/tidbcloud/migrate-incremental-data-from-mysql

データ移行を使用してMySQL互換データベースをTiDB Cloudに移行する {#migrate-mysql-compatible-databases-to-tidb-cloud-using-data-migration}

このドキュメントでは、TiDB Cloud のデータ移行機能を使用して、Amazon Aurora MySQL、Amazon RDS、Azure Database for MySQL - Flexible Server、Google Cloud SQL for MySQL、またはSelf-Managed MySQL インスタンスからTiDB Cloud Dedicated 、 TiDB Cloud Essential TiDB CloudプレミアムTiDB CloudコンソールCloud Premium へ MySQL データベースを移行する手順を説明します。

注記：

現在、 TiDB Cloud Essentialのデータ移行機能はベータ版です。

注記：

現在、データ移行機能はTiDB Cloud Premiumのパブリックプレビュー版として提供されています。

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

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

制限事項 {#limitations}

可用性 {#availability}

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

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

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

TiDB Cloud Premiumのデータ移行機能は、現在パブリックプレビュー版として提供されています。
- 移行ジョブ間でソース接続の詳細を保存または再利用することはできません。
- パブリックプレビュー期間中は、機能の成熟に伴い、移行ジョブに追加の制限が適用される場合があります。詳細については、 TiDB Cloudサポートにお問い合わせください。

移行ジョブの最大数 {#maximum-number-of-migration-jobs}

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

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

フィルタリングおよび削除されたデータベース {#filtered-out-and-deleted-databases}

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

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

Alibaba Cloud RDSの制限事項 {#limitations-of-alibaba-cloud-rds}

Alibaba Cloud RDSをデータソースとして使用する場合、すべてのテーブルに明示的な主キーが必要です。主キーのないテーブルの場合、RDSはbinlogに非表示の主キーを追加しますが、これによりソーステーブルとのスキーマの不一致が発生し、移行が失敗します。

Alibaba Cloud PolarDB-Xの制限事項 {#limitations-of-alibaba-cloud-polardb-x}

完全なデータ移行中に、PolarDB-Xのスキーマに下流のデータベースと互換性のないキーワードが含まれている場合、インポートが失敗する可能性があります。

これを防ぐには、移行プロセスを開始する前に、下流データベースにターゲットテーブルを作成してください。

既存のデータ移行の限界 {#limitations-of-existing-data-migration}

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

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

TiDB Cloud Essentialでは、現在、データ移行には論理モードのみがサポートされています。このモードでは、MySQLソースデータベースからSQLステートメントとしてデータをエクスポートし、TiDB上で実行します。このモードでは、移行前のターゲットテーブルは空でも空でなくても構いません。

TiDB Cloud Premium では、論理モード (デフォルト) と物理モードの両方がサポートされています。論理モードでは、MySQL ソースデータベースから SQL ステートメントとしてデータをエクスポートし、ターゲットのTiDB Cloud Premium インスタンスで実行します。このとき、ロード中にリクエスト容量ユニット (RCU) が消費されます。物理モードでは、ターゲットのTiDB Cloud Premium インスタンスでIMPORT INTOを使用し、ロードのスループットとコスト効率を優先する場合の大規模データセットに推奨されます。
物理モードを使用し、移行ジョブが開始されたら、 TiDB Cloud PremiumインスタンスでPITR（ポイントインタイムリカバリ）を有効にしたり、変更フィードを設定したりしないでください。そうしないと、移行ジョブが停止します。PITRを有効にしたり、変更フィードを設定したりする必要がある場合は、代わりに論理モードを使用してデータを移行してください。
物理モードを使用する場合、既存のデータ移行が完了する前に、 TiDB Cloud Premiumインスタンスに対して2つ目の移行ジョブまたはインポートタスクを作成することはできません。

増分データ移行の限界 {#limitations-of-incremental-data-migration}

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

増分データ移行中に、移行対象のテーブルが既にターゲットデータベースに重複キーで存在する場合、エラーが報告され、移行は中断されます。この場合、MySQLソースデータが正確であることを確認する必要があります。データが正確であれば、移行ジョブの**「再開」**ボタンをクリックすると、移行ジョブはターゲットのTiDB Cloud Essentialインスタンス内の競合レコードをMySQLソースレコードに置き換えます。
増分データ移行 (進行中の変更をTiDB Cloud Essentialインスタンスに移行する) 中に、移行ジョブが突然のエラーから回復した場合、60 秒間セーフモードに入ることがあります。セーフモード中、 TiDB CloudはINSERTステートメントをREPLACEに、 UPDATEステートメントをDELETEおよびREPLACEに移行し、これらのトランザクションをターゲットのTiDB Cloud Essentialインスタンスに適用して、突然のエラー中に発生したすべてのデータが安全にターゲットに到達するようにします。ソーステーブルに主キーまたは null 以外の一意インデックスがない場合、ターゲットのTiDB Cloud Essentialインスタンスで重複した行が発生する可能性があります。

増分データ移行 (進行中の変更をTiDB Cloud Dedicatedクラスターに移行する) 中に、移行ジョブが突然のエラーから回復した場合、60 秒間セーフモードに入ることがあります。セーフモード中、 TiDB CloudはINSERTステートメントをREPLACEに、 UPDATEステートメントをDELETEおよびREPLACEに移行し、これらのトランザクションをターゲットのTiDB Cloud Dedicatedクラスターに適用して、突然のエラー中に発生したすべてのデータが安全にターゲットに到達するようにします。ソーステーブルに主キーまたは null 以外の一意インデックスがない場合、ターゲットのTiDB Cloud Dedicated Dedicated クラスターで重複した行が発生する可能性があります。
以下のシナリオでは、移行ジョブに24時間以上かかる場合、ソースデータベースのバイナリログを削除しないでください。これにより、データ移行ツールは増分データ移行のために連続したバイナリログを取得できます。
- 既存のデータ移行中に。
- 既存のデータ移行が完了し、増分データ移行が初めて開始された後、レイテンシーは0msになりません。

増分データ移行 (進行中の変更をTiDB Cloud Premium インスタンスに移行する) 中に、移行ジョブが突然のエラーから回復した場合、60 秒間セーフモードに入ることがあります。セーフモード中、 TiDB CloudはINSERTステートメントをREPLACEに、 UPDATEステートメントをDELETEおよびREPLACEに移行し、これらのトランザクションをターゲットのTiDB Cloud Premium インスタンスに適用して、突然のエラー中に発生したすべてのデータが安全にターゲットに到達するようにします。ソーステーブルに主キーまたは null 以外の一意インデックスがない場合、ターゲットのTiDB Cloud Premium インスタンスで重複した行が発生する可能性があります。

前提条件 {#prerequisites}

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

データソースとバージョンがサポートされていることを確認してください。 {#make-sure-your-data-source-and-version-are-supported}

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

データソース	サポートされているバージョン
自己管理型MySQL（オンプレミスまたはパブリッククラウド）	8.0、5.7、5.6
Amazon Aurora MySQL	8.0、5.7、5.6
Amazon RDS MySQL	8.0、5.7
Azure Database for MySQL - 柔軟なサーバー	8.0、5.7
Google Cloud SQL for MySQL	8.0、5.7、5.6
Alibaba Cloud RDS MySQL	8.0、5.7

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

データソース	サポートされているバージョン
自己管理型MySQL（オンプレミスまたはパブリッククラウド）	8.0、5.7
Amazon Aurora MySQL	8.0、5.7
Amazon RDS MySQL	8.0、5.7
Alibaba Cloud RDS MySQL	8.0、5.7
Azure Database for MySQL - 柔軟なサーバー	8.0、5.7
Google Cloud SQL for MySQL	8.0、5.7

TiDB Cloud Premium の場合、データ移行機能は次の MySQL 互換ソースデータベースをサポートしており、 MySQL は移行ジョブウィザードで使用できる唯一のデータソースタイプです。サポートされている接続方法については、ネットワーク接続を確保する参照してください。

データソース	サポートされているバージョン
自己管理型MySQL（オンプレミスまたはパブリッククラウド）	8.0、5.7
Amazon Aurora MySQL	8.0、5.7
Amazon RDS MySQL	8.0、5.7
Azure Database for MySQL - 柔軟なサーバー	8.0、5.7
Google Cloud SQL for MySQL	8.0、5.7
Alibaba Cloud RDS MySQL	8.0、5.7

レプリケーションのために、ソースのMySQL互換データベースでバイナリログを有効にする {#enable-binary-logs-in-the-source-mysql-compatible-database-for-replication}

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

設定	必要値	なぜ
`log_bin`	`ON`	DMがTiDBへの変更を複製するために使用するバイナリログを有効にします。
`binlog_format`	`ROW`	すべてのデータ変更を正確に記録します（他の形式では例外的なケースを見落とします）。
`binlog_row_image`	`FULL`	安全な紛争解決のために、イベントにすべての列値が含まれます。
`binlog_expire_logs_seconds`	≥ `86400` （1日）、 `604800` （7日、推奨）	移行中にDMが連続ログにアクセスできるようにします
`binlog_transaction_compression`	`OFF`	DMはトランザクション圧縮をサポートしていません

現在の値を確認し、ソースのMySQLインスタンスを設定します。 {#check-current-values-and-configure-the-source-mysql-instance}

現在の設定を確認するには、ソースの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インスタンスを構成する

/etc/my.cnfを開いて、以下を追加します。

[mysqld]
log_bin = mysql-bin
binlog_format = ROW
binlog_row_image = FULL
binlog_expire_logs_seconds = 604800   # 7 days retention
binlog_transaction_compression = OFF

変更を適用するには、MySQLサービスを再起動してください。
```
sudo systemctl restart mysqld
```
設定が有効になっていることを確認するには、 SHOW VARIABLESステートメントを再度実行してください。

詳細な手順については、MySQL ドキュメントのMySQLサーバーのシステム変数およびバイナリログを参照してください。

AWS RDSまたはAurora MySQLの設定

AWS マネジメントコンソールで、 Amazon RDS コンソールを開き、左側のナビゲーションペインで**[パラメータグループ]**をクリックし、カスタムパラメータグループを作成または編集します。
上記の4つのパラメータを必要な値に設定してください。
パラメータグループをインスタンスまたはクラスターにアタッチし、再起動して変更を適用してください。
再起動後、インスタンスに接続し、 SHOW VARIABLESステートメントを実行して構成を確認します。

詳細な手順については、AWS ドキュメントのDBパラメータグループの操作とMySQLバイナリログの設定参照してください。

Azure Database for MySQL の構成 - Flexible Server

Azureポータルで、 Azure Database for MySQL サーバーを検索して選択し、インスタンス名をクリックしてから、左側のナビゲーションペインで**[設定]** > **[サーバーパラメーター]**をクリックします。
各パラメータを検索し、その値を更新します。

ほとんどの変更は再起動なしで反映されます。再起動が必要な場合は、ポータルから通知が表示されます。
SHOW VARIABLESステートメントを実行して、設定を確認します。

詳細な手順については、Microsoft Azure ドキュメントのAzure ポータルを使用して、Azure Database for MySQL - Flexible Server でサーバーパラメーターを構成する参照してください。

Google Cloud SQL for MySQL の設定

Google Cloud Consoleで、インスタンスを含むプロジェクトを選択し、インスタンス名をクリックして、 **[編集]**をクリックします。
必要なフラグ ( log_bin 、 binlog_format 、 binlog_row_image 、 binlog_expire_logs_seconds ) を追加または変更します。
**「保存」**をクリックしてください。再起動が必要な場合は、コンソールからメッセージが表示されます。
再起動後、 SHOW VARIABLESステートメントを実行して変更を確認します。

詳細な手順については、Google Cloud ドキュメントのデータベースフラグを設定すると特定時点へのリカバリを使用するご覧ください。

Alibaba Cloud RDS MySQL の設定

ApsaraDB RDSコンソールで、インスタンスのリージョンを選択し、RDS for MySQL インスタンスの ID をクリックします。
左側のナビゲーションペインで**「パラメーター」**をクリックし、各パラメーターを検索して、次の値を設定します。
- binlog_row_image : FULL
左側のナビゲーションペインで、 **[バックアップと復元]**をクリックし、 **[バックアップ戦略]**を選択します。移行中に DM が連続するbinlogファイルにアクセスできるようにするには、バックアップ戦略を次の制約で構成します。
- 保存期間：最低3日間（推奨7日間）に設定してください。
- 保持ファイル: 古いログが時期尚早に上書きされないように、「最大ファイル数」が十分であることを確認してください。
- ストレージ保護：ストレージの使用状況を綿密に監視してください。ディスク容量の使用量がシステムしきい値に達すると、保持期間の設定に関わらず、RDS は最も古いバイナリログを自動的に削除しますのでご注意ください。
変更を適用した後（必要に応じて再起動した後）、インスタンスに接続し、このセクションのSHOW VARIABLESステートメントを実行して構成を確認します。

詳細については、インスタンスパラメータを設定します参照してください。

ネットワーク接続を確保する {#ensure-network-connectivity}

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

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

接続方法	可用性	推奨対象
公開エンドポイントまたはIPアドレス	TiDB Cloudがサポートするすべてのクラウドプロバイダー	迅速な概念実証移行、テスト、またはプライベート接続が利用できない場合
プライベートリンクまたはプライベートエンドポイント	AWSとAzureのみ	データをパブリックインターネットに公開することなく、本番環境のワークロードを実行する
VPCピアリング	AWSとGoogle Cloudのみ	低遅延でリージョン内接続が必要であり、VPC/VNet CIDRが重複しない本番ワークロード

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

接続方法	可用性	推奨対象
公開エンドポイントまたはIPアドレス	TiDB Cloudがサポートするすべてのクラウドプロバイダー	迅速な概念実証移行、テスト、またはプライベート接続が利用できない場合
プライベートリンクまたはプライベートエンドポイント	AWSとAlibaba Cloudのみ	データをパブリックインターネットに公開することなく、本番環境のワークロードを実行する

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

接続方法	可用性	推奨対象
公開エンドポイントまたはIPアドレス	TiDB Cloud Premiumがサポートするすべてのクラウドプロバイダー	迅速な概念実証移行、テスト、またはプライベート接続が利用できない場合
プライベートリンク	AWSのみ	データをパブリックインターネットに公開することなく、本番環境のワークロードを実行する

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

TLS/SSLによるエンドツーエンド暗号化 {#end-to-end-encryption-over-tls-ssl}

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

TLS/SSL暗号化接続用のクラウドプロバイダーの証明書をダウンロードして保存する

Amazon Aurora MySQL または Amazon RDS MySQL: SSL/TLSを使用してDBインスタンスまたはクラスターへの接続を暗号化する
Azure Database for MySQL - フレキシブルサーバー: 暗号化された接続で接続します
Google Cloud SQL for MySQL: SSL/TLS証明書の管理
Alibaba Cloud RDS MySQL: SSL暗号化機能を設定する

公開エンドポイントまたはIPアドレス {#public-endpoints-or-ip-addresses}

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

注記：

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

ファイアウォールルールを変更する権限が必要です。

セットアッププロセス中に、クラウドプロバイダーのコンソールにアクセスできます。

タスク作成ワークフローを一時停止して、ファイアウォールを設定できます。

ソースとなるMySQLインスタンスのエンドポイントホスト名（FQDN）またはパブリックIPアドレスを特定し、記録します。
データベースのファイアウォールまたはセキュリティグループのルールを変更するには、必要な権限が付与されていることを確認してください。詳細については、クラウドプロバイダーのドキュメントを参照してください。
- Amazon Aurora MySQL または Amazon RDS MySQL: セキュリティグループによるアクセス制御。
- Azure Database for MySQL - フレキシブルサーバー: 公共ネットワークアクセス
- Google Cloud SQL for MySQL: 認証済みネットワーク。
オプション：適切な証明書を使用して転送中の暗号化を行い、パブリックインターネットアクセスを備えたマシンからソースデータベースへの接続を確認します。
```
mysql -h <public-host> -P <port> -u <user> -p --ssl-ca=<path-to-provider-ca.pem> -e "SELECT version();"
```
後ほど、データ移行ジョブの設定時に、 TiDB Cloud送信元IPアドレス範囲が提供されます。その際、上記と同じ手順に従って、このIPアドレス範囲をデータベースのファイアウォールまたはセキュリティグループのルールに追加する必要があります。

プライベートリンクまたはプライベートエンドポイント {#private-link-or-private-endpoint}

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

MySQLソースデータベース用にAWS PrivateLinkとプライベートエンドポイントを設定します。

AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサポートしていません。そのため、ネットワークロードバランサー (NLB) を作成し、それをソース MySQL インスタンスに関連付けられたエンドポイントサービスとして公開し、TiDB Cloud の AWS プリンシパルがそのサービスを利用できるように承認する必要があります。

Amazon EC2 コンソールデータベースのプライベート IP アドレスを含むターゲットグループに転送する TCP リスナーをポート3306で持つ内部 NLB を作成します。以下のキー設定を構成します。
- スキーム:内部。ロードバランサーはVPC内に留まります。次のステップのエンドポイントサービスのみが、ロードバランサーをTiDB Cloudに公開します。
- VPC ：RDSまたはAuroraインスタンスと同じVPCを指定します。フォームはデフォルトでアカウントのデフォルトVPCを選択しますが、データベースが配置されている場所は通常このVPCではないため、続行する前にVPCのドロップダウンリストを変更してください。
- アベイラビリティゾーン：少なくとも2つのアベイラビリティゾーンでサブネットを選択してください。NLBでは、エンドポイントサービスの可用性を確保するためにマルチAZ構成が必要です。RDSがシングルAZ構成の場合でも、同じVPC内の別のAZに2つ目のサブネットが必要になります。
- リスナーポート： 3306 。ウィザードのデフォルト値は80です。リスナーを作成する前に変更してください。
- 対象グループ：対象タイプはIPアドレス、プロトコルはTCP 、ポートは3306 、データベースと同じVPC内。RDSエンドポイントを直接登録することはできないため、代わりにデータベースのプライベートIPアドレスを登録してください。
  
  Amazon EC2 コンソールでデータベースのプライベート IP アドレスを見つけるには、左側のナビゲーションペインで**「ネットワークインターフェイス」をクリックし、「説明= RDSNetworkInterfaceと「VPC** = ご使用の VPC」でフィルタリングします。一致するネットワークインターフェイスに表示されているプライマリプライベート IPv4 アドレスを使用します。
  
  注記：
  
  RDS プライベート IP は、フェールオーバー、メンテナンス、またはストレージの拡張時に変更される可能性があります。実稼働デプロイメントについては、本番ローテーションパターンについて、AWS データベースブログのAWS PrivateLinkとネットワークロードバランサーを使用して、VPCをまたいでAmazon RDSにアクセスします。参照してください。
詳細な手順については、AWS ドキュメントのネットワークロードバランサーを作成する参照してください。
Amazon VPC コンソールで、左側のナビゲーションペインの**[エンドポイントサービス]**をクリックし、 **[エンドポイントサービスの作成]**をクリックします。次の設定を構成します。
- ロードバランサーの種類を**「ネットワーク」に設定し、前の手順で作成したNLBを選択します。利用可能なロードバランサーのリストが空の場合は、NLBがアクティブ**状態になるまで待ってから、リストの横にある更新アイコンをクリックします。
- 承認が必要：有効（デフォルト）。
- サポートされているIPアドレスタイプ： IPv4を選択してください。
エンドポイントサービスが作成されたら、後で使用するためにサービス名をコピーしてください。サービス名はcom.amazonaws.vpce.<region>.vpce-svc-<id>の形式です。たとえば、 com.amazonaws.vpce.us-east-1.vpce-svc-0123456789abcdef0ようになります。

詳細な手順については、AWS ドキュメントのエンドポイントサービスを作成します参照してください。
TiDB CloudのAWSプリンシパルがエンドポイントサービスを使用できるように承認します。Amazon Amazon VPC コンソールのエンドポイントサービスの詳細ページで、 **[プリンシパルの許可]**タブを開き、 **[プリンシパルの許可]**をクリックして、次のARNを追加します。
```
arn:aws:iam::886436925895:root
```
この手順を行わないと、 TiDB Cloud はサービスに接続する VPC エンドポイントを作成できず、 TiDB Cloudの**「外部サービス用のプライベートエンドポイントの作成」**ダイアログがエラーメッセージも表示されずに永久に停止してしまいます。

詳細な手順については、AWS ドキュメントの権限を管理する参照してください。
オプション：移行を開始する前に、同じVPC内の踏み台サーバーまたはクライアントから接続テストを実施してください。
```
mysql -h <private‑host> -P 3306 -u <user> -p --ssl-ca=<path-to-provider-ca.pem> -e "SELECT version();"
```
後ほど、 TiDB Cloud DMをPrivateLink経由で接続するように設定する際には、AWSコンソールに戻り、 TiDB Cloudからこのプライベートエンドポイントへの保留中の接続要求を承認する必要があります。

Azure PrivateLink と MySQL ソースデータベース用のプライベートエンドポイントを設定します。

Azure Database for MySQL - Flexible Server は、ネイティブのプライベートエンドポイントをサポートしています。MySQL インスタンスの作成時にプライベートアクセス (VNet 統合) を有効にするか、後からプライベートエンドポイントを追加することができます。

新しいプライベートエンドポイントを追加するには、以下の手順を実行してください。

Azureポータルで、 「Azure Database for MySQL サーバー」を検索して選択し、インスタンス名をクリックしてから、左側のナビゲーションペインで「設定」 > **「ネットワーク」**をクリックします。
ネットワーク設定ページで、プライベートエンドポイントのセクションまでスクロールダウンし、 **「+ プライベートエンドポイントの作成」**をクリックして、画面の指示に従ってプライベートエンドポイントを設定します。

セットアップ中に、[仮想ネットワーク]タブでTiDB Cloud がアクセスできる仮想ネットワークとサブネットを選択し、 [DNS]タブで[プライベート DNS 統合] を有効にします。プライベートエンドポイントが作成されてデプロイされたら、 [リソースに移動] をクリックし、左側のナビゲーションペインで[設定] > [DNS 構成] をクリックして、[**顧客可視 FQDN]**セクションでインスタンスへの接続に使用するホスト名を見つけます。通常、ホスト名は<your-instance-name>.mysql.database.azure.com形式です。

詳細な手順については、Azure ドキュメントのプライベートリンクセンターを使用してプライベートエンドポイントを作成します。参照してください。
オプション：移行を開始する前に、同じVPCまたはVNet内の踏み台サーバーまたはクライアントから接続テストを実施してください。
```
mysql -h <private‑host> -P 3306 -u <user> -p --ssl-ca=<path-to-provider-ca.pem> -e "SELECT version();"
```
Azureポータルので、MySQL Flexible Server インスタンスの概要ページ (プライベートエンドポイントオブジェクトではありません) に戻り、 **[Essentials]セクションで[JSON ビュー]**をクリックして、後で使用するためにリソース ID をコピーします。リソース ID は/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.DBforMySQL/flexibleServers/<server>形式です。このリソース ID (プライベートエンドポイント ID ではありません) を使用して、 TiDB Cloud DM を構成します。
後ほど、 TiDB Cloud DMをPrivateLink経由で接続するように構成する際には、Azureポータルに戻り、 TiDB Cloudからこのプライベートエンドポイントへの保留中の接続要求を承認する必要があります。

プロバイダーネイティブのプライベートリンクまたはプライベートエンドポイントを使用する場合は、ソース MySQL インスタンスに対してプライベートリンク接続作成します。

AWS 上でホストされているTiDB Cloud Premium インスタンスの場合、AWS PrivateLink を使用して、データベースをパブリックインターネットに公開することなく、ソース MySQL インスタンスに接続できます。同じTiDB Cloud Premium インスタンス上で、複数のデータ移行ジョブや変更フィードにわたってプライベートエンドポイントを再利用できます。

MySQLソースデータベース用にAWS PrivateLinkとプライベートエンドポイントを設定します。

Amazon EC2 コンソールデータベースのプライベート IP アドレスを含むターゲットグループに転送する TCP リスナーをポート3306で持つ内部 NLB を作成します。以下のキー設定を構成します。
- スキーム:内部。ロードバランサーはVPC内に留まります。次のステップのエンドポイントサービスのみが、ロードバランサーをTiDB Cloudに公開します。
- VPC ：RDSまたはAuroraインスタンスと同じVPCを指定します。フォームはデフォルトでアカウントのデフォルトVPCを選択しますが、データベースが配置されている場所は通常このVPCではないため、続行する前にVPCのドロップダウンリストを変更してください。
- アベイラビリティゾーン：少なくとも2つのアベイラビリティゾーンでサブネットを選択してください。NLBでは、エンドポイントサービスの可用性を確保するためにマルチAZ構成が必要です。RDSがシングルAZ構成の場合でも、同じVPC内の別のAZに2つ目のサブネットが必要になります。
- リスナーポート： 3306 。ウィザードのデフォルト値は80です。リスナーを作成する前に変更してください。
- 対象グループ：対象タイプはIPアドレス、プロトコルはTCP 、ポートは3306 、データベースと同じVPC内。RDSエンドポイントを直接登録することはできないため、代わりにデータベースのプライベートIPアドレスを登録してください。
  
  Amazon EC2 コンソールでデータベースのプライベート IP アドレスを見つけるには、左側のナビゲーションペインで**「ネットワークインターフェイス」をクリックし、「説明= RDSNetworkInterfaceと「VPC** = ご使用の VPC」でフィルタリングします。一致するネットワークインターフェイスに表示されているプライマリプライベート IPv4 アドレスを使用します。
  
  注記：
  
  RDS プライベート IP は、フェールオーバー、メンテナンス、またはストレージの拡張時に変更される可能性があります。実稼働デプロイメントについては、本番ローテーションパターンについて、AWS データベースブログのAWS PrivateLinkとネットワークロードバランサーを使用して、VPCをまたいでAmazon RDSにアクセスします。参照してください。
詳細な手順については、AWS ドキュメントのネットワークロードバランサーを作成する参照してください。
Amazon VPC コンソールで、左側のナビゲーションペインの**[エンドポイントサービス]**をクリックし、 **[エンドポイントサービスの作成]**をクリックします。次の設定を構成します。
- ロードバランサーの種類を**「ネットワーク」に設定し、前の手順で作成したNLBを選択します。利用可能なロードバランサーのリストが空の場合は、NLBがアクティブ**状態になるまで待ってから、リストの横にある更新アイコンをクリックします。
- 承認が必要：有効（デフォルト）。
- サポートされているIPアドレスタイプ： IPv4を選択してください。
エンドポイントサービスが作成されたら、後で使用するためにサービス名をコピーしてください。サービス名はcom.amazonaws.vpce.<region>.vpce-svc-<id>の形式です。たとえば、 com.amazonaws.vpce.us-east-1.vpce-svc-0123456789abcdef0ようになります。

詳細な手順については、AWS ドキュメントのエンドポイントサービスを作成します参照してください。
TiDB CloudのAWSプリンシパルがエンドポイントサービスを使用できるように承認します。Amazon Amazon VPC コンソールのエンドポイントサービスの詳細ページで、 **[プリンシパルの許可]**タブを開き、 **[プリンシパルの許可]**をクリックして、次のARNを追加します。
```
arn:aws:iam::886436925895:root
```
この手順を行わないと、 TiDB Cloud はサービスに接続する VPC エンドポイントを作成できず、 TiDB Cloudの**「外部サービス用のプライベートエンドポイントの作成」**ダイアログがエラーメッセージも表示されずに永久に停止してしまいます。

詳細な手順については、AWS ドキュメントの権限を管理する参照してください。
オプション：移行を開始する前に、同じVPC内の踏み台サーバーまたはクライアントから接続テストを実施してください。
```
mysql -h <private‑host> -P 3306 -u <user> -p --ssl-ca=<path-to-provider-ca.pem> -e "SELECT version();"
```
後ほど、 TiDB Cloud DMをPrivateLink経由で接続するように設定する際には、AWSコンソールに戻り、 TiDB Cloudからこのプライベートエンドポイントへの保留中の接続要求を承認する必要があります。

プライベートエンドポイントは、 TiDB Cloud Premiumインスタンスのネットワークページ、またはデータ移行ジョブの作成時に作成できます（ステップ2参照）。

ネットワークページからプライベートエンドポイントを作成するには、以下の手順を実行してください。

TiDB Cloudコンソールにログインし、 TiDB Cloud Premiumインスタンスの概要ページに移動してください。
左側のナビゲーションペインで、 [設定] > **[ネットワーク]**をクリックします。
AWS 外部サービス用プライベートエンドポイントのセクションで、 **[外部サービス用プライベートエンドポイントの作成]**をクリックします。
「外部サービス用のプライベートエンドポイントの作成」ダイアログで、プライベートエンドポイントの名前と、MySQLソースデータベース用にAWS PrivateLinkをセットアップした際にコピーしたエンドポイントサービス名を入力します。

注記：

「作成」をクリックする前に、上記の「MySQLソースデータベースのAWS PrivateLinkとプライベートエンドポイントの設定」の手順3で説明されているように、AWSのエンドポイントサービスでTiDB CloudのAWSプリンシパル（ arn:aws:iam::886436925895:root ）が承認されていることを確認してください。承認されていない場合、このダイアログはエラーメッセージを表示せずに永久に停止します。
**「作成」**をクリックします。

プライベートエンドポイントが利用可能になったら、データ移行ジョブを作成する際にそれを選択できるようになります。

VPCピアリング {#vpc-peering}

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

AWS VPCピアリングの設定

MySQLサービスがAWS VPC内にある場合は、以下の手順を実行してください。

MySQL サービスの VPC とTiDB Cloud Dedicatedクラスターの間でVPCピアリング接続を設定する。
MySQLサービスが関連付けられているセキュリティグループの受信ルールを変更します。

TiDB Cloud Dedicatedクラスターが配置されているリージョンの CIDR受信ルールに追加する必要があります。これにより、 TiDB Cloud Dedicatedクラスターから MySQL インスタンスにトラフィックが流れるようになります。

TiDB Cloud Essentialインスタンスが配置されているリージョンのCIDRルールに追加する必要があります。これにより、トラフィックがTiDB Cloud Essentialインスタンスから MySQL インスタンスに流れるようになります。
MySQLのURLにDNSホスト名が含まれている場合、 TiDB CloudがMySQLサービスのホスト名を解決できるようにする必要があります。
1. VPCピアリング接続のDNS解決を有効にするの手順に従います。
2. アクセプターDNS解決オプションを有効にする。

Google Cloud VPCネットワークピアリングの設定

MySQLサービスがGoogle Cloud VPC内にある場合は、以下の手順を実行してください。

セルフホスト型のMySQLの場合は、この手順をスキップして次の手順に進んでください。MySQLサービスがGoogle Cloud SQLの場合は、Google Cloud SQLインスタンスに関連付けられたVPCにMySQLエンドポイントを公開する必要があります。Googleが開発したCloud SQL認証プロキシ使用する必要があるかもしれません。
MySQL サービスの VPC とTiDB Cloud Dedicatedクラスターの間でVPCピアリング接続を設定する。
MySQLが配置されているVPCの受信ファイアウォールルールを変更します。

TiDB Cloud Dedicatedクラスターが配置されているリージョンの CIDRイングレスファイアウォールルールに追加する必要があります。これにより、トラフィックがTiDB Cloud Dedicatedクラスターから MySQL エンドポイントに流れることが可能になります。

TiDB Cloud Essentialインスタンスが配置されているリージョンのCIDRイングレスファイアウォールルールに追加する必要があります。これにより、トラフィックがTiDB Cloud Essentialインスタンスから MySQL エンドポイントに流れることが可能になります。

移行に必要な権限を付与する {#grant-required-privileges-for-migration}

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

ソースMySQLデータベースで、移行ユーザーに必要な権限を付与します。 {#grant-required-privileges-to-the-migration-user-in-the-source-mysql-database}

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

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

特権	範囲	目的
`SELECT`	表	すべてのテーブルからデータを読み取ることができます
`RELOAD`	グローバル	フルダンプ中に一貫性のあるスナップショットを保証します
`REPLICATION SLAVE`	グローバル	増分データ移行のためのbinlogストリーミングを有効にする
`REPLICATION CLIENT`	グローバル	binlogの位置とサーバーの状態へのアクセスを提供します
`LOCK TABLES`	表	ソースがマネージド MySQL サービス (Amazon RDS、 Aurora、ApsaraDB RDS for MySQL、Azure Database for MySQL、Google Cloud SQL など) であり、 `FLUSH TABLES WITH READ LOCK` (FTWRL) が許可されていない場合に必要です。この場合、DM は`LOCK TABLES`にフォールバックし、完全なデータエクスポート中の一貫性を確保します。FTWRL が利用可能なSelf-Managed MySQL インスタンスには不要です。

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

-- For self-managed MySQL:
GRANT SELECT, RELOAD, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'dm_source_user'@'%';

-- For managed MySQL services (such as Amazon RDS and Aurora), also grant the LOCK TABLES privilege:
GRANT SELECT, RELOAD, LOCK TABLES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'dm_source_user'@'%';

対象のTiDB Cloudリソースで必要な権限を付与する {#grant-required-privileges-in-the-target-tidb-cloud-resource}

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

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

特権	範囲	目的
`CREATE`	データベース、テーブル	ターゲットにスキーマオブジェクトを作成します
`SELECT`	表	移行中にデータを検証する
`INSERT`	表	移行されたデータを書き込む
`UPDATE`	表	増分データ移行中に既存の行を変更します
`DELETE`	表	レプリケーションまたは更新中に行を削除します
`ALTER`	表	スキーマ変更時にテーブル定義を修正します
`DROP`	データベース、テーブル	スキーマ同期中にオブジェクトを削除します
`INDEX`	表	インデックスを作成および変更します
`CREATE VIEW`	ビュー	マイグレーションで使用されるビューを作成します

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

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

ステップ1：データ移行ページに移動します {#step-1-go-to-the-data-migration-page}

TiDB Cloudコンソールにログインし、私のTiDBページに移動します。
ターゲットのTiDB Cloud DedicatedクラスターTiDB Cloud EssentialインスタンスTiDB Cloud Premiumインスタンス名前をクリックして概要ページに移動し、左側のナビゲーションペインで**[データ]** > **[データ移行]**をクリックします。
データ移行ページで、右上隅にある**「移行ジョブの作成」**をクリックします。移行ジョブの作成ページが表示されます。

ステップ2：ソース接続とターゲット接続を設定する {#step-2-configure-the-source-and-target-connections}

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

職名を入力してください。職名は文字で始まり、60文字以内である必要があります。文字（AZ、az）、数字（0～9）、アンダースコア（_）、ハイフン（-）が使用可能です。
ソース接続プロファイルを入力してください。
- データソース：データソースの種類。
- 接続方法：セキュリティ要件とクラウドプロバイダーに基づいて、データソースの接続方法を選択してください。
  - パブリックIP ：すべてのクラウドプロバイダーで利用可能（テストおよび概念実証移行に推奨）。
  - プライベートリンク：AWSおよびAzureでのみ利用可能（プライベート接続を必要とする本番ワークロードに推奨）。
  - VPCピアリング：AWSとGoogle Cloudでのみ利用可能です（低遅延でリージョン内接続が必要で、VPC/VNet CIDRが重複しない本番ロードに推奨されます）。
- 接続方法：セキュリティ要件とクラウドプロバイダーに基づいて、データソースの接続方法を選択してください。
  - 公開：すべてのクラウドプロバイダーで利用可能（テストおよび概念実証のための移行に推奨）。
  - プライベートリンク：AWSおよびAlibaba Cloudでのみ利用可能です（プライベート接続を必要とする本番のワークロードに推奨）。
- 接続方法：セキュリティ要件とクラウドプロバイダーに基づいて、データソースの接続方法を選択してください。
  - 公開： TiDB Cloud Premiumがサポートするすべてのクラウドプロバイダーで利用可能（テストおよび概念実証移行に推奨）。
  - プライベートリンク：AWSのみで利用可能（プライベート接続を必要とする本番のワークロードに推奨）。
- 選択した接続方法に基づいて、以下の手順を実行してください。
  - パブリックIPまたはVPCピアリングを選択した場合は、ホスト名またはIPアドレスのフィールドにデータソースのホスト名またはIPアドレスを入力してください。
  - **「プライベートリンク」**を選択した場合は、以下の情報を入力してください。
    - エンドポイントサービス名(データソースがAWS の場合に利用可能): RDS または Aurora インスタンス用に作成した VPC エンドAuroraサービス名 (形式: com.amazonaws.vpce.<region>.vpce-svc-<id> 、例: com.amazonaws.vpce.us-east-1.vpce-svc-0123456789abcdef0 ) を入力します。
    - プライベートエンドポイントリソースID （データソースがAzureの場合に利用可能）：MySQL Flexible ServerインスタンスのリソースIDを入力します（形式： /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.DBforMySQL/flexibleServers/<server> ）。
- 選択した接続方法に基づいて、以下の手順を実行してください。
  - **「公開」**を選択した場合は、 **「ホスト名またはIPアドレス」**フィールドにデータソースのホスト名またはIPアドレスを入力してください。
  - **[プライベートリンク]**が選択されている場合は、[プライベートリンクプライベートリンクまたはプライベートエンドポイントセクションで作成したプライベートリンク接続を選択します。
- 選択した接続方法に基づいて、以下の手順を実行してください。
  - **「公開」**を選択した場合は、 **「ホスト名またはIPアドレス」**フィールドにデータソースのホスト名またはIPアドレスを入力してください。
  - **[プライベートリンク]**が選択されている場合は、 [プライベートエンドポイント]フィールドで既存のプライベートエンドポイントを選択するか、 [ここでプライベートエンドポイントを作成] をクリックしてプライベートエンドポイントを作成します。プライベートエンドポイントは、 TiDB Cloud Premium インスタンスの[ネットワーキング] > **[外部サービスのプライベートエンドポイント]**で管理されます。プライベートエンドポイントは、複数のデータ移行ジョブおよび変更フィード間で再利用できます。設定の詳細については、プライベートリンクまたはプライベートエンドポイントをご覧ください。
- ポート：データソースのポート番号。
- ユーザー名：データソースのユーザー名。
- パスワード：ユーザー名のパスワード。
- 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証明書リンクを参照)。
      - 組織の内部認証局証明書を使用してください。
      - 自己署名証明書（開発／テスト専用）。
ターゲット接続プロファイルを入力してください。
- ユーザー名: TiDB Cloud DedicatedクラスターTiDB クラウドTiDB Cloud EssentialインスタンスTiDB CloudTiDB Cloud Premiumインスタンスのユーザー名を入力します。
- パスワード： TiDB Cloudのユーザー名のパスワードを入力してください。
入力した情報を検証するには、 「接続を検証」をクリックし、「次へ」をクリックしてください。
表示されたメッセージに従って行動してください。
- 接続方法としてパブリックIPまたはVPCピアリングを使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。
- 接続方法としてプライベートリンクを使用する場合、エンドポイント要求を承認するよう求められます。
  - AWSの場合： AWS VPCコンソールで、エンドポイントサービスを作成したAWSリージョンに切り替え、 **[エンドポイントサービス]**をクリックし、 TiDB Cloudからのエンドポイントリクエストを承認します。
  - Azure の場合: Azureポータルに移動し、MySQL Flexible Server を名前で検索し、左側のナビゲーションペインで**[設定]** > **[ネットワーク]をクリックし、右側の[プライベートエンドポイント]**セクションを見つけて、 TiDB Cloudからの保留中の接続要求を承認します。
パブリックIPを使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。
- 接続方法としてパブリックを使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。
- Private Linkを使用しており、選択したプライベートエンドポイントがAWSでまだ承認されていない場合は、 AWS VPCコンソールでエンドポイントサービスを作成したAWSリージョンに切り替え、 **[エンドポイントサービス]**を選択し、 TiDB Cloudからのエンドポイント接続要求を承認してください。

ステップ3：移行ジョブの種類を選択する {#step-3-choose-migration-job-type}

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

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

移行タイプのステップでは、既存データと増分データの両方を移行する場合は**「完全＋増分」を**、増分データのみを移行する場合は**「増分のみ」**を選択できます。

既存データと増分データを移行する {#migrate-existing-data-and-incremental-data}

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に対するパフォーマンスへの影響が異なります。以下の表は、各仕様のパフォーマンス低下を示しています。

移行仕様	最大輸出速度	MySQLソースデータベースのパフォーマンス低下
RCU 2台	80.84 MiB/秒	15.6%
4つのRCU	214.2 MiB/秒	20.0%
8 RCU	365.5 MiB/秒	28.9%
16 RCU	424.6 MiB/秒	46.7%

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

現在、既存データの移行には論理モードのみを使用できます。このモードでは、MySQLソースデータベースからSQLステートメントとしてデータをエクスポートし、TiDB上で実行します。このモードでは、移行前のターゲットテーブルは空でも空でなくても構いません。

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

既存データの移行には、物理モードまたは論理モードのいずれかを使用できます。

デフォルトモードは論理モードです。このモードでは、MySQLソースデータベースからSQLステートメントとしてデータをエクスポートし、ターゲットのTiDB Cloud Premiumインスタンス上で実行します。このモードでは、移行前にターゲットテーブルが空でも空でなくても構いませんが、物理モードよりもパフォーマンスが低下します。
大規模なデータセットの場合は、物理モードを選択できます。このモードでは、ターゲットのTiDB Cloud Premium インスタンスでIMPORT INTOを使用してロードを高速化します。物理モードでは、移行前にターゲットテーブルが空である必要があります。事前チェックで選択したターゲットテーブルが空でないことが検出された場合、移行ジョブは自動的に論理モードに切り替わります。

注記：

物理モードを使用する場合、既存のデータ移行が完了する前に、 TiDB Cloud Premiumインスタンスに対して2つ目の移行ジョブまたはインポートタスクを作成することはできません。

物理モードを使用し、移行ジョブが開始されたら、 TiDB Cloud PremiumインスタンスでPITR（ポイントインタイムリカバリ）を有効にしたり、変更フィードを設定したりしないでください。そうしないと、移行ジョブが停止します。PITRを有効にしたり、変更フィードを設定したりする必要がある場合は、代わりに論理モードを使用してデータを移行してください。

既存データのみを移行する {#migrate-only-existing-data}

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

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

増分データのみを移行する {#migrate-only-incremental-data}

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

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

ステップ4：移行するオブジェクトを選択する {#step-4-choose-the-objects-to-be-migrated}

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

ステップ5：事前チェック {#step-5-precheck}

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

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

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

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

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

ステップ6：移行の進捗状況をビュー {#step-6-view-the-migration-progress}

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

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

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

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

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

ステップ6：移行の進捗状況を監視する {#step-6-monitor-the-migration-progress}

移行ジョブは、実行中でも一時停止または削除できます。移行ジョブが失敗した場合は、問題を解決した後に再開できます。移行ジョブは、どの状態でも削除できます。

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

注記：

TiDB Cloud Premiumは、移行ジョブのリソースを自動的に管理します。ワーカープールはアクティブな移行ジョブの数に基づいて自動的にスケールアップ/スケールダウンするため、仕様を選択したり、手動でスケーリングしたりする必要はありません。

ステップ6：仕様を選択して移行を開始する {#step-6-choose-a-spec-and-start-migration}

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

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

ステップ7：移行の進捗状況をビュー {#step-7-view-the-migration-progress}

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

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

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

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

移行ジョブ仕様を拡張する {#scale-a-migration-job-specification}

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

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

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

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

制限事項 {#limitations}

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

スケーリング手順 {#scaling-procedure}

TiDB Cloudコンソールにログインし、私のTiDBページに移動します。
対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**「データ」** > **「データ移行」**をクリックします。
データ移行ページで、スケールアップする移行ジョブを探します。アクション列で、 [...] > **[スケールアップ/スケールダウン]**をクリックします。
**「スケールアップ／スケールダウン」**ウィンドウで、使用する新しい仕様を選択し、 **「送信」**をクリックします。ウィンドウの下部に、その仕様の新しい価格が表示されます。

Navigation Menu

Uh oh!

データ移行を使用してMySQL互換データベースをTiDB Cloudに移行する {#migrate-mysql-compatible-databases-to-tidb-cloud-using-data-migration}

制限事項 {#limitations}

可用性 {#availability}

移行ジョブの最大数 {#maximum-number-of-migration-jobs}

フィルタリングおよび削除されたデータベース {#filtered-out-and-deleted-databases}

Alibaba Cloud RDSの制限事項 {#limitations-of-alibaba-cloud-rds}

Alibaba Cloud PolarDB-Xの制限事項 {#limitations-of-alibaba-cloud-polardb-x}

既存のデータ移行の限界 {#limitations-of-existing-data-migration}

増分データ移行の限界 {#limitations-of-incremental-data-migration}

前提条件 {#prerequisites}

データソースとバージョンがサポートされていることを確認してください。 {#make-sure-your-data-source-and-version-are-supported}

レプリケーションのために、ソースのMySQL互換データベースでバイナリログを有効にする {#enable-binary-logs-in-the-source-mysql-compatible-database-for-replication}

現在の値を確認し、ソースのMySQLインスタンスを設定します。 {#check-current-values-and-configure-the-source-mysql-instance}

ネットワーク接続を確保する {#ensure-network-connectivity}

TLS/SSLによるエンドツーエンド暗号化 {#end-to-end-encryption-over-tls-ssl}

公開エンドポイントまたはIPアドレス {#public-endpoints-or-ip-addresses}

プライベートリンクまたはプライベートエンドポイント {#private-link-or-private-endpoint}

VPCピアリング {#vpc-peering}

移行に必要な権限を付与する {#grant-required-privileges-for-migration}

ソースMySQLデータベースで、移行ユーザーに必要な権限を付与します。 {#grant-required-privileges-to-the-migration-user-in-the-source-mysql-database}

対象のTiDB Cloudリソースで必要な権限を付与する {#grant-required-privileges-in-the-target-tidb-cloud-resource}

ステップ1：データ移行ページに移動します {#step-1-go-to-the-data-migration-page}

ステップ2：ソース接続とターゲット接続を設定する {#step-2-configure-the-source-and-target-connections}

ステップ3：移行ジョブの種類を選択する {#step-3-choose-migration-job-type}

既存データと増分データを移行する {#migrate-existing-data-and-incremental-data}

既存データのみを移行する {#migrate-only-existing-data}

増分データのみを移行する {#migrate-only-incremental-data}

ステップ4：移行するオブジェクトを選択する {#step-4-choose-the-objects-to-be-migrated}

ステップ5：事前チェック {#step-5-precheck}

ステップ6：移行の進捗状況をビュー {#step-6-view-the-migration-progress}

ステップ6：移行の進捗状況を監視する {#step-6-monitor-the-migration-progress}

ステップ6：仕様を選択して移行を開始する {#step-6-choose-a-spec-and-start-migration}

ステップ7：移行の進捗状況をビュー {#step-7-view-the-migration-progress}

移行ジョブ仕様を拡張する {#scale-a-migration-job-specification}

制限事項 {#limitations}

スケーリング手順 {#scaling-procedure}

Uh oh!

FilesExpand file tree

migrate-from-mysql-using-data-migration.md

Latest commit

History

migrate-from-mysql-using-data-migration.md

File metadata and controls

データ移行を使用してMySQL互換データベースをTiDB Cloudに移行する {#migrate-mysql-compatible-databases-to-tidb-cloud-using-data-migration}

制限事項 {#limitations}

可用性 {#availability}

移行ジョブの最大数 {#maximum-number-of-migration-jobs}

フィルタリングおよび削除されたデータベース {#filtered-out-and-deleted-databases}

Alibaba Cloud RDSの制限事項 {#limitations-of-alibaba-cloud-rds}

Alibaba Cloud PolarDB-Xの制限事項 {#limitations-of-alibaba-cloud-polardb-x}

既存のデータ移行の限界 {#limitations-of-existing-data-migration}

増分データ移行の限界 {#limitations-of-incremental-data-migration}

前提条件 {#prerequisites}

データソースとバージョンがサポートされていることを確認してください。 {#make-sure-your-data-source-and-version-are-supported}

レプリケーションのために、ソースのMySQL互換データベースでバイナリログを有効にする {#enable-binary-logs-in-the-source-mysql-compatible-database-for-replication}

現在の値を確認し、ソースのMySQLインスタンスを設定します。 {#check-current-values-and-configure-the-source-mysql-instance}

ネットワーク接続を確保する {#ensure-network-connectivity}

TLS/SSLによるエンドツーエンド暗号化 {#end-to-end-encryption-over-tls-ssl}

公開エンドポイントまたはIPアドレス {#public-endpoints-or-ip-addresses}

プライベートリンクまたはプライベートエンドポイント {#private-link-or-private-endpoint}

VPCピアリング {#vpc-peering}

移行に必要な権限を付与する {#grant-required-privileges-for-migration}

ソースMySQLデータベースで、移行ユーザーに必要な権限を付与します。 {#grant-required-privileges-to-the-migration-user-in-the-source-mysql-database}

対象のTiDB Cloudリソースで必要な権限を付与する {#grant-required-privileges-in-the-target-tidb-cloud-resource}

ステップ1：データ移行ページに移動します {#step-1-go-to-the-data-migration-page}

ステップ2：ソース接続とターゲット接続を設定する {#step-2-configure-the-source-and-target-connections}

ステップ3：移行ジョブの種類を選択する {#step-3-choose-migration-job-type}

既存データと増分データを移行する {#migrate-existing-data-and-incremental-data}

既存データのみを移行する {#migrate-only-existing-data}

増分データのみを移行する {#migrate-only-incremental-data}

ステップ4：移行するオブジェクトを選択する {#step-4-choose-the-objects-to-be-migrated}

ステップ5：事前チェック {#step-5-precheck}

ステップ6：移行の進捗状況をビュー {#step-6-view-the-migration-progress}

ステップ6：移行の進捗状況を監視する {#step-6-monitor-the-migration-progress}

ステップ6：仕様を選択して移行を開始する {#step-6-choose-a-spec-and-start-migration}

ステップ7：移行の進捗状況をビュー {#step-7-view-the-migration-progress}

移行ジョブ仕様を拡張する {#scale-a-migration-job-specification}

制限事項 {#limitations}

スケーリング手順 {#scaling-procedure}