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

Data Transmission Service:PolarDB for MySQL クラスターから MaxCompute プロジェクトへのデータ移行

最終更新日:Mar 29, 2026

Data Transmission Service (DTS) を使用して、PolarDB for MySQL クラスターから MaxCompute プロジェクトへデータを移行します。DTS はスキーマ移行、完全なデータ移行、および増分データ移行をサポートしており、既存データと継続的な変更の両方をカバーします。

仕組み

DTS は、PolarDB for MySQL から MaxCompute へデータを移動するための 3 段階パイプラインを使用します。

  1. スキーマ移行:DTS がソーステーブルのスキーマを読み取り、MaxCompute 内に対応するテーブルを作成します。各テーブル名には _base サフィックスが付加されます。たとえば、customer テーブルは MaxCompute 上で customer_base となります。

  2. 完全なデータ移行:DTS が各ソーステーブルのすべての既存レコードを、MaxCompute 内の対応する _base テーブルにコピーします。これらのテーブルは全量ベースラインテーブルと呼ばれ、増分同期の出発点となります。

  3. 増分データ移行:DTS が移行対象の各テーブルごとに個別の _log テーブル(例: customer_log)を作成し、ソースのバイナリログから実行中の INSERT、UPDATE、DELETE 操作をリアルタイムでストリーム処理してこれらのテーブルに書き込みます。

前提条件

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

プライマリアカウントの AccessKey ペアを使用する代わりに、RAM ユーザーを作成し、MaxCompute プロジェクトのスーパー管理者として設定します

制限事項

タスク実行を妨げる条件(開始前に修正が必要)

以下の条件が満たされていない場合、移行タスクは失敗します。

  • ソースデータベースがデプロイされているサーバーには十分なアウトバウンド帯域幅が必要です。そうでない場合、データ移行速度が低下します。

  • 移行対象のテーブルには、すべてのフィールドが一意である PRIMARY KEY または一意制約(UNIQUE constraint)が必要です。この制約がない場合、宛先に重複レコードが含まれる可能性があります。

  • テーブルを移行オブジェクトとして選択し、テーブル名またはカラム名の変更が必要な場合、1 つのタスクで最大 1,000 個のテーブルをサポートします。このモードで 1,000 個を超えるテーブルを指定すると、リクエストエラーが返されます。複数のタスクを構成するか、データベースレベルでの移行を選択してください。

  • 増分データ移行の場合、バイナリロギングを有効にする必要があり、loose_polar_log_bin パラメーターを on に設定する必要があります。バイナリロギングが有効になっていない場合、事前チェックは失敗し、タスクを開始できません。詳細については、「バイナリロギングの有効化」および「パラメーターの変更」をご参照ください。

  • スキーマ移行または完全なデータ移行中に、DDL ステートメントを使用してデータベースまたはテーブルのスキーマを変更しないでください。タスク実行中にスキーマが変更された場合、移行タスクは失敗します。

  • 移行対象のオブジェクトに対して、pt-online-schema-change などのツールによるオンライン DDL 操作を実行しないでください。移行タスクは失敗します。

PolarDB for MySQL クラスターでバイナリロギングを有効化すると、バイナリログファイルのストレージ料金が発生します。

データ整合性リスク(開始前に確認)

以下の条件により、データの不整合または損失が発生する可能性があります。

  • バイナリログは、少なくとも 3 日間は保持する必要があります。安全を期すには、7 日間保持してください。DTS がバイナリログを読み取れない場合、タスクが失敗します。例外的なケースでは、データの不整合または損失が発生する可能性があります。必要な日数よりも短い期間だけログを保持すると、DTS のサービスレベルアグリーメント (SLA) が適用されない場合があります。詳細については、「保持期間の変更」をご参照ください。

  • 完全なデータ移行のみ(スキーマ移行+完全なデータ移行、増分なし)の実行中は、ソースデータベースへの書き込みを行わないでください。このフェーズ中にソースへの書き込みを行うと、データの不整合が発生します。移行中にソースへの安全な書き込みを行うには、増分データ移行を含めてください。

  • 移行中は、他のソースから宛先 MaxCompute プロジェクトへの書き込みを行わないでください。外部からの書き込みはデータの不整合を引き起こします。

  • MaxCompute はプライマリキー制約をサポートしていません。ネットワークエラーが発生した場合、DTS が重複レコードを MaxCompute プロジェクトに書き込む可能性があります。

  • DTS は失敗したタスクを最大 7 日間再試行します。ワークロードを宛先に切り替える前に、失敗したタスクを停止またはリリースしてください。あるいは、宛先の DTS アカウントに対する書き込み権限を取り消してください。これを実施しない場合、失敗したタスクが再開された際に、ソースデータが宛先データを上書きする可能性があります。

