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

Data Transmission Service:PolarDB-X 1.0 インスタンスから AnalyticDB for MySQL 3.0 クラスターへのデータ移行

最終更新日:Mar 29, 2026

Data Transmission Service (DTS) を使用して、PolarDB-X 1.0 インスタンスから AnalyticDB for MySQL 3.0 クラスターへデータを移行します。本トピックでは、前提条件、ソースおよびターゲットデータベースの要件、必要な権限、および移行タスクの手順に沿った構成方法について説明します。

前提条件

開始する前に、以下の点を確認してください。

  • PolarDB-X 1.0 のソースインスタンスが存在すること。PolarDB-X 1.0 インスタンスの作成をご参照ください。

    重要

    PolarDB-X 1.0 インスタンスのストレージタイプは、ApsaraDB RDS for MySQL(カスタムまたは購入済みインスタンス)である必要があります。PolarDB for MySQL は、ストレージタイプとしてサポートされていません。

  • ソース PolarDB-X 1.0 インスタンスのバージョンが 5.2 以降であり、MySQL 5.7 と互換性があること。

  • ターゲットとなる AnalyticDB for MySQL 3.0 クラスターが存在し、そのストレージ容量がソースインスタンスの使用済みストレージ容量より大きいこと。クラスターの作成をご参照ください。

  • (増分移行のみ)移行対象のデータの文字セットが utf8mb3 でないこと。utf8mb3 データを増分で移行すると、タスクが失敗します。

制限事項

ソースデータベースの制限

制限事項詳細
帯域幅ソースサーバーには十分なアウトバウンド帯域幅が必要です。帯域幅が不足していると、移行速度が低下します。
テーブル構造テーブルには、すべてのフィールドが一意である PRIMARY KEY または一意制約(UNIQUE constraint)が必要です。該当する制約がない場合、ターゲット側に重複レコードが発生する可能性があります。
テーブル数(テーブルレベルの移行)列名またはテーブル名の変更を伴う個別テーブルの移行では、1 つのタスクで最大 1,000 個のテーブルをサポートします。この上限を超えるとリクエストエラーが発生します。作業を複数のタスクに分割するか、データベースレベルでの移行を選択してください。
バイナリログ(増分移行)バイナリログが有効化されていること、および binlog_row_imagefull に設定されていることが必要です。設定されていない場合、事前チェックに失敗し、タスクを開始できません。
バイナリログの保持期間(増分移行)増分のみのタスク:ログを 24 時間以上保持してください。完全+増分のタスク:ログを最低 7 日間保持してください。DTS が読み取る前にログがパージされると、タスクが失敗し、データ損失またはデータの不整合が発生する可能性があります。完全移行が完了した後は、保持期間を 24 時間以上に短縮できます。
移行中の禁止操作タスク実行中に、ソースインスタンスに対してスケーリング、縮小、ホットテーブル移行、シャードキーの変更、DDL 変更などの操作を実行しないでください。これらの操作により、タスクが失敗します。
ネットワークタイプの変更移行中に PolarDB-X 1.0 インスタンスのネットワークタイプを切り替える場合、切り替え完了後に移行タスクの接続情報を更新してください。

外部キーの動作

DTS はスキーマ移行時に外部キー(foreign keys)を移行しません。完全および増分データ移行中、DTS はセッションレベルで外部キー制約チェックおよびカスケード操作を一時的に無効化します。この期間中にソース側でカスケード更新または削除が発生した場合、データの不整合が生じる可能性があります。

その他の制限事項

制限事項詳細
ターゲット側のプライマリキーターゲットデータベースにはカスタムのプライマリキーが必要です。または、「データベース・テーブル・カラムの構成」ステップで プライマリキー列 を設定してください。プライマリキーが設定されていない場合、移行が失敗する可能性があります。
移行タイミング非ピーク時間帯に移行を実行してください。完全データ移行では、両方のデータベースで読み取りおよび書き込みリソースが使用されるため、サーバー負荷が増加します。
完全移行後の表領域サイズ完全データ移行中の並列 INSERT 操作により、ターゲット側で断片化が発生します。完全移行完了後、ターゲットの表領域はソースよりも大きくなります。
タスクの自動再開DTS は、失敗したタスクを最大 7 日間再試行します。ワークロードをターゲットに切り替える前に、タスクを停止または解放するか、REVOKE を使用して DTS アカウントの書き込み権限を取り消してください。そうしないと、再開されたタスクによって、ターゲット側のデータがソース側のデータで上書きされます。
バックアップとの競合DTS タスク実行中に AnalyticDB for MySQL 3.0 クラスターがバックアップを開始すると、DTS タスクが失敗します。
テクニカルサポートによるタスク復旧タスクが失敗した場合、DTS テクニカルサポートは 8 時間以内に復旧を試みます。復旧中にタスクが再起動されたり、タスクパラメーターが変更されたりすることがあります。ただし、データベースパラメーターは変更されません。

その他の注意事項

DTS は定期的にソースデータベース内の dts_health_check.ha_health_check テーブルに書き込みを行い、バイナリログ位置を進める動作を行います。これは想定された正常な動作です。

課金

移行タイプリンク構成料金データ転送料金
スキーマ移行+完全データ移行無料インターネット経由でデータを移行する場合、アウトバウンドトラフィックに対して課金されます。詳しくは、「課金概要」をご参照ください。
増分データ移行課金対象です。「課金概要」をご参照ください。

移行タイプ

DTS では、本移行パス向けに 3 種類の移行タイプがサポートされています。サービス中断を最小限に抑えたスムーズな移行を行うには、すべての 3 種類を選択してください。

タイプ機能完了後のタスク動作
スキーマ移行選択したオブジェクトのスキーマをターゲットに移行します。外部キーは移行されません。自動的に停止します。
完全データ移行ソースからターゲットへ、すべての既存データを移行します。自動的に停止します。
増分データ移行完全移行完了後、ソースからの変更を継続的にターゲットへレプリケートします。アプリケーションの実行を継続しながら、ターゲットを同期状態に保ちます。継続実行されます — 自動的に停止しません。ワークロードをターゲットに切り替える前に、タスクを手動で停止してください。
完全データ移行のみ(増分なし)を実行する場合、タスク実行中はソースデータベースへの書き込みを避けてください。タスク開始後のソースへの書き込みにより、ソースとターゲットの間でデータの不整合が発生します。

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

操作タイプサポートされる文
DMLINSERT、UPDATE、DELETE
AnalyticDB for MySQL 3.0 のターゲットクラスターへの書き込みにおいて、UPDATE は自動的に REPLACE INTO に変換されます。UPDATE 対象がプライマリキー列の場合、DELETE + INSERT に変換されます。

必要な権限

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

データベーススキーマ移行完全移行増分移行
PolarDB-X 1.0SELECTSELECTREPLICATION SLAVE、REPLICATION CLIENT、および移行対象オブジェクトに対する SELECT
AnalyticDB for MySQL 3.0アクセス制御リスト
REPLICATION SLAVE および REPLICATION CLIENT は、増分移行にのみ必要です。完全移行のみのタスクでは、これらの特権は不要です。

アカウントの作成および権限の付与に関する手順については、以下をご参照ください。

データ型のマッピング

スキーマ移行におけるデータ型のマッピング」をご参照ください。

移行タスクの作成

ステップ 1:データ移行ページへ移動

DTS コンソールまたは DMS コンソールのいずれかを使用します。

DTS コンソール

  1. DTS コンソール にログインします。

  2. 左側のナビゲーションウィンドウで、データ移行 をクリックします。

  3. 左上隅で、移行インスタンスが存在するリージョンを選択します。

DMS コンソール

手順は、DMS コンソールのモードおよびレイアウトによって異なる場合があります。「シンプルモード」および「DMS コンソールのレイアウトおよびスタイルのカスタマイズ」をご参照ください。
  1. DMS コンソール にログインします。

  2. 上部のナビゲーションバーで、Data + AI > DTS (DTS) > データ移行 にポインターを合わせます。

  3. データ移行タスク の右側にあるドロップダウンリストから、インスタンスが存在するリージョンを選択します。

ステップ 2:ソースおよびターゲットデータベースの構成

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

  2. 先に、ページ上部に表示される 制限事項 をご確認ください。

  3. 以下のパラメーターを使用して、ソースおよびターゲットデータベースを構成します。

ソースデータベース

パラメーター説明
タスク名DTS タスクの名前です。DTS が自動的に名前を生成します。タスクを容易に識別できるよう、意味のある名前を指定してください。名前は一意である必要はありません。
既存の接続を選択ソースインスタンスがすでに DTS に登録済みの場合は、ドロップダウンリストから選択してください。DTS が残りのパラメーターを自動的に設定します。それ以外の場合は、以下のパラメーターを構成してください。
データベースタイプPolarDB-X 1.0 を選択します。
アクセス方法クラウドインスタンス を選択します。
インスタンスリージョンソース PolarDB-X 1.0 インスタンスが存在するリージョンを選択します。
Alibaba Cloud アカウント間でのデータ複製ソースインスタンスが現在の Alibaba Cloud アカウントに属している場合は、いいえ を選択します。
インスタンス IDソース PolarDB-X 1.0 インスタンスの ID を選択します。
データベースアカウントデータベースアカウントを入力します。「必要な権限」で、必要な最小限の権限をご確認ください。
データベースパスワードデータベースアカウントのパスワードを入力します。

ターゲットデータベース

パラメーター説明
既存の接続を選択ターゲットクラスターがすでに DTS に登録済みの場合は、ドロップダウンリストから選択してください。それ以外の場合は、以下のパラメーターを構成してください。
データベースタイプAnalyticDB MySQL 3.0 を選択します。
アクセス方法クラウドインスタンス を選択します。
インスタンスリージョンターゲット AnalyticDB for MySQL 3.0 クラスターが存在するリージョンを選択します。
インスタンス IDターゲット AnalyticDB for MySQL 3.0 クラスターの ID を選択します。
データベースアカウントデータベースアカウントを入力します。「必要な権限」で、必要な最小限の権限をご確認ください。
データベースパスワードデータベースアカウントのパスワードを入力します。
  1. 接続テストと続行 をクリックします。

    DTS サーバーの IP アドレス範囲を、両方のデータベースのセキュリティ設定に追加する必要があります。DTS が自動的に追加することも、手動で追加することも可能です。「DTS サーバーの CIDR ブロックをオンプレミスデータベースのセキュリティ設定に追加」をご参照ください。

ステップ 3:移行オブジェクトの構成

オブジェクトの構成 ページで、以下のパラメーターを設定します。

パラメーター説明
移行タイプ実行する移行タイプを選択します。サービス中断を最小限に抑えるには、スキーマ移行完全データ移行、および 増分データ移行 を選択してください。完全移行のみを実行するには、スキーマ移行 および 完全データ移行 を選択してください。
説明

「スキーマ移行」をスキップする場合は、ターゲットデータベースおよびテーブルを手動で作成し、「選択されたオブジェクト」でオブジェクト名マッピング機能を有効にしてからタスクを開始してください。

同期対象の DDL および DML 操作インスタンスレベルで、増分移行に同期する SQL 操作を選択します。「増分移行でサポートされる SQL 操作」をご参照ください。データベースまたはテーブルレベルで構成するには、選択済みオブジェクト 内のオブジェクトを右クリックし、ダイアログボックスで操作を選択してください。
テーブルのマージはい を選択すると、選択したすべてのソーステーブルが単一のターゲットテーブルにマージされます。DTS はデータソースを格納するために __dts_data_source 列を追加します。特定のテーブルのみをマージするには、2 つの別々の移行タスクを作成してください。いいえ(デフォルト)を選択すると、テーブルはマージされずに移行されます。
警告

移行中に、ソースデータベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。これにより、データの不整合やタスクの失敗が発生する可能性があります。

競合するテーブルの処理モード事前チェックおよびエラー報告(デフォルト):ターゲットテーブルの名前がソーステーブルと同じかどうかをチェックします。同一の名前が存在する場合、事前チェックに失敗し、タスクを開始できません。オブジェクト名マッピング機能を使用して、競合するテーブルの名前を変更してください。エラーを無視して続行:名前の競合チェックをスキップします。ソースとターゲットのスキーマが同一であり、レコードが既存のターゲットレコードとプライマリキーを共有する場合 — 完全移行では DTS がそのレコードをスキップし、増分移行では上書きします。スキーマが異なる場合、一致するカラムのみが移行されるか、タスクが失敗します。慎重に使用してください。
ターゲットインスタンスにおけるオブジェクト名の大文字小文字ターゲットにおけるデータベース、テーブル、およびカラム名の大文字小文字を制御します。デフォルト: DTS デフォルトポリシー。「ターゲットインスタンスにおけるオブジェクト名の大文字小文字の指定」をご参照ください。
ソースオブジェクト移行するカラム、テーブル、またはデータベースを選択し、Rightwards arrow をクリックして 選択済みオブジェクト に追加します。
説明

テーブルを選択した場合、関連ビュー、トリガー、およびストアドプロシージャは移行されません。データベースを選択した場合:プライマリキーを持つテーブルでは、それを分散キーとして使用します。プライマリキーを持たないテーブルには自動インクリメント主キーが付与されますが、これによりデータの不整合が発生する可能性があります。

選択済みオブジェクト単一のオブジェクトの名前を変更するには、右クリックして「オブジェクトの名前を 1 つずつ変更」の手順に従ってください。複数のオブジェクトを一度に名前変更するには、右上隅の 編集 をクリックしてください。「オブジェクトを一括で名前変更」をご参照ください。
説明

オブジェクトの名前を変更すると、そのオブジェクトに依存する他のオブジェクトの移行が妨げられる可能性があります。行をフィルターするには、テーブルを右クリックして WHERE 条件を設定してください。「フィルター条件の構成」をご参照ください。

ステップ 4:高度な設定の構成

次へ:高度な設定 をクリックし、以下のパラメーターを構成します。

パラメーター説明
タスクスケジューリング用の専用クラスターデフォルトでは、DTS がタスクを共有クラスターにスケジュールします。タスクの安定性を向上させるには、専用クラスターを購入してください。「DTS 専用クラスターとは」をご参照ください。
接続失敗時の再試行時間ソースまたはターゲットデータベースに到達不能な場合の DTS の再試行時間です。有効値:10~1,440 分。デフォルト:720 分。30 分より大きい値を設定してください。再試行ウィンドウ内に DTS が再接続できた場合、タスクは再開されます。再接続できなかった場合、タスクは失敗します。
説明

複数のタスクが同じソースまたはターゲットデータベースを共有する場合、最も最近設定された再試行時間がすべてのタスクに適用されます。再試行中は、インスタンスに対して課金されます。

その他の問題発生時の再試行時間DDL または DML 操作が失敗した場合の DTS の再試行時間です。有効値:1~1,440 分。デフォルト:10 分。10 分より大きい値を設定してください。この値は、接続失敗時の再試行時間 よりも小さくする必要があります。
完全データ移行のスロットリングの有効化完全データ移行中のリソース消費を制限します。ソースデータベースへのクエリ数/秒(QPS)完全データ移行の RPS、および 完全移行のデータ移行速度(MB/s) を構成します。完全データ移行 が選択されている場合にのみ利用可能です。
増分データ移行のスロットリングの有効化増分移行中のリソース消費を制限します。増分データ移行の RPS および 増分移行のデータ移行速度(MB/s) を構成します。増分データ移行 が選択されている場合にのみ利用可能です。
環境タグ組織目的で DTS インスタンスにタグを付けることができます。任意項目です。
ETL の構成はい を選択すると、抽出・変換・書き出し(ETL)機能が有効化され、データ処理文を入力できます。「データ移行またはデータ同期タスクにおける ETL の構成」をご参照ください。いいえ を選択すると、ETL をスキップします。
モニタリングとアラートはい を選択すると、タスクの失敗や移行遅延がしきい値を超えた際に通知を受け取ることができます。アラートのしきい値および通知設定を構成してください。「DTS タスク作成時のモニタリングおよびアラートの構成」をご参照ください。

ステップ 5:データベースおよびテーブルフィールドの構成(任意)

次へ:データベースおよびテーブルフィールドの構成 をクリックし、ターゲットデータベース内のテーブルに対して タイププライマリキー列分散キーパーティションキーパーティションルール、および パーティションライフサイクル を設定します。

このステップは、スキーマ移行 が選択されている場合にのみ利用可能です。定義ステータスすべて に設定すると、すべてのテーブルが表示されます。複数のカラムを複合 プライマリキー列 として選択し、そのうち 1 つ以上のカラムを 分散キー および パーティションキー として選択できます。「CREATE TABLE」をご参照ください。

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

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

ヒント: 保存する前に、OpenAPI パラメーターのプレビュー をクリックすると、このタスクの構成に使用される対応する API オペレーションのパラメーターを確認できます。

DTS はタスク開始前に事前チェックを実行します。いずれかの項目が失敗した場合:

  1. 失敗した項目の横にある 詳細の表示 をクリックします。

  2. チェック結果に基づいて、根本的な問題を修正します。

  3. 再度事前チェック をクリックします。

いずれかの項目でアラートが発生した場合:

  • アラートを無視できない場合は、失敗した項目の横にある 詳細の表示 をクリックし、問題をトラブルシューティングしてください。その後、再度事前チェック をクリックします。

  • アラートを無視する場合は、以下の手順に従ってください。

    1. アラート詳細の確認 をクリックします。

    2. ダイアログボックスで 無視 をクリックし、OK をクリックします。

    3. 再度事前チェック をクリックします。

警告

アラート項目を無視すると、データの不整合が発生する可能性があります。リスクを理解した上で実行してください。

ステップ 7:インスタンスの購入およびタスクの開始

  1. 成功率100% になるまで待機し、次へ:インスタンスの購入 をクリックします。

  2. インスタンスの購入 ページで、以下のパラメーターを構成します。

    パラメーター説明
    リソースグループ移行インスタンスのリソースグループです。デフォルト: デフォルトリソースグループ。「Resource Management とは
    インスタンスクラスインスタンスクラスは移行速度を決定します。要件に応じてクラスを選択してください。「データ移行インスタンスのインスタンスクラス」をご参照ください。
  3. Data Transmission Service(従量課金)サービス利用規約 を確認し、チェックボックスをオンにして同意します。

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

データ移行 ページで進行状況を確認できます。

  • スキーマ移行および完全データ移行タスクは完了時に自動的に停止します。ステータス 列に 完了 と表示されます。

  • 増分データ移行タスクは継続実行され、自動的に停止しません。ステータス 列に 実行中 と表示されます。ワークロードをターゲットに切り替える前に、タスクを手動で停止してください。

次のステップ