すべてのプロダクト
Search
ドキュメントセンター

Data Transmission Service:PolarDB-X 2.0 インスタンスから ApsaraDB RDS for MySQL インスタンスへのデータ移行

最終更新日:Mar 29, 2026

Data Transmission Service (DTS) を使用して、PolarDB-X 2.0 インスタンスから ApsaraDB RDS for MySQL インスタンスへ最小限のダウンタイムでデータを移行します。DTS はスキーマ移行、完全なデータ移行、増分データ移行をサポートしているため、移行中もソースデータベースをオンラインのまま維持できます。

前提条件

作業を開始する前に、以下の要件を満たしていることを確認してください。

  • MySQL 5.7 と互換性のある PolarDB-X 2.0 インスタンス

  • 宛先の ApsaraDB RDS for MySQL インスタンス。詳細については、「ApsaraDB RDS for MySQL インスタンスの作成」をご参照ください。

  • 宛先インスタンスに、ソースインスタンスの全データサイズを超える空きストレージ容量があること

課金

移行タイプインスタンス構成料金インターネットトラフィック料金
スキーマ移行+完全なデータ移行無料Alibaba Cloud からインターネット経由で移行する場合のみ課金されます。詳細については、「課金概要」をご参照ください。
増分データ移行課金対象です。詳細については、「課金概要」をご参照ください。詳細については、「課金概要」をご参照ください。

必要な権限

DTS が使用するデータベースアカウントに、以下の権限を付与してください。

データベーススキーマ移行完全なデータ移行増分データ移行
PolarDB-X 2.0SELECTSELECTREPLICATION SLAVE、REPLICATION CLIENT、SELECT
ApsaraDB RDS for MySQL読み取りおよび書き込み読み取りおよび書き込み読み取りおよび書き込み

ソースの PolarDB-X 2.0 インスタンスおよび宛先の ApsaraDB RDS for MySQL インスタンスでアカウントを作成し、権限を付与する手順については、「アカウントの作成」および「アカウントの権限の変更」をご参照ください。

制限事項

ソースデータベース

カテゴリ制限事項
帯域幅ソースデータベースサーバーには十分なアウトバウンド帯域幅が必要です。帯域幅が低いと、移行速度が低下します。
テーブル構造テーブルにはプライマリキーまたは一意制約が必要であり、すべてのフィールドが一意である必要があります。これらの制約がないテーブルは、ターゲットデータベースに重複レコードを生成する可能性があります。
テーブル数テーブルを移行オブジェクトとして選択し、宛先データベースで名前を変更する必要がある場合、1 つのタスクで最大 1,000 個のテーブルをサポートします。1,000 個を超える場合は、複数のタスクを作成するか、データベース単位で移行を行ってください。
移行中の DDLスキーマ移行および完全なデータ移行中は、データベースまたはテーブルスキーマを変更する DDL 操作を実行しないでください。これにより、タスクが失敗します。
ネットワーク変更移行中に PolarDB-X インスタンスのネットワークタイプを変更する場合、DTS タスクのネットワーク接続設定を適宜更新してください。
完全移行中の書き込み増分データ移行を含まない完全なデータ移行中は、ソースデータベースへの書き込みを行わないでください。整合性を保証するには、スキーマ移行、完全なデータ移行、増分データ移行を同時に選択してください。

増分データ移行の要件

増分データ移行を行うには、ソースデータベースが以下の要件を満たしている必要があります。

  • バイナリログが有効になっており、binlog_row_imagefull に設定されていること。この設定が行われていない場合、事前チェックに失敗し、タスクを開始できません。

  • バイナリログの保持期間:ログの保持期間が短すぎると、DTS がログを読み取れず、タスクが失敗する可能性があります。例外的なケースでは、データ損失や不整合が発生する可能性があります。完全移行完了後は、保持期間を 24 時間以上に短縮できます。

    • 増分移行のみの場合:ログを 24 時間以上保持

    • 完全移行 + 増分移行の場合:ログを少なくとも 7 日間保持

警告

バイナリログの保持期間が上記要件を満たしていない場合、DTS はサービスレベル契約 (SLA) を保証しません。

その他の制限事項

  • 移行前に、ソースおよび宛先データベースへのパフォーマンスへの影響を評価してください。移行はオフピーク時間帯に実行することを推奨します。完全なデータ移行中、DTS はソースおよび宛先データベースの読み取り・書き込みリソースを使用するため、データベースサーバーの負荷が増加する可能性があります。

  • 完全なデータ移行中、同時実行の INSERT 操作により、宛先テーブルに断片化が発生します。完全移行後、宛先の表領域はソースよりも大きくなります。

  • DTS は失敗したタスクを最大 7 日間リトライします。ワークロードを宛先データベースに切り替える前に、失敗したタスクを停止またはリリースするか、REVOKE を実行して、宛先データベースに対する DTS の書き込み権限を削除してください。そうしないと、再開された失敗タスクが宛先のデータを上書きする可能性があります。

注意事項

  • DTS は、バイナリログの位置を進めるために、定期的にソースデータベース内の dts_health_check.ha_health_check テーブルを更新します。

  • DTS は、送信先の ApsaraDB RDS for MySQL インスタンスにデータベースを自動的に作成します。ソースデータベース名が無効な場合、移行タスクを設定する前に手動でデータベースを作成してください。詳細については、「データベースの管理」をご参照ください。

移行タイプ

DTS は、以下の 3 種類の移行タイプをサポートしており、要件に応じて組み合わせて使用できます。

移行タイプ機能推奨用途
スキーマ移行選択したオブジェクトのスキーマをソースから宛先に移行常に含めてください
完全なデータ移行ソースから宛先に既存の全データを移行初期データコピー
増分データ移行完全移行完了後、ソースから宛先に変更内容を継続的にレプリケートダウンタイムの最小化

最小限のダウンタイムで移行するには、3 つのタイプすべてを選択してください。増分移行により、ソースおよび宛先データベースが同期された状態を維持できるため、準備が整った時点で切り替えられます。

サポートされる移行オブジェクト

オブジェクトタイプサポート注記
テーブル (プライマリキーまたは一意制約あり)はい
インデックスはいスキーマ移行の一部として移行されます
ビュー、トリガー、ストアドプロシージャいいえテーブルまたはカラムをオブジェクトとして選択した場合、これらは移行されません。これらを移行するには、データベース全体をオブジェクトとして選択してください。
プライマリキーまたは一意制約のないテーブルいいえ宛先に重複レコードが発生する可能性があります

増分移行中にサポートされる SQL 操作

タイプ操作
DMLINSERT、UPDATE、DELETE
DDLALTER TABLE;CREATE FUNCTION、CREATE INDEX、CREATE TABLE;DROP INDEX、DROP TABLE;RENAME TABLE;TRUNCATE TABLE
説明

RENAME TABLE 操作はデータの不整合を引き起こす可能性があります。テーブルを移行オブジェクトとして選択し、移行中にそのテーブル名を変更すると、そのテーブルのデータは宛先に移行されません。これを回避するには、個別のテーブルではなく、データベース全体を移行オブジェクトとして選択してください。

データ移行タスクの作成

ステップ 1:データ移行タスクページへのアクセス

  1. Data Management (DMS) コンソールにログインします。

  2. 上部のナビゲーションバーで、DTS 上にポインターを合わせます。

  3. DTS (DTS) > データ移行 を選択します。

説明

また、新しい DTS コンソールのデータ移行ページに直接アクセスすることもできます。ナビゲーションは、DMS コンソールモードによって異なる場合があります。詳細については、「シンプルモード」および「DMS コンソールのレイアウトとスタイルをカスタマイズする」をご参照ください。

ステップ 2:リージョンの選択

データ移行タスク の右側にあるドロップダウンリストから、移行インスタンスが配置されているリージョンを選択します。

説明

新しい DTS コンソールでは、左上隅でリージョンを選択します。

ステップ 3:ソースおよび宛先データベースの設定

  1. タスクの作成 をクリックします。

  2. [データ移行タスクの作成] ページで、先に進む前にページ上部に表示される 制限事項 を確認します。

  3. ソースデータベースを設定します。

    パラメーター
    タスク名わかりやすい名前を入力します。名前は一意である必要はありません。
    DMS データベースインスタンスの選択既存のデータベースを選択するか、新しいものを設定します。
    データベースタイプPolarDB-X 2.0
    アクセス方法Alibaba Cloud インスタンス
    インスタンスリージョンソース PolarDB-X インスタンスのリージョン
    インスタンス IDソース PolarDB-X インスタンスの ID
    データベースアカウント必要な権限を持つアカウント(「必要な権限」を参照)
    データベースパスワードアカウントのパスワード
  4. 宛先データベースを設定します。

    パラメーター
    DMS データベースインスタンスの選択既存のデータベースを選択するか、新しいものを設定します。
    データベースタイプMySQL
    アクセス方法Alibaba Cloud インスタンス
    インスタンスリージョン宛先 ApsaraDB RDS for MySQL インスタンスのリージョン
    RDS インスタンス ID宛先 ApsaraDB RDS for MySQL インスタンスの ID
    データベースアカウント読み取りおよび書き込み権限を持つアカウント
    データベースパスワードアカウントのパスワード
    暗号化[暗号化なし]」または「[SSL 暗号化]」を選択します。SSL 暗号化を使用するには、まず RDS インスタンスで SSL を有効化する必要があります。詳細については、「クラウド証明書を使用して SSL 暗号化を有効化する」をご参照ください。

ステップ 4:接続性のテスト

接続性をテストして次へ をクリックします。

DTS は、自動的にそのサーバーの CIDR ブロックを Alibaba Cloud データベースインスタンスの IP アドレスホワイトリストに追加します。自己管理データベースの場合、これらの CIDR ブロックを手動で追加する必要があります。詳細については、「DTS サーバーの CIDR ブロック」をご参照ください。

警告

データベースのホワイトリストまたはセキュリティグループルールに DTS サーバーの CIDR ブロックを追加すると、セキュリティリスクが生じます。強力な認証情報の使用、公開ポートの制限、API 呼び出しの認証、ホワイトリストルールの定期的な監査などの予防措置を講じてください。または、Express Connect、VPN Gateway、Smart Access Gateway を介して接続することを推奨します。

ステップ 5:オブジェクトおよび移行タイプの選択

以下の設定を行います。

パラメーター説明
移行タイプ一度限りの移行を行う場合は、スキーマ移行 および 完全なデータ移行 を選択します。データを同期したまま維持し、ダウンタイムを最小限に抑えるには、増分データ移行 を追加します。
競合テーブルの処理モード事前チェックとエラー報告: ソースと送信先に同じ名前のテーブルが存在する場合、事前チェックに失敗します。オブジェクト名マッピングを使用して競合を解決します。 エラーを無視して続行: チェックをスキップします。完全移行中はプライマリキーが一致する既存の送信先レコードが保持されますが、増分移行中は上書きされます。注意して続行してください。
ソースオブジェクトソースオブジェクト からオブジェクトを選択し、 アイコンを使用して 選択済みオブジェクトRightwards arrow に移動します。カラム、テーブル、スキーマを選択できます。テーブルまたはカラムを選択すると、ビュー、トリガー、ストアドプロシージャは除外されます。
選択済みオブジェクトオブジェクトを右クリックして、名前を変更する、フィルター条件を追加する、または移行する特定のSQL 操作を選択します。複数のオブジェクトを一度に名前変更するには、[一括編集] をクリックします。注意:オブジェクトの名前を変更すると、依存オブジェクトが失敗する場合があります。「オブジェクト名のマッピング」および「フィルター条件の指定」をご参照ください。

ステップ 6:詳細設定の構成

次へ:詳細設定 をクリックし、以下の項目を設定します。

パラメーター説明
モニタリングとアラートタスクが失敗した場合や移行遅延が設定したしきい値を超えた場合にアラートを受信するには、[Yes] を選択します。アラートのしきい値と通知設定を構成してください。詳細については、「モニタリングとアラートの設定」をご参照ください。
失敗した接続のリトライ時間DTS が失敗した接続をリトライする時間範囲です。有効値:10~1440 分。デフォルト値:720 分。30 分を超える値を設定してください。この期間内に DTS が再接続できれば、タスクは再開されます。それ以外の場合は、タスクは失敗します。注:リトライ中も DTS の課金は継続されます。
ETL の設定抽出・変換・書き出し (ETL) 機能を有効にするには、[Yes] を選択し、データ処理文を入力します。詳細については、「ETL とは」および「データ移行またはデータ同期タスクでの ETL の設定」をご参照ください。
転送および逆再生タスクのハートビートテーブルに対する SQL 操作の削除設定[Yes]:DTS はソースデータベースにハートビート SQL を書き込みませんが、メトリック上に移行遅延が表示される可能性があります。[No]:DTS はハートビート SQL を書き込みます。これにより、ソースデータベース上の物理バックアップおよびクローン操作に影響を与える可能性があります。

ステップ 7:事前チェックの実行

次へ:タスク設定の保存と事前チェック をクリックします。

説明

このタスクの API パラメーターをプレビューするには、次へ:タスク設定の保存と事前チェック 上にポインターを合わせ、OpenAPI パラメーターのプレビュー をクリックします。

DTS は自動的に事前チェックを実行します。先に進む前に、問題を解決してください。

  • 失敗した項目詳細を表示 をクリックして報告された問題を修正し、その後 再度事前チェック をクリックします。

  • タスクをブロックするアラート項目詳細を表示 をクリックして問題を修正し、再度事前チェックを実行します。

  • 無視可能なアラート項目アラートの詳細を確認 > 無視 > OK をクリックし、その後 再度事前チェック をクリックします。アラートを無視すると、データの不整合が発生する可能性があります。

ステップ 8:インスタンスの購入

  1. 成功率100% になるまで待ちます。

  2. 次へ:インスタンスの購入 をクリックします。

  3. インスタンスの購入 ページで、インスタンスを設定します。

    パラメーター説明
    [リソースグループ]移行インスタンスのリソースグループです。デフォルト:デフォルトリソースグループ。詳細については、「Resource Management とは
    [インスタンスクラス]必要な移行速度に基づいてインスタンスクラスを選択します。詳細については、「データ移行インスタンスのインスタンスクラス」をご参照ください。
  4. Data Transmission Service (従量課金) サービス利用規約 チェックボックスをオンにします。

  5. 購入して開始 をクリックし、確認ダイアログで OK をクリックします。

データ移行ページでタスクの進行状況をモニタリングします。

宛先データベースへの切り替え

アプリケーションを宛先データベースに切り替える前に、以下の手順を実行してください。

  1. ソースデータベースへの書き込みを停止します。

  2. 増分データ移行の遅延が 0 になり、ソースと宛先のデータギャップが解消されたことを確認します。両方の値が安定するまで待ってから、次のステップに進んでください。

  3. 移行タスクを停止またはリリースします。

  4. アプリケーションの接続文字列を更新して、宛先の ApsaraDB RDS for MySQL インスタンスを指すようにします。

警告

DTS は失敗したタスクを最大 7 日間リトライします。切り替え前にタスクを停止しない場合、再開されたタスクが宛先データベースのデータを上書きする可能性があります。切り替え前に、タスクを停止するか、REVOKE を実行して DTS の書き込み権限を削除してください。

次のステップ