運用上の制限

  • DTS は、ソース PolarDB for MySQL クラスターの読み取り専用ノードを移行しません。

  • DTS は、ソース PolarDB for MySQL クラスターの Object Storage Service (OSS) 外部テーブルを移行しません。

  • DTS は外部キー(foreign keys)を移行しません。外部キーに依存するカスケード操作および削除操作は宛先に複製されません。

  • トラフィックが少ない時間帯にデータを移行してください。完全なデータ移行では、ソースおよび宛先の両方で読み取りおよび書き込みリソースが使用されるため、両方のデータベースサーバーの負荷が増加します。

  • 完全なデータ移行後、宛先の表領域(tablespace)はソースより大きくなります。これは、同時 INSERT 操作によってテーブルが断片化(fragmentation)するためです。

  • DTS インスタンスが障害を起こした場合、DTS ヘルプデスクは 8 時間以内に回復を試みます。回復には、インスタンスの再起動または DTS インスタンスのパラメーターの調整(データベースのパラメーターではありません)が含まれる場合があります。変更可能なパラメーターについては、「インスタンスのパラメーターを変更する」をご参照ください。

課金

移行タイプタスク構成料金インターネットトラフィック料金
スキーマ移行と完全なデータ移行無料です。[アクセス方法][パブリック IP アドレス] に設定されている場合を除き、無料です。 詳細については、「課金概要」をご参照ください。
増分データ移行有料です。 詳細については、「課金概要」をご参照ください。

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

操作タイプSQL ステートメント
DMLINSERT、UPDATE、DELETE
DDLADD COLUMN
属性列(attribute column)を含む ADD COLUMN 操作は移行できません。

必要なデータベースアカウント権限

データベース必要な権限権限の付与方法
PolarDB for MySQL移行対象オブジェクトに対する読み取り権限データベースアカウントの作成と管理およびデータベースアカウントパスワードの管理

移行タスクの作成

ステップ 1:データ移行ページを開く

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

DTS コンソール

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

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

  3. 左上隅から、移行インスタンスを配置するリージョンを選択します。

DMS コンソール

DMS コンソールのレイアウトは、モードによって異なります。詳細については、「シンプルモード」および「DMS コンソールのレイアウトとスタイルをカスタマイズする」をご参照ください。

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

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

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

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

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

  2. 以下のパラメーターを構成します。

一般

パラメーター説明
タスク名DTS タスクの名前です。DTS がデフォルト名を生成しますが、タスクを容易に識別できるよう、意味のある名前を指定することを推奨します。タスク名は一意である必要はありません。

ソースデータベース

パラメーター説明
既存の接続を選択ソースデータベースがすでに DTS に登録されている場合は、ドロップダウンリストから選択してください。DTS が残りのフィールドを自動的に入力します。それ以外の場合は、以下のフィールドを手動で構成してください。DMS コンソールでは、DMS データベースインスタンスの選択 から選択します。
データベースタイプPolarDB for MySQL を選択します。
アクセス方法Alibaba Cloud インスタンス を選択します。
インスタンスリージョンソース PolarDB for MySQL クラスターが配置されているリージョンです。
Alibaba Cloud アカウント間でのデータ複製同一の Alibaba Cloud アカウント内で移行する場合は、いいえ を選択します。
PolarDB クラスター IDソース PolarDB for MySQL クラスターの ID です。
データベースアカウントソースクラスターのデータベースアカウントです。詳細については、「必要なデータベースアカウント権限」をご参照ください。
データベースパスワードデータベースアカウントのパスワードです。
暗号化ソースデータベースへの接続を暗号化するかどうかです。詳細については、「SSL 暗号化の構成」をご参照ください。

宛先データベース

パラメーター説明
既存の接続を選択宛先 MaxCompute プロジェクトがすでに DTS に登録されている場合は、ドロップダウンリストから選択してください。それ以外の場合は、以下のフィールドを手動で構成してください。
データベースタイプMaxCompute を選択します。
アクセス方法Alibaba Cloud インスタンス を選択します。
インスタンスリージョン宛先 MaxCompute プロジェクトが配置されているリージョンです。
プロジェクト宛先 MaxCompute プロジェクトの名前です。
Alibaba Cloud アカウントの AccessKey ID前提条件で準備した AccessKey ペアの AccessKey ID です。
Alibaba Cloud アカウントの AccessKey シークレットAccessKey ペアの AccessKey シークレットです。
  1. 接続テストと続行 をクリックします。

ソースデータベースとターゲットデータベースのセキュリティ設定に、DTS サーバーの CIDR ブロックが追加されていることを確認してください。CIDR ブロックは、DTS によって自動的に追加することも、手動で追加することもできます。詳細については、「DTS サーバーの IP アドレスをホワイトリストに追加する」をご参照ください。
  1. MaxCompute プロジェクトに対する DTS の権限付与を承認するために、OK をクリックします。その後、接続テストと続行 をクリックします。

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

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

移行タイプ

パラメーター説明
移行タイプユースケースに応じて移行タイプを選択します。・ スキーマ移行完全なデータ移行:既存データのみを移行します。タスクは自動的に完了し、停止します。・ スキーマ移行完全なデータ移行増分データ移行:既存データを移行し、継続的な変更をリアルタイムで複製します。タスクは、手動で停止するまで継続して実行されます。
スキーマ移行 をスキップする場合、タスク開始前に宛先データベースおよびテーブルを手動で作成し、選択されたオブジェクト でオブジェクト名マッピングを有効化してください。
増分データ移行 をスキップする場合、データの不整合を避けるため、移行中にソースデータベースへの書き込みを行わないでください。

テーブル構成

パラメーター説明
追加カラムの命名規則移行後、DTS は宛先テーブルに追加カラムを挿入します。追加されたカラム名が既存のカラム名と重複した場合、タスクは失敗します。ご使用の環境に応じて、新規ルール または 従来のルール を選択してください。選択前に、名称の重複がないか事前に確認してください。詳細については、「追加カラムの命名規則」をご参照ください。
増分データテーブルのパーティション定義増分データテーブルのパーティション名を選択します。詳細については、「パーティション」をご参照ください。
競合テーブルの処理モードDTS が、ソース側と同名のテーブルが宛先側に存在する場合にどのように処理するかを指定します。- 事前チェックを行い、エラーを報告:名称の重複が検出された場合、事前チェックでタスクが失敗します。宛先テーブルの名前変更を行わずに競合を解消するには、オブジェクト名マッピングを使用してください。詳細については、「オブジェクト名のマッピング」をご参照ください。- エラーを無視して続行:競合チェックをスキップします。ソースと宛先のスキーマが一致し、プライマリキーが重複している場合、完全移行では競合レコードをスキップ(宛先側のレコードを保持)、増分移行では上書きされます。スキーマが異なる場合は、特定のカラムのみを移行するか、タスクが失敗します。このモードは注意してご使用ください。
宛先インスタンスにおけるオブジェクト名の大文字小文字設定宛先側のデータベース名、テーブル名、カラム名における大文字小文字の取り扱いポリシーです。デフォルト値は DTS デフォルトポリシー宛先インスタンスでのオブジェクト名称の大文字と小文字の区別の指定 です。詳細については、「」をご参照ください。

オブジェクト選択

パラメーター説明
ソースオブジェクト移行対象のオブジェクトを選択します。移動するには、向右小箭头 アイコンをクリックして 選択されたオブジェクト に追加します。この移行パスでは、テーブルのみがサポートされるオブジェクトタイプです。
選択されたオブジェクト宛先で単一オブジェクトの名前を変更するには、選択されたオブジェクト 内で右クリックし、名前を変更します。詳細については、「単一オブジェクトの名前をマッピング」をご参照ください。複数のオブジェクトを一度に名前変更するには、一括編集 をクリックします。詳細については、「複数のオブジェクト名を一度にマッピング」をご参照ください。テーブル内の行をフィルターするには、テーブルを右クリックしてフィルター条件を構成します。詳細については、「フィルター条件の指定」をご参照ください。
説明

オブジェクト名マッピングによるオブジェクト名の変更は、依存オブジェクトの移行失敗を引き起こす可能性があります。

  1. 次へ:高度な設定 をクリックします。

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

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

複数のタスクが同じソースまたは宛先データベースを共有する場合、最も最近設定された再試行時間が適用されます。再試行中も DTS インスタンスの課金が発生します。

その他の問題発生時の再試行時間DDL または DML の失敗後の DTS の再試行時間です。有効範囲:1~1,440 分。デフォルト値:10 分。10 分を超える値を設定することを推奨します。接続失敗時の再試行時間 よりも小さい値を指定する必要があります。
完全なデータ移行のスロットリングの有効化完全なデータ移行中のソースおよび宛先への読み取りおよび書き込み負荷を制限します。ソースデータベースへのクエリ数(QPS)完全なデータ移行の RPS(1 秒あたりの行数)、および 完全なデータ移行のデータ移行速度(MB/s) を構成します。完全なデータ移行 が選択されている場合にのみ利用可能です。
増分データ移行のスロットリングの有効化増分データ移行中の負荷を制限します。増分データ移行の RPS および 増分データ移行のデータ移行速度(MB/s) を構成します。増分データ移行 が選択されている場合にのみ利用可能です。
転送および逆再生タスクのハートビートテーブルに対する SQL 操作の削除の有無DTS が実行中にソースデータベースのハートビートテーブルに SQL 操作を書き込むかどうかを制御します。はいアラート通知設定:ハートビートテーブルへの書き込みを行いません(インスタンスに遅延インジケーターが表示される場合があります)。いいえ:ハートビートテーブルに書き込みを行います(ソースの物理バックアップまたはクローン作成に影響を与える可能性があります)。
環境タグDTS インスタンスを環境(例:本番またはテスト)で識別するための任意のタグです。
ETL の構成ETL (抽出・変換・書き出し) 機能を有効にするかどうか。[はい]:コードエディタでデータ処理文を設定します。詳細については、「ETL をデータ移行またはデータ同期タスクで設定する」をご参照ください。[いいえ]:ETL の設定をスキップします。詳細については、「ETL とは?
モニタリングとアラート移行タスクにアラートを設定するかどうかを指定します。[はい]: アラートのしきい値と通知の連絡先を設定します。タスクが失敗した場合、または移行遅延がしきい値を超えた場合にアラートが発行されます。詳細については、「DTS タスクの作成時にモニタリングとアラートを設定する」をご参照ください。[いいえ]: アラート機能はスキップされます。

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

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

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

DTS は、移行タスクを開始する前に事前チェックを実行します。事前チェックが成功した場合にのみ、タスクが開始されます。

  • チェック項目が失敗した場合、隣の 詳細の表示 をクリックし、問題を修正してから 再事前チェック をクリックします。

  • チェック項目でアラートが発行され、かつその項目を安全に無視できる場合、アラートの詳細の確認 をクリックし、ダイアログボックスで 無視 をクリックしてから OK をクリックします。その後、再事前チェック をクリックします。アラートを無視すると、データの不整合が発生する可能性があります。

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

  1. 成功率100% に達したら、次へ:インスタンスの購入 をクリックします。

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

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

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

タスクは データ移行 ページに表示されます。

  • 増分移行を含まないタスクは、完全なデータ移行が完了すると自動的に停止します。ステータスは 完了 と表示されます。

  • 増分移行を含むタスクは継続して実行されます。ステータスは 実行中 と表示されます。切り替え(cut over)の準備が整ったら、手動でタスクを停止してください。

増分データテーブルの構造

増分データテーブルをクエリする前に、MaxCompute で set odps.sql.allow.fullscan=true; を実行して、プロジェクトに対する全表スキャンを許可してください。

DTS は、ソースからの増分変更を MaxCompute 内の _log テーブル(例: customer_log)に書き込みます。増分データテーブルの各行は 1 つの変更イベントを表し、ソーステーブルのデータカラムに加えて、以下のメタデータカラムを含みます。

フィールド説明
record_id増分ログエントリの固有識別子です。ID は新規エントリごとに自動インクリメントされます。UPDATE 操作の場合、DTS は事前更新値と事後更新値の 2 つのエントリを、同じ record_id で生成します。
operation_flag変更の種類です:I(INSERT)、D(DELETE)、または U(UPDATE)。
utc_timestampバイナリログから取得した、UTC 表示の操作タイムスタンプです。
before_flag行が事前更新値を含むかどうかを示します:Y または N
after_flag行が事後更新値を含むかどうかを示します:Y または N