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

Data Transmission Service:ApsaraDB for MongoDB インスタンスから PolarDB for MySQL クラスターへのデータ移行

最終更新日:Mar 29, 2026

Data Transmission Service (DTS) を使用して、ApsaraDB for MongoDB レプリカセットから PolarDB for MySQL クラスターへデータを移行します。DTS は完全なデータ移行および増分データ移行をサポートしています。

仕組み

MongoDB から PolarDB for MySQL への移行は、パラダイムの異なる移行です。MongoDB では柔軟な BSON ドキュメントとしてデータが格納されますが、PolarDB for MySQL では固定スキーマのリレーショナルテーブルにデータが格納されます。DTS では、bson_value() 式を用いたフィールド単位のマッピングを定義することで、この違いに対応します。

移行対象の各コレクションについて、DTS は各 MongoDB フィールドを宛先テーブルの列にマップします。例を以下に示します。

MongoDB ドキュメントのフィールドPolarDB for MySQL の列
"_id": "62cd344c85c1ea6a2a9f****"mongo_id(varchar、プライマリキー)
"person.name": "neo"person_name(varchar)
"person.age": 26person_age(decimal)

開始前に、正しいスキーマで宛先テーブルを作成してください。DTS はそのテーブルにデータを書き込みますが、テーブル構造の作成や変更は行いません。

前提条件

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

  • ソースデータの合計サイズより大きい空きストレージ容量を持つ PolarDB for MySQL クラスター。ソースデータサイズに対して少なくとも 10 % の余裕を持たせてください。詳細については、「Enterprise Edition クラスターの購入」または「サブスクリプションクラスターの購入」をご参照ください。

  • 宛先クラスター内に、単一列のプライマリキーを持つデータベースおよびテーブルを作成済みであること。複合プライマリキーはサポートされていません。

    • 任意の列名を _id または _value としないでください。そうすると、データ移行タスクが失敗します。

    • 宛先列のデータ型が、対応する MongoDB のデータ型と互換性があることを確認してください。たとえば、MongoDB の _id フィールド(ObjectId 型)は、varchar 列にマップする必要があります。完全なデータ型マッピングについては、「データ型マッピング」をご参照ください。

    • データベースの管理」をご参照ください。

  • ソース ApsaraDB for MongoDB インスタンス上のデータベースアカウントで、必要な権限に記載されている権限を付与済みであること。

  • 宛先 PolarDB for MySQL クラスター上のデータベースアカウントで、宛先データベースに対する読み取りおよび書き込み権限を付与済みであること。詳細については、「データベースアカウントの作成と管理」をご参照ください。

  • (シャードクラスターをソースとする場合のみ)すべてのシャードノードにエンドポイントが適用済みであること。すべてのシャードノードは、同一のアカウントパスワードおよびエンドポイントを共有する必要があります。「シャードまたは ConfigServer コンポーネント向けエンドポイントの申請」をご参照ください。

移行タイプ

移行タイプ説明
完全なデータ移行ソース ApsaraDB for MongoDB インスタンスから宛先 PolarDB for MySQL クラスターへ、すべての既存データを移行します。リンク構成料金は無料です。
増分データ移行完全移行完了後、ソースから宛先へ新規の変更を継続的に移行します。サポートされる操作:コレクションドキュメントに対する insert、update、delete。ただし、$set コマンドを使用して更新されたドキュメントのみ、その増分変更が移行されます。リンク構成料金が発生します。

課金の詳細については、「課金概要」をご参照ください。Alibaba Cloud からインターネットを介してデータを移行する場合は、データ転送料金が発生します。

必要な権限

データベース完全なデータ移行増分データ移行
ソース ApsaraDB for MongoDB インスタンスソースデータベースの読み取りソースデータベース、admin データベース、および local データベースでの読み取り
宛先 PolarDB for MySQL クラスター宛先データベースに対する読み取りおよび書き込み権限宛先データベースに対する読み取りおよび書き込み権限

MongoDB アカウントの管理手順については、「アカウント管理」をご参照ください。PolarDB for MySQL アカウントについては、「データベースアカウントの作成と管理」をご参照ください。

制限事項

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

制限事項詳細
アウトバウンド帯域幅ソースデータベースをホストするサーバーは、十分なアウトバウンド帯域幅を備えている必要があります。帯域幅が不足していると、移行速度が低下します。
コレクション数移行中にコレクション名を変更する場合、1 つのタスクでサポートされる最大コレクション数は 1,000 です。大規模な移行は、複数のタスクに分割してください。
完全移行のみ以下のソースタイプでは完全なデータ移行のみがサポートされており、増分移行は利用できません:スタンドアロンの ApsaraDB for MongoDB インスタンス、Azure Cosmos DB for MongoDB クラスター、Amazon DocumentDB エラスティッククラスター。
増分移行の要件増分データ移行を実行するには、以下のいずれかを満たす必要があります。(1)ソースデータベースで oplog が有効化されており、操作ログが最低 7 日間保持されている。(2)Change Stream が有効化されており、DTS が過去 7 日間に発生したデータ変更をサブスクライブできる状態である。いずれの条件も満たさない場合、DTS が操作ログを取得できず、タスクが失敗したりデータの不整合が発生したりする可能性があります。これは DTS のサービスレベルアグリーメント(SLA)の範囲外となります。可能な限り oplog 方式をご利用ください。こちらの方が増分移行のレイテンシーが低くなります。Change Stream は MongoDB V4.0 以降が必要です。
Amazon DocumentDB(非エラスティッククラスター)ChangeStream 方式のみがサポートされています。タスクを構成する際には、移行方法ChangeStreamChange Streams に、アーキテクチャSharded Cluster に設定してください。
シャードクラスター — _id の一意性各コレクション内の _id フィールドは一意である必要があります。重複する _id 値はデータの不整合を引き起こします。
シャードクラスター — Mongos ノード数ソースシャードクラスターには、10 を超える Mongos ノードを含めることはできず、孤立ドキュメントもあってはなりません。MongoDB ドキュメントおよびDTS よくある質問をご参照ください。
シャードクラスター — balancerシャードクラスターで MongoDB balancer が有効化されている場合、インスタンスに遅延が発生する可能性があります。
完全移行中の操作データベースまたはコレクションのスキーマを変更しないでください。ARRAY 型のデータを変更しないでください。完全移行のみ(増分移行なし)を実行する場合、移行中はソースデータベースへの書き込みを行わないでください。書き込みを行うと、ソースと宛先の間でデータの不整合が発生します。

その他の制限事項

制限事項詳細
移行対象オブジェクト移行対象として選択できるのはコレクションのみです。
プライマリキーの要件宛先テーブルには、単一列のユニークなプライマリキーが必要です。bson_value("_id") をそのプライマリキー列に割り当ててください。
除外されるデータベースDTS は admin および local データベースからのデータ移行は行えません。
トランザクショントランザクション情報は保持されません。トランザクションは宛先データベース内で個別のレコードに変換されます。
4 バイト文字ソースデータに稀少な文字や絵文字(4 バイト UTF-8)が含まれる場合、宛先データベースおよびテーブルは utf8mb4 文字セットを使用する必要があります。DTS スキーマ移行を利用する場合は、宛先データベースの character_set_server パラメーターを utf8mb4 に設定してください。
FLOAT および DOUBLE の精度DTS は FLOAT および DOUBLE 値を ROUND(COLUMN, PRECISION) を使用して読み取ります。精度が指定されていない場合、DTS は FLOAT に対して 38 桁、DOUBLE に対して 308 桁を使用します。移行を開始する前に、これらのデフォルト値が要件を満たすことを確認してください。
タスクの自動再開DTS は、失敗した移行タスクを 7 日以内に自動的に再開します。ビジネスワークロードを宛先インスタンスに切り替える前に、DTS タスクを終了または解放するか、revoke コマンドを使用して、DTS アカウントの宛先インスタンスに対する書き込み権限を取り消してください。そうしないと、再開されたタスクが宛先のデータを上書きする可能性があります。
増分レイテンシー表示DTS は、最新の移行済みレコードのタイムスタンプと現在のソースタイムスタンプに基づいて増分移行のレイテンシーを計算します。ソースで長期間更新が発生しない場合、表示されるレイテンシーは不正確になる可能性があります。レイテンシーの読み取りを更新するには、ソースで更新操作を実行してください。
DTS タスクの障害復旧DTS タスクが失敗した場合、DTS テクニカルサポートが 8 時間以内に復旧を試みます。復旧中、タスクが再起動し、タスクレベルのパラメーター(データベースパラメーターではない)が変更される場合があります。

移行タスクの構成

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

以下のいずれかの方法で、データ移行ページに移動します。

DTS コンソール

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

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

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

DMS コンソール

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

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

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

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

ステップ 2:タスクの作成

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

  2. 右上隅に 新規構成ページ ボタンが表示された場合は、新しい構成インターフェイスに切り替えるためにクリックします。

    戻る(以前のバージョン) が表示されている場合は、このステップをスキップしてください。

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

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

カテゴリパラメーター説明
該当なしタスク名DTS タスクの名前です。DTS が自動的に名前を生成しますが、タスクを容易に識別できるよう、意味のある名前を指定することを推奨します。名前は一意である必要はありません。
ソースデータベース既存の接続を選択既存の登録済みインスタンスを選択するか、新しいインスタンスを手動で設定します。既存のインスタンスを選択した場合、DTS がデータベースパラメーターを自動入力します。データベースを登録するには、「データベース接続の管理」をご参照ください。DMS コンソールで、[DMS データベースインスタンスの選択] ドロップダウンリストからデータベースを選択するか、[DMS データベースインスタンスの追加] をクリックします。「Alibaba Cloud データベースインスタンスの登録」および「サードパーティのクラウドサービスでホストされているデータベース、または自己管理データベースの登録」をご参照ください。
データベースタイプここでは MongoDB を選択します。
アクセス方法ここでは Alibaba Cloud インスタンス を選択します。
インスタンスリージョンソース ApsaraDB for MongoDB インスタンスが存在するリージョンです。
Alibaba Cloud アカウント間でのデータ複製ここでは いいえ(同一アカウント)を選択します。
アーキテクチャソースインスタンスのアーキテクチャです。本例では レプリカセット を選択します。ソースが シャードクラスター の場合、Oplog 方式を使用する際に シャードアカウント および シャードパスワード も指定する必要があります。
移行方法増分変更をキャプチャする方法です。Oplog(推奨):ソースで oplog が有効化されている必要があります。ChangeStream:Change Stream が有効化されている必要があります。Amazon DocumentDB 非エラスティッククラスターでは必須です。シャードクラスターのアーキテクチャで ChangeStream を使用する場合、シャードアカウント および シャードパスワード は不要です。
インスタンス IDソース ApsaraDB for MongoDB インスタンスの ID です。
認証データベースアカウント認証情報を格納するデータベースです。デフォルトは admin です。
データベースアカウントソースデータベースへの接続に使用するアカウントです。
データベースパスワードアカウントのパスワードです。
暗号化接続暗号化方式です:暗号化なしSSL 暗号化、または Mongo Atlas SSL。利用可能なオプションは、アクセス方法 および アーキテクチャ の値によって異なります。アーキテクチャシャードクラスター かつ 移行方法Oplog の場合、SSL 暗号化は利用できません。SSL 暗号化を使用する自己管理 MongoDB レプリカセットでは、CA 証明書をアップロードして接続を検証してください。
宛先データベース既存の接続を選択データベース接続の管理登録済みの既存インスタンスを選択するか、手動で新規に構成します。データベースを登録するには、「」をご参照ください。
データベースタイプここでは PolarDB for MySQL を選択します。
アクセス方法ここでは Alibaba Cloud インスタンス を選択します。
インスタンスリージョン宛先 PolarDB for MySQL クラスターが存在するリージョンです。
Alibaba Cloud アカウント間でのデータ複製ここでは いいえ(同一アカウント)を選択します。
PolarDB クラスター ID宛先 PolarDB for MySQL クラスターの ID です。
データベースアカウント宛先クラスターへの接続に使用するアカウントです。
データベースパスワードアカウントのパスワードです。
暗号化接続暗号化方式です。「SSL 暗号化の構成」をご参照ください。

構成を完了したら、ページ下部の 接続テストと続行 をクリックします。

重要

DTS サーバーの CIDR ブロックが、ソースおよびターゲットデータベースのセキュリティ設定に追加されていることを確認してください。詳細については、「DTS サーバーの CIDR ブロックをオンプレミスデータベースのセキュリティ設定に追加する」をご参照ください。ソースまたはターゲットが自己管理データベースである場合、[接続テスト][DTS サーバーの CIDR ブロック] ダイアログボックスでクリックします。

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

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

パラメーター説明
移行タイプ完全なデータ移行 を選択すると、既存データのみが移行されます。完全なデータ移行 および 増分データ移行 の両方を選択すると、移行中に宛先を同期状態に保ち、ダウンタイムを最小限に抑えることができます。完全移行のみを実行する場合、データの不整合を避けるため、移行中はソースデータベースへの書き込みを行わないでください。
競合するテーブルの処理モード事前チェックとエラー報告(推奨):DTS は開始前にコレクション名の競合をチェックします。競合が存在する場合、事前チェックは失敗し、タスクは開始できません。競合を解決するには、オブジェクト名マッピング 機能を使用して、宛先のコレクション名を変更してください。エラーを無視して続行:DTS は名前の競合チェックをスキップします。宛先で重複するプライマリキーを持つレコードは移行されません。データの不整合が発生する可能性があり、データの初期化に失敗したり、特定の列のみが移行されたり、データ移行タスクが失敗したりする場合があります。
宛先インスタンスにおけるオブジェクト名の大文字小文字の設定宛先におけるデータベース名、テーブル名、列名の大文字小文字の設定を制御します。デフォルトは DTS デフォルトポリシー宛先インスタンスにおけるオブジェクト名の大文字小文字の指定 です。「」をご参照ください。
ソースオブジェクト移行するコレクションを選択し、右向き矢印アイコンをクリックして 選択済みオブジェクト に移動します。

オブジェクトを選択した後、選択済みオブジェクト 内で以下の構成を完了します。

  1. データベース名のマッピング選択済みオブジェクト でソースデータベースを右クリックし、データベース名 を PolarDB for MySQL クラスター内のターゲットスキーマ名に変更します。OK をクリックします。

  2. コレクション(テーブル)名のマッピング:コレクションを右クリックし、テーブル名 を PolarDB for MySQL クラスター内のターゲットテーブル名に変更します。

    • (任意)データのサブセットを移行するためのフィルター条件を指定できます。「フィルター条件の指定」をご参照ください。

    • (任意)増分移行中に含める DML 操作を選択できます。

  3. フィールドマッピングの構成:DTS は各フィールドに対して bson_value() 式を自動生成します。各列の 列名長さ、および 精度 を確認・調整してください。

    • 移行する必要がないフィールドを削除するには、フィールド行の横にある削除アイコンをクリックします。

    • 自動生成された式がフィールド構造と一致しない場合(たとえば、ネストされたフィールドなど)、削除アイコンをクリックして行を削除し、+ 列の追加 をクリックして、正しい bson_value() 式を手動で入力します。「フィールドマッピングの例」を参考にしてください。

    重要

    宛先テーブルのプライマリキー列には bson_value("_id") を割り当ててください。ネストされたフィールドは、bson_value() 内で完全な階層パスを使用して指定します。たとえば、name サブフィールドは person の子要素であるため、bson_value("person","name") を使用します。bson_value("person") のみを使用すると、person オブジェクト全体が単一列にマップされ、サブフィールドの増分変更が失われるため注意してください。

  4. OK をクリックします。

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

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

パラメーター説明
タスクスケジューリング専用クラスターデフォルトでは、DTS はタスクを共有クラスターでスケジュールします。安定性を向上させるには、専用クラスターをご購入ください。「DTS 専用クラスターとは」をご参照ください。
宛先データベースのエンジンタイプの選択宛先データベースのストレージエンジンです。InnoDB(デフォルト)は標準エンジンです。X-Engine はオンライントランザクション処理(OLTP)ワークロードに最適化されています。
接続失敗時の再試行時間接続失敗後に DTS が再試行する時間です。有効範囲:10~1,440 分。デフォルト:720 分。少なくとも 30 分に設定することを推奨します。複数のタスクが同一のソースまたは宛先データベースを共有する場合、最も最近設定された値が適用されます。再試行中は、インスタンスに対して課金されます。
その他の問題発生時の再試行時間DDL または DML の失敗後の再試行時間です。有効範囲:1~1,440 分。デフォルト:10 分。少なくとも 10 分に設定してください。この値は 接続失敗時の再試行時間 より小さくなければなりません。
完全なデータ移行のスロットリング有効化完全移行中の DTS の読み取り/書き込みスループットを制限し、データベースへの負荷を軽減します。ソースデータベースへのクエリ数(QPS)完全データ移行の RPS、および 完全移行のデータ移行速度(MB/s) を構成します。完全なデータ移行 が選択されている場合のみ利用可能です。
単一テーブル内でのプライマリキー _id のデータ型は 1 種類のみ_id フィールドがコレクション内で一貫したデータ型を持つ場合。はいアラート通知設定:DTS は完全移行中にデータ型のスキャンをスキップします。いいえ:DTS は複数のデータ型をスキャンおよび処理します。完全なデータ移行 が選択されている場合のみ利用可能です。
増分データ移行のスロットリング有効化増分移行中の DTS のスループットを制限します。増分データ移行の RPS および 増分移行のデータ移行速度(MB/s) を構成します。増分データ移行 が選択されている場合のみ利用可能です。
環境タグタスク環境のオプションタグです。
ETL の構成ETL (抽出・変換・書き出し) 処理を有効にするかどうかを指定します。[はい] を選択した場合、コードエディタにデータ変換文を入力します。詳細については、「データ移行またはデータ同期タスクで ETL を設定する」をご参照ください。
モニタリングとアラートタスクの失敗またはレイテンシーしきい値に対するアラートを設定するかどうか。もし[はい]の場合、アラートのしきい値と通知設定を構成します。詳細については、「モニタリングとアラートを構成する」をご参照ください。

ステップ 6:設定の保存と事前チェックの実行

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

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

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

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

  • アラートがトリガーされた場合:問題を修正して再チェックするか、アラート詳細の確認 > 無視 > OK > 再チェック をクリックして、アラートを無視して続行できます。アラート項目を無視すると、データの不整合が発生する可能性があります。

ステップ 7:インスタンスの購入とタスクの開始

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

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

    パラメーター説明
    リソースグループ移行インスタンスのリソースグループです。デフォルト: デフォルトリソースグループ。「Resource Management とは
    インスタンスクラスインスタンスクラスは移行速度を決定します。ワークロードに基づいて選択してください。詳細については、「データ移行インスタンスのインスタンスクラス」をご参照ください。
  3. Data Transmission Service(従量課金)利用規約 を読み、同意します。

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

移行タスクは データ移行 ページに表示されます。そこから進行状況を監視できます。

移行タスクを実行する前に、ソースおよび宛先データベースのパフォーマンスを評価してください。可能であれば、ピーク時を避けた時間帯に移行を実行してください。完全データ移行中は、DTS が両データベースの読み取りおよび書き込みリソースを使用するため、負荷が増加する可能性があります。また、完全移行中の同時 INSERT 操作により、宛先でテーブルの断片化が発生する点にもご注意ください。完全移行完了後、宛先の使用領域はソースよりも大きくなる場合があります。

データ型マッピング

MongoDB のデータ型PolarDB for MySQL のデータ型
ObjectIdVARCHAR
StringVARCHAR
DocumentVARCHAR
DbPointerVARCHAR
ArrayVARCHAR
DateDATETIME
TimeStampDATETIME
DoubleDOUBLE
32-bit integer (BsonInt32)INTEGER
64-bit integer (BsonInt64)BIGINT
Decimal128DECIMAL
BooleanBOOLEAN
NullVARCHAR

フィールドマッピングの例

以下の例では、ネストされた MongoDB ドキュメントを PolarDB for MySQL テーブルにマップする方法を示します。

ソース MongoDB のデータ構造

{
  "_id": "62cd344c85c1ea6a2a9f****",
  "person": {
    "name": "neo",
    "age": 26,
    "sex": "male"
  }
}

宛先 PolarDB for MySQL のテーブルスキーマ

列名
mongo_idvarchar(プライマリキー)
person_namevarchar
person_agedecimal

新規列の構成

重要

bson_value() 式では、完全なネストパスを使用してください。bson_value("person") を使用すると、person オブジェクト全体が単一列にマップされ、person.nameperson.ageperson.sex の増分変更が失われるため注意してください。

列名値の割り当て
mongo_idSTRINGbson_value("_id")
person_nameSTRINGbson_value("person","name")
person_ageDECIMALbson_value("person","age")

次のステップ