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

PostgreSQL、Oracle、SQL Server などの異種データベースをTiDB Cloudに移行する場合は、AWS Database Migration Service (AWS DMS) を使用することをお勧めします。

AWS DMS は、リレーショナルデータベース、データウェアハウス、NoSQL データベース、その他の種類のデータストアの移行を容易にするクラウドサービスです。AWS DMS を使用して、データをTiDB Cloudに移行できます。

このドキュメントでは、Amazon RDS を例に、AWS DMS を使用してデータをTiDB Cloudに移行する方法を説明します。この手順は、セルフホスト型 MySQL データベースまたは Amazon AuroraからTiDB Cloudにデータを移行する場合にも適用されます。

この例では、データソースは Amazon RDS で、データの送信先はTiDB Cloud内のTiDB Cloud Dedicated クラスターです。アップストリームデータベースとダウンストリームデータベースは両方とも同じリージョンにあります。

前提条件

移行を開始する前に、必ず次の内容をお読みください。

ソースデータベースが Amazon RDS または Amazon Auroraの場合、 binlog_formatパラメータをROWに設定する必要があります。データベースがデフォルトのパラメータグループを使用する場合、 binlog_formatパラメータはデフォルトでMIXEDなり、変更できません。この場合、新しいパラメータグループを作成する、たとえばnewset設定し、そのbinlog_formatをROWに設定する必要があります。次に、デフォルトのパラメータグループを変更するをnewsetに設定します。パラメータグループを変更すると、データベースが再起動されることに注意してください。
ソースデータベースが TiDB と互換性のある照合順序を使用していることを確認してください。TiDB の utf8mb4 文字セットのデフォルトの照合順序はutf8mb4_binです。ただし、MySQL 8.0 では、デフォルトの照合順序はutf8mb4_0900_ai_ciです。アップストリーム MySQL がデフォルトの照合順序を使用している場合、TiDB はutf8mb4_0900_ai_ciと互換性がないため、AWS DMS は TiDB にターゲットテーブルを作成できず、データを移行できません。この問題を解決するには、移行前にソースデータベースの照合順序をutf8mb4_binに変更する必要があります。TiDB でサポートされている文字セットと照合順序の完全なリストについては、文字セットと照合順序を参照してください。
TiDB PERFORMANCE_SCHEMA INFORMATION_SCHEMA mysql sys test移行タスクを作成するときは、デフォルトの%を使用して移行オブジェクトを選択するのではなく、これらのシステムデータベースを除外する必要があります。そうしないと、AWS DMS はこれらのシステムデータベースをソースデータベースからターゲット TiDB に移行しようとし、タスクが失敗します。この問題を回避するには、特定のデータベース名とテーブル名を入力することをお勧めします。
AWS DMS のパブリックおよびプライベートネットワーク IP アドレスを、ソースデータベースとターゲットデータベースの両方の IP アクセスリストに追加します。そうしないと、シナリオによってはネットワーク接続が失敗する可能性があります。
VPC ピアリングまたはプライベートエンドポイント接続を使用して、AWS DMS と TiDB クラスターを接続します。
より優れたデータ書き込みパフォーマンスを得るには、AWS DMS と TiDB クラスターに同じリージョンを使用することをお勧めします。
AWS DMS dms.t3.large (2 vCPU および 8 GiBメモリ) 以上のインスタンスクラスを使用することをお勧めします。インスタンスクラスが小さいと、メモリ不足 (OOM) エラーが発生する可能性があります。
AWS DMS はターゲットデータベースにawsdms_controlデータベースを自動的に作成します。

制限

AWS DMS はDROP TABLEレプリケーションをサポートしていません。
AWS DMS は、テーブルとプライマリキーの作成を含む基本的なスキーマ移行をサポートしています。ただし、AWS DMS はTiDB Cloudにセカンダリインデックス、外部キー、またはユーザーアカウントを自動的に作成しません。必要に応じて、セカンダリインデックスを含むテーブルを含むこれらのオブジェクトを TiDB に手動で作成する必要があります。詳細については、 AWS Database Migration Service の移行計画参照してください。

ステップ1. AWS DMSレプリケーションインスタンスを作成する

AWS DMS コンソールのレプリケーションインスタンスページに移動し、対応するリージョンに切り替えます。AWS DMS にはTiDB Cloudと同じリージョンを使用することをお勧めします。このドキュメントでは、アップストリームおよびダウンストリームデータベースと DMS インスタンスはすべてus-west-2リージョンにあります。
レプリケーションインスタンスの作成をクリックします。
インスタンス名、ARN、説明を入力します。
インスタンス構成を入力します。
- インスタンスクラス: 適切なインスタンスクラスを選択します。パフォーマンスを向上させるには、 dms.t3.large以上のインスタンスクラスを使用することをお勧めします。
- エンジンバージョン: デフォルト構成を使用します。
- マルチ AZ : ビジネスニーズに応じて、シングル AZまたはマルチ AZを選択します。
割り当てられたstorage(GiB)フィールドでstorageを構成します。デフォルトの構成を使用します。
接続とセキュリティを構成します。
- ネットワークタイプ - 新規: IPv4を選択します。
- IPv4 用の仮想プライベートクラウド (VPC) : 必要な VPC を選択します。ネットワーク構成を簡素化するために、アップストリームデータベースと同じ VPC を使用することをお勧めします。
- レプリケーションサブネットグループ: レプリケーションインスタンスのサブネットグループを選択します。
- パブリックアクセス可能: デフォルトの設定を使用します。
必要に応じて、詳細設定、メンテナンス、タグを構成します。 「レプリケーションインスタンスの作成」をクリックして、インスタンスの作成を完了します。

ステップ2. ソースデータベースエンドポイントを作成する

AWS DMS コンソールで、先ほど作成したレプリケーションインスタンスをクリックします。次のスクリーンショットに示すように、パブリックおよびプライベートネットワークの IP アドレスをコピーします。
Amazon RDS のセキュリティグループルールを設定します。この例では、AWS DMS インスタンスのパブリック IP アドレスとプライベート IP アドレスをセキュリティグループに追加します。
[エンドポイントの作成] をクリックして、ソースデータベースエンドポイントを作成します。
この例では、 「RDS DB インスタンスの選択」をクリックし、ソース RDS インスタンスを選択します。ソースデータベースがセルフホスト型 MySQL の場合は、この手順をスキップして、次の手順で情報を入力できます。
次の情報を設定します。
- エンドポイント識別子: 後続のタスク構成で識別できるように、ソースエンドポイントのラベルを作成します。
- 記述的な Amazon リソース名 (ARN) - オプション: デフォルトの DMS ARN のわかりやすい名前を作成します。
- ソースエンジン: MySQLを選択します。
- エンドポイントデータベースへのアクセス:アクセス情報を手動で提供するを選択します。
- サーバー名: データプロバイダーのデータサーバーの名前を入力します。データベースコンソールからコピーできます。アップストリームが Amazon RDS または Amazon Auroraの場合は、名前が自動的に入力されます。ドメイン名のないセルフホスト MySQL の場合は、IP アドレスを入力できます。
- ソースデータベースのポート、ユーザー名、およびパスワードを入力します。
- セキュリティ Socket Layer (SSL) モード: 必要に応じて SSL モードを有効にすることができます。
エンドポイント設定、 KMS キー、タグにはデフォルト値を使用します。エンドポイント接続のテスト (オプション)セクションでは、ネットワーク構成を簡素化するために、ソースデータベースと同じ VPC を選択することをお勧めします。対応するレプリケーションインスタンスを選択し、テストの実行をクリックします。ステータスは成功である必要があります。
[エンドポイントの作成]をクリックします。

ステップ3. ターゲットデータベースエンドポイントを作成する

AWS DMS コンソールで、先ほど作成したレプリケーションインスタンスをクリックします。次のスクリーンショットに示すように、パブリックおよびプライベートネットワークの IP アドレスをコピーします。
TiDB Cloudコンソールで、 クラスターページに移動し、ターゲットクラスターの名前をクリックして、右上隅の[接続] をクリックし、 TiDB Cloudデータベース接続情報を取得します。
ダイアログの「ステップ 1: トラフィックフィルターの作成」で、 「編集」をクリックし、AWS DMS コンソールからコピーしたパブリックおよびプライベートネットワークの IP アドレスを入力して、 「フィルターの更新」をクリックします。AWS DMS レプリケーションインスタンスのパブリック IP アドレスとプライベート IP アドレスを TiDB クラスターのトラフィックフィルターに同時に追加することをお勧めします。そうしないと、一部のシナリオで AWS DMS が TiDB クラスターに接続できない可能性があります。
CA 証明書をダウンロードするには、 -h CA 証明書のダウンロード」をクリックします。ダイアログの「手順 3: SQL クライアントで接続する」で、接続文字列の-u 、および-P情報を後で使用するためにメモします。
ダイアログの「VPC ピアリング」タブをクリックし、 「ステップ 1: VPC のセットアップ」の下にある「追加」をクリックして、TiDB クラスターと AWS DMS の VPC ピアリング接続を作成します。
対応する情報を設定します。1 VPC ピアリング接続を設定する参照してください。
TiDB クラスターのターゲットエンドポイントを構成します。
- エンドポイントタイプ:ターゲットエンドポイントを選択します。
- エンドポイント識別子: エンドポイントの名前を入力します。
- 記述的な Amazon リソース名 (ARN) - オプション: デフォルトの DMS ARN のわかりやすい名前を作成します。
- ターゲットエンジン: MySQLを選択します。
AWS DMS コンソールで、 [エンドポイントの作成]をクリックしてターゲットデータベースエンドポイントを作成し、次の情報を構成します。
- サーバー名: 記録した-hの情報である TiDB クラスターのホスト名を入力します。
- ポート: 記録した-Pの情報である TiDB クラスターのポートを入力します。TiDB クラスターのデフォルトポートは 4000 です。
- ユーザー名: 記録した-uの情報である TiDB クラスターのユーザー名を入力します。
- パスワード: TiDB クラスターのパスワードを入力します。
- セキュリティ Socket Layer (SSL) モード: Verify-caを選択します。
- 「新しい CA 証明書の追加」をクリックして、前の手順でTiDB Cloudコンソールからダウンロードした CA ファイルをインポートします。
CA ファイルをインポートします。
エンドポイント設定、 KMS キー、タグにはデフォルト値を使用します。エンドポイント接続のテスト (オプション)セクションで、ソースデータベースと同じ VPC を選択します。対応するレプリケーションインスタンスを選択し、テストの実行をクリックします。ステータスは成功である必要があります。
[エンドポイントの作成]をクリックします。

ステップ4. データベース移行タスクを作成する

AWS DMS コンソールで、データ移行タスクページに移動します。リージョンに切り替えます。次に、ウィンドウの右上隅にある[タスクの作成] をクリックします。
次の情報を設定します。
- タスク識別子: タスクの名前を入力します。覚えやすい名前を使用することをお勧めします。
- 記述的な Amazon リソース名 (ARN) - オプション: デフォルトの DMS ARN のわかりやすい名前を作成します。
- レプリケーションインスタンス: 先ほど作成した AWS DMS インスタンスを選択します。
- ソースデータベースエンドポイント: 先ほど作成したソースデータベースエンドポイントを選択します。
- ターゲットデータベースエンドポイント: 作成したターゲットデータベースエンドポイントを選択します。
- 移行タイプ: 必要に応じて移行タイプを選択します。この例では、「既存のデータを移行し、進行中の変更を複製する」を選択します。
次の情報を設定します。
- 編集モード:ウィザードを選択します。
- ソーストランザクションのカスタム CDC 停止モード: デフォルト設定を使用します。
- ターゲットテーブル準備モード: 必要に応じて、 [何もしない]またはその他のオプションを選択します。この例では、 [何もしない]を選択します。
- フルロードが完了したらタスクを停止します。デフォルト設定を使用します。
- レプリケーションに LOB 列を含める:制限付き LOB モードを選択します。
- 最大 LOB サイズ (KB) : デフォルト値32を使用します。
- 検証をオンにします。必要に応じて選択します。
- タスクログ: 今後のトラブルシューティングのためにCloudWatch ログをオンにするを選択します。関連する構成にはデフォルト設定を使用します。
テーブルマッピングセクションで、移行するデータベースを指定します。
スキーマ名は、Amazon RDS インスタンス内のデータベース名です。ソース名のデフォルト値は「%」で、これは Amazon RDS 内のすべてのデータベースが TiDB に移行されることを意味します。これにより、Amazon RDS 内のmysqlやsysなどのシステムデータベースが TiDB クラスターに移行され、タスクが失敗します。したがって、特定のデータベース名を入力するか、すべてのシステムデータベースを除外することをお勧めします。たとえば、次のスクリーンショットの設定によると、 franktestという名前のデータベースとそのデータベース内のすべてのテーブルのみが移行されます。
右下隅の「タスクの作成」をクリックします。
データ移行タスクページに戻ります。地域に切り替えます。タスクのステータスと進行状況を確認できます。

移行中に問題や障害が発生した場合は、クラウドウォッチのログ情報を確認して問題のトラブルシューティングを行うことができます。

Troubleshooting

参照

AWS DMS をTiDB Cloud Serverless またはTiDB Cloud Dedicated に接続する方法の詳細については、 AWS DMS をTiDB Cloudクラスターに接続する参照してください。
Aurora MySQL や Amazon Relational Database Service (RDS) などの MySQL 互換データベースからTiDB Cloudに移行する場合は、 TiDB Cloud上のデータ移行使用することをお勧めします。
AWS DMS を使用して Amazon RDS for Oracle からTiDB Cloud Serverless に移行する場合は、 AWS DMS を使用して Amazon RDS for Oracle からTiDB Cloud Serverless に移行する参照してください。