すべてのプロダクト
Search

このプロダクト

    Data Transmission Service:ApsaraDB for MongoDB (レプリカセットアーキテクチャ) から ApsaraDB for MongoDB (レプリカセットまたはシャードクラスターアーキテクチャ) への移行

    ドキュメントセンター

    Data Transmission Service:ApsaraDB for MongoDB (レプリカセットアーキテクチャ) から ApsaraDB for MongoDB (レプリカセットまたはシャードクラスターアーキテクチャ) への移行

    最終更新日:Feb 05, 2026

    このトピックでは、Data Transmission Service (DTS) を使用して、レプリカセットアーキテクチャの ApsaraDB for MongoDB インスタンスから、レプリカセットまたはシャードクラスターアーキテクチャの別の ApsaraDB for MongoDB インスタンスにデータを移行する方法について説明します。

    サポートされるソースデータベースとターゲットデータベース

    ソースデータベース (レプリカセットアーキテクチャ)

    ターゲットデータベース (レプリカセットまたはシャードクラスターアーキテクチャ)

    ApsaraDB for MongoDB

    ApsaraDB for MongoDB

    ECS 上でホストされている自己管理データベース

    ECS 上でホストされている自己管理データベース

    専用回線、VPN Gateway、または Smart Access Gateway 経由で接続された自己管理データベース

    専用回線、VPN Gateway、または Smart Access Gateway 経由で接続された自己管理データベース

    パブリック IP アドレスを持つ自己管理データベース

    パブリック IP アドレスを持つ自己管理データベース

    このトピックでは、ApsaraDB for MongoDB (ReplicaSet アーキテクチャ) と ApsaraDB for MongoDB (ReplicaSet またはシャードクラスターアーキテクチャ) を例として構成プロセスを説明します。他のデータソースの構成も同様です。

    前提条件

    • ソースの ApsaraDB for MongoDB インスタンス (レプリカセットアーキテクチャ) とターゲットの ApsaraDB for MongoDB インスタンス (レプリカセットまたはシャードクラスターアーキテクチャ) を作成します。詳細については、「レプリカセットインスタンスの作成」および「シャードクラスターインスタンスの作成」をご参照ください。

      説明

      サポートされているバージョンについては、「移行ソリューションの概要」をご参照ください。

    • ターゲットの ApsaraDB for MongoDB インスタンスのストレージ容量が、ソースの ApsaraDB for MongoDB インスタンスよりも少なくとも 10% 大きいことを確認してください。

    • ターゲットの ApsaraDB for MongoDB インスタンスがシャードクラスターの場合、シャーディングするデータベースとコレクションを作成し、データシャーディングを構成し、バランサーを有効にし、必要に応じてターゲットの ApsaraDB for MongoDB インスタンスで事前シャーディングを実行する必要があります。詳細については、「シャードのパフォーマンスを最大化するためのデータシャーディングの構成」および「MongoDB シャードクラスターにおける不均一なデータ分布の処理方法」をご参照ください。

      説明

      データパーティションを構成することで、移行されたすべてのデータが単一のシャードに保存されるのを防ぎ、クラスターのパフォーマンス制限を回避できます。バランサーを有効にして事前シャーディングを実行すると、データスキューを回避するのに役立ちます。

    注意事項

    タイプ

    説明

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

    • 帯域幅の要件：ソースデータベースのサーバーには十分な出力帯域幅が必要です。帯域幅が不足すると、移行速度に影響します。

    • 移行対象のコレクションには、プライマリキーまたは一意制約が必要であり、フィールドは一意である必要があります。そうでない場合、ターゲットデータベースに重複データが存在する可能性があります。

    • コレクションレベルでオブジェクトを移行し、コレクション名のマッピングなど編集が必要な場合、1 つのデータ移行タスクで移行できるコレクションは最大 1,000 個です。この制限を超えると、タスク送信後にエラーが報告されます。この場合、コレクションを複数のデータ移行タスクに分割するか、データベース全体を移行するようにタスクを構成してください。

    • ソースデータベースから移行される単一のデータは 16 MB を超えることはできません。超えた場合、タスクは失敗します。

    • ソースデータベースが Azure Cosmos DB for MongoDB または Amazon DocumentDB (MongoDB 互換) のエラスティッククラスターである場合、完全移行のみがサポートされます。

    • 増分移行の場合：

      ソースデータベースで Oplog が有効になっている必要があり、Oplog は少なくとも 7 日間保持される必要があります。または、Change Streams を有効にし、DTS が Change Streams を通じて過去 7 日間のソースデータベースのデータ変更をサブスクライブできるようにする必要があります。そうでない場合、ソースデータベースからデータ変更を取得できないため、タスクが失敗する可能性があります。極端な場合、これによりデータ不整合やデータ損失が発生する可能性があります。これによって引き起こされる問題は、DTS のサービスレベル契約 (SLA) の対象外です。

      重要

      • Oplog を通じてソースデータベースからデータ変更を取得することを推奨します。

      • MongoDB 4.0 以降のみが Change Streams を通じてデータ変更を取得することをサポートしています。

      • ソースデータベースが Amazon DocumentDB (非エラスティッククラスター) の場合、手動で Change Streams を有効にする必要があります。タスクを構成する際、移行方法 を ChangeStream に、アーキテクチャ を シャードクラスター に設定してください。

    • ソースデータベースの操作制限：

      • スキーマ移行および完全なデータ移行中は、データベースまたはコレクションのスキーマを変更しないでください。これには、配列内のデータの更新も含まれます。スキーマの変更は、データ移行タスクの失敗や、ソースデータベースとターゲットデータベース間のデータ不整合を引き起こす可能性があります。

      • 完全なデータ移行のみを実行する場合、ソースインスタンスに新しいデータを書き込まないでください。そうしないと、ソースデータベースとターゲットデータベース間でデータ不整合が発生します。リアルタイムのデータ整合性を維持するには、スキーマ移行、完全なデータ移行、および増分データ移行を選択してください。

    • 移行対象のコレクションに Time To Live (TTL) インデックスが含まれている場合、データ不整合またはインスタンスの遅延が発生する可能性があります。

    その他の制限

    • ターゲットインスタンスがシャードクラスターインスタンスの場合：

      • 孤立ドキュメントをパージする必要があります。そうしないと、移行性能に影響します。移行中に競合する _id 値を持つドキュメントが見つかった場合、データ不整合またはタスクの失敗が発生する可能性があります。

      • タスクが開始される前に、移行したいソースデータにターゲットインスタンスの対応するシャーディングキーを追加してください。ソースインスタンスにシャーディングキーを追加できない場合は、「シャーディングキーのない MongoDB インスタンスから MongoDB シャードクラスターインスタンスへのデータ移行」をご参照ください。

      • タスクが開始された後、INSERT コマンドを使用する場合、移行対象のデータにはシャーディングキーが含まれている必要があります。UPDATE コマンドを使用する場合、シャーディングキーを変更することはできません。

    • ターゲットインスタンスが ReplicaSet インスタンスの場合：

      • アクセス方法 が Express Connect、VPN Gateway、または Smart Access Gateway、パブリック IP アドレス、または Cloud Enterprise Network (CEN) の場合、ドメイン名または IP アドレス および ポート番号 フィールドにプライマリノードのアドレスとポートを入力するか、高可用性 (HA) エンドポイントを構成する必要があります。高可用性 (HA) エンドポイントの詳細については、「高可用性 MongoDB ソースまたはターゲットデータベース用のインスタンスの作成」をご参照ください。

      • アクセス方法 が ECS 上の自己管理データベース に設定されている場合、ポート番号 にプライマリノードのポートを入力します。

    • SRV レコードを使用して MongoDB データベースに接続することはできません。

    • 互換性を確保するために、ソースとターゲットの MongoDB インスタンスのデータベースバージョンを同じにするか、古いバージョンから新しいバージョンにデータを移行することを推奨します。新しいバージョンから古いバージョンにデータを移行すると、データベースの互換性の問題が発生する可能性があります。

    • admin、config、および local データベースのデータは移行できません。

    • ターゲットコレクションに一意なインデックスがあるか、その capped プロパティが true に設定されている場合、そのコレクションは増分移行中の同時再生をサポートしません。シングルスレッドの書き込みのみをサポートします。これにより、タスクの遅延が増加する可能性があります。

    • トランザクション情報は保持されません。ソースデータベースのトランザクションは、ターゲットデータベースに移行される際に個別のレコードに変換されます。

    • DTS がターゲットコレクションにデータを書き込む際にプライマリキーまたは一意キーの競合が発生した場合、DTS は対応するデータ書き込み文をスキップし、ターゲットコレクションの既存のデータを保持します。

    • ソース MongoDB インスタンスが V3.6 より前で、ターゲット MongoDB インスタンスが V3.6 以降の場合、データベースエンジンの実行計画の違いにより、移行後にデータ内のフィールドの順序が一致しない場合があります。フィールドと値のマッピングは一貫性を保ちます。ご利用のビジネスにネストされた構造の一致検索ロジックが含まれる場合は、フィールド順序の不一致による潜在的な影響を評価してください。

    • データ移行の前に、ソースとターゲットのデータベースのパフォーマンスを評価してください。データ移行はオフピーク時に実行することを推奨します。完全なデータ移行中、DTS はソースとターゲットのデータベースの読み取りおよび書き込みリソースの一部を消費します。これにより、データベースの負荷が増加する可能性があります。

    • 完全なデータ移行には同時 INSERT 操作が含まれるため、ターゲットコレクションで断片化が発生します。完全なデータ移行が完了した後、ターゲットコレクションが使用するディスク領域は、ソースコレクションが使用するディスク領域よりも大きくなります。

    • FLOAT または DOUBLE データ型の列の移行精度がビジネス要件を満たしているか確認してください。DTS は、ROUND(COLUMN,PRECISION) を使用してこれらの列の値を読み取ります。精度が明示的に定義されていない場合、DTS は FLOAT 値を 38 桁の精度で、DOUBLE 値を 308 桁の精度で移行します。

    • DTS は、失敗した移行タスクを 7 日以内に再開しようとします。ビジネスをターゲットインスタンスに切り替える前に、タスクを終了またはリリースしてください。また、revoke コマンドを使用して、ターゲットインスタンスに対する DTS アカウントの書き込み権限を取り消すこともできます。これにより、タスクが自動的に再開された後にソースデータがターゲットインスタンスのデータを上書きするのを防ぎます。

    • DTS はデータを同時に書き込みます。これにより、ターゲットインスタンスが使用するストレージ領域は、ソースインスタンスよりも 5% から 10% 大きくなります。

    • ターゲット MongoDB インスタンスのドキュメント数をクエリするには、db.$table_name.aggregate([{ $count:"myCount"}]) 構文を使用してください。

    • ターゲット MongoDB インスタンスにソースインスタンスと同じプライマリキー (デフォルトは _id) がないことを確認してください。そうしないと、データ損失が発生する可能性があります。ターゲットインスタンスにソースインスタンスと同じプライマリキーがある場合は、ビジネスに影響を与えずにターゲットインスタンスの関連データをクリアしてください。これは、ソースインスタンスと同じ _id を持つドキュメントをターゲットインスタンスから削除することを意味します。

    • タスクが失敗した場合、DTS の技術サポートは 8 時間以内に回復を試みます。回復プロセス中に、タスクの再起動やパラメーターの調整などの操作が実行される場合があります。

      説明

      パラメーターが調整される場合、DTS タスクのパラメーターのみが変更され、データベースのパラメーターは変更されません。変更される可能性のあるパラメーターには、「インスタンスパラメーターの変更」で説明されているものが含まれますが、これらに限定されません。

    • ターゲットデータベースが MongoDB シャードクラスターインスタンスの場合、ビジネスをこのデータベースに切り替えた後、ビジネス運用がシャードコレクションの要件に準拠していることを確認してください。

    • ソースデータベースが MongoDB 5.0 以降で、ターゲットデータベースが 5.0 より前の場合、capped collection を移行することはできません。これにより、タスクが失敗したり、ソースデータベースとターゲットデータベース間でデータ不整合が発生したりする可能性があります。これは、MongoDB 5.0 で capped collection の動作が変更されたためです。明示的な削除と更新中のドキュメントサイズの増加が許可されるようになりました。以前のデータベースカーネルは、これらの新機能と互換性がありません。

    • MongoDB 5.0 以降で導入された時系列コレクションは移行できません。

    特殊なケース

    ソースデータベースが自己管理 MongoDB インスタンスの場合：

    • 移行中のプライマリ/セカンダリのスイッチオーバーは、移行タスクの失敗を引き起こします。

    • DTS の遅延は、最後に移行されたデータレコードのタイムスタンプと現在のタイムスタンプを比較して計算されます。ソースデータベースが長期間更新されていない場合、遅延情報が不正確になることがあります。タスクが長い遅延を示している場合は、ソースデータベースで更新操作を実行して遅延情報をリフレッシュできます。

    説明

    データベース全体を移行することを選択した場合、ハートビートテーブルを作成することもできます。ハートビートテーブルは毎秒更新または書き込みされます。

    課金

    移行タイプ

    インスタンス構成料金

    インターネットトラフィック料金

    スキーマ移行と完全なデータ移行

    無料です。

    ターゲットデータベースの アクセス方法 パラメーターが パブリック IP アドレス に設定されている場合、インターネットトラフィックに対して課金されます。詳細については、「課金の概要」をご参照ください。

    増分データ移行

    課金されます。詳細については、「課金の概要」をご参照ください。

    移行タイプ

    移行タイプ

    説明

    スキーマ移行

    ソースの ApsaraDB for MongoDB インスタンスからターゲットの ApsaraDB for MongoDB インスタンスにオブジェクトの構造を移行します。

    説明

    スキーマ移行でサポートされるオブジェクトには、DATABASE、COLLECTION、INDEX があります。

    完全移行

    選択したオブジェクトのすべての既存データをソースの ApsaraDB for MongoDB インスタンスからターゲットの ApsaraDB for MongoDB インスタンスに移行します。

    説明

    DATABASE および COLLECTION オブジェクトのデータの移行をサポートします。

    増分移行

    完全移行が完了した後、ソースの ApsaraDB for MongoDB インスタンスからターゲットの ApsaraDB for MongoDB インスタンスに増分更新を移行します。

    Oplog の使用

    増分移行は、タスク開始後に作成されたデータベースをサポートしません。サポートされる増分更新は次のとおりです：

    • CREATE COLLECTION, INDEX

    • DROP DATABASE, COLLECTION, INDEX

    • RENAME COLLECTION

    • コレクション内のドキュメントの挿入、更新、または削除。

      説明

      増分ドキュメントの更新では、$set コマンドを使用した操作のみがサポートされます。

    ChangeStream の使用

    サポートされる増分更新は次のとおりです：

    • DROP DATABASE, COLLECTION

    • RENAME COLLECTION

    • コレクション内のドキュメントの挿入、更新、または削除。

      説明

      増分ドキュメントの更新では、$set コマンドを使用した操作のみがサポートされます。

    データベースアカウントの権限

    データベース

    スキーマ移行

    完全移行

    増分移行

    ソース ApsaraDB for MongoDB

    移行対象のデータベースと config データベースに対する読み取り権限。

    移行対象のデータベース、admin データベース、および local データベースに対する読み取り権限。

    ターゲット ApsaraDB for MongoDB

    dbAdminAnyDatabase 権限、ターゲットデータベースに対する readWrite 権限、および local データベースに対する読み取り権限。

    ソースおよびターゲットの ApsaraDB for MongoDB インスタンスのデータベースアカウントの作成と権限付与の手順については、「DMS での MongoDB データベースユーザーの管理」をご参照ください。

    操作手順

    1. 次のいずれかの方法で、ターゲットリージョンの移行タスクリストページに移動します。

      DTS コンソールから

      1. Data Transmission Service (DTS) コンソールにログインします。

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

      3. ページ左上で、移行インスタンスが配置されているリージョンを選択します。

      DMS コンソールから

      説明

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

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

      2. トップメニューバーで、[データ + AI] > [データ伝送 (DTS)] > [データ移行] を選択します。

      3. データ移行タスク の右側で、移行インスタンスが配置されているリージョンを選択します。

    2. タスクの作成 をクリックして、タスク構成ページに移動します。

    3. ソースデータベースとターゲットデータベースを構成します。

      警告

      ソースインスタンスとターゲットインスタンスを選択した後、ページ上部に表示される制限事項をよくお読みください。そうしないと、タスクが失敗したり、データ不整合が発生したりする可能性があります。

      カテゴリ

      構成

      説明

      なし

      タスク名

      DTS は自動的にタスク名を生成します。識別しやすいように、わかりやすい名前を指定することを推奨します。名前は一意である必要はありません。

      移行元データベース

      既存の接続情報の選択

      • システムに追加された (作成または保存された) データベースインスタンスを使用するには、ドロップダウンリストから目的のデータベースインスタンスを選択します。以下のデータベース情報が自動的に構成されます。

        説明

        DMS コンソールでは、このパラメーターは DMS データベースインスタンスの選択 という名前です。

      • データベースインスタンスをシステムに登録していない場合、または登録済みのインスタンスを使用する必要がない場合は、以下のデータベース情報を手動で構成します。

      データベースタイプ

      [MongoDB] を選択します。

      アクセス方法

      [クラウドインスタンス] を選択します。

      インスタンスリージョン

      ソースの ApsaraDB for MongoDB インスタンスが存在するリージョンを選択します。

      Alibaba Cloud アカウント間でデータを複製

      この例では、現在の Alibaba Cloud アカウント下のデータベースインスタンスを使用します。× を選択します。

      アーキテクチャタイプ

      [レプリカセットアーキテクチャ] を選択します。

      • [レプリカセットアーキテクチャ]：複数のノードタイプを通じて高可用性と読み書き分離を実現します。詳細については、「レプリカセットアーキテクチャ」をご参照ください。

      • [シャードクラスターアーキテクチャ]：Mongos、Shard、ConfigServer の 3 つのコンポーネントを提供し、Mongos と Shard の数と構成を柔軟に選択できます。詳細については、「シャードクラスターアーキテクチャ」をご参照ください。

      移行方法

      状況に応じて増分データ移行方法を選択します。

      • Oplog (推奨)：

        ソースデータベースで Oplog が有効な場合に使用できます。

        説明

        Oplog は、自己管理 MongoDB および ApsaraDB for MongoDB でデフォルトで有効になっています。Oplog を使用すると、増分移行タスクの遅延が低減される (ログ検索が高速になる) ため、Oplog を選択することを推奨します。

      • ChangeStream：ソースデータベースで Change Streams (Change Streams) が有効な場合に使用できます。

        説明

        • ソースデータベースが Amazon DocumentDB (非エラスティッククラスター) の場合、ChangeStream のみを選択できます。

        • アーキテクチャ が シャードクラスター に設定されている場合、Shardアカウント と Shardパスワード を入力する必要はありません。

      [インスタンス ID]

      ソースの ApsaraDB for MongoDB インスタンスのインスタンス ID を選択します。

      [認証データベース名]

      ソースの ApsaraDB for MongoDB データベースアカウントが属するデータベースの名前を入力します。変更していない場合、デフォルト値は admin です。

      データベースアカウント

      ソースの ApsaraDB for MongoDB インスタンスのデータベースアカウントを入力します。権限要件については、「データベースアカウントの権限」をご参照ください。

      データベースパスワード

      データベースアカウントのパスワードを入力します。

      暗号化

      DTS は 非暗号化、SSL 暗号化、Mongo Atlas SSL の 3 つの接続タイプをサポートしています。暗号化 パラメーターで利用可能なオプションは、アクセス方法 および アーキテクチャ パラメーターで選択された値によって決まります。DTS コンソールに表示されるオプションが優先されます。

      説明

      • アーキテクチャ が シャードクラスター で、移行方法 が Oplog の MongoDB データベースは、SSL 暗号化 をサポートしていません。

      • ソースデータベースが レプリカセット を使用する自己管理 MongoDB データベースで、アクセス方法 が Alibaba Cloud インスタンス に設定されておらず、SSL 暗号化 を選択した場合、認証局 (CA) 証明書をアップロードしてソースデータベースへの接続を検証することもできます。

      移行先データベース

      既存の接続情報の選択

      • システムに追加された (作成または保存された) データベースインスタンスを使用するには、ドロップダウンリストから目的のデータベースインスタンスを選択します。以下のデータベース情報が自動的に構成されます。

        説明

        DMS コンソールでは、このパラメーターは DMS データベースインスタンスの選択 という名前です。

      • データベースインスタンスをシステムに登録していない場合、または登録済みのインスタンスを使用する必要がない場合は、以下のデータベース情報を手動で構成します。

      データベースタイプ

      [MongoDB] を選択します。

      アクセス方法

      [クラウドインスタンス] を選択します。

      インスタンスリージョン

      ターゲットの ApsaraDB for MongoDB インスタンスが存在するリージョンを選択します。

      Alibaba Cloud アカウント間でデータを複製

      この例では、現在の Alibaba Cloud アカウント下のデータベースインスタンスを使用します。× を選択します。

      アーキテクチャタイプ

      ビジネスニーズに基づいてアーキテクチャを選択します：

      • [レプリカセットアーキテクチャ]：複数のノードタイプを通じて高可用性と読み書き分離を実現します。詳細については、「レプリカセットアーキテクチャ」をご参照ください。

      • [シャードクラスターアーキテクチャ]：Mongos、Shard、ConfigServer の 3 つのコンポーネントを提供し、Mongos と Shard の数と構成を柔軟に選択できます。詳細については、「シャードクラスターアーキテクチャ」をご参照ください。

      [インスタンス ID]

      ターゲットの ApsaraDB for MongoDB インスタンスのインスタンス ID を選択します。

      [認証データベース名]

      ターゲットの ApsaraDB for MongoDB データベースアカウントが属するデータベースの名前を入力します。変更していない場合、デフォルト値は admin です。

      データベースアカウント

      ターゲットの ApsaraDB for MongoDB インスタンスのデータベースアカウントを入力します。権限要件については、「データベースアカウントの権限」をご参照ください。

      データベースパスワード

      データベースアカウントのパスワードを入力します。

      暗号化

      DTS は 非暗号化、SSL 暗号化、Mongo Atlas SSL の 3 つの接続タイプをサポートしています。暗号化 パラメーターで利用可能なオプションは、アクセス方法 および アーキテクチャ パラメーターで選択された値によって決まります。DTS コンソールに表示されるオプションが優先されます。

      説明

      • アーキテクチャ が シャードクラスター の MongoDB データベースは、SSL 暗号化 をサポートしていません。

      • ターゲットデータベースが レプリカセット を使用する自己管理 MongoDB データベースで、アクセス方法 が Alibaba Cloud インスタンス ではなく、SSL 暗号化 を選択した場合、DTS は CA 証明書をアップロードして接続を検証することもサポートしています。

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

      説明

      • DTS サーバーからのアクセスを許可するために、DTS サーバーの IP アドレス CIDR ブロックがソースおよびターゲットデータベースのセキュリティ設定に追加されていることを確認してください。これは自動または手動で行うことができます。詳細については、「DTS サーバーの IP アドレス CIDR ブロックをホワイトリストに追加する」をご参照ください。

      • ソースまたはターゲットデータベースが自己管理データベース (アクセス方法 が Alibaba Cloud インスタンス ではない) の場合、DTS サーバーの CIDR ブロック ダイアログボックスで 接続テスト をクリックする必要もあります。

    5. タスクオブジェクトを構成します。

      1. オブジェクト設定 ページで、移行するオブジェクトを構成します。

        構成

        説明

        移行タイプ

        • 完全移行のみを実行する必要がある場合は、スキーマ移行 と 完全データ移行 の両方を選択します。

        • ダウンタイムなしで移行を実行するには、スキーマ移行、完全データ移行、および 増分データ移行 を選択します。

        説明

        • スキーマ移行 を選択しない場合は、データを受け取るためのデータベースとテーブルがターゲットデータベースに存在することを確認する必要があります。選択中のオブジェクト ボックスのオブジェクト名マッピング機能も必要に応じて使用できます。

        • 増分データ移行 を選択しない場合は、データの一貫性を確保するために、データ移行中にソースインスタンスに新しいデータを書き込まないでください。

        タスクステップの詳細については、「移行タイプ」をご参照ください。

        競合するテーブルの処理モード

          移行先インスタンスでのオブジェクト名の大文字化

          ターゲットインスタンスのデータベース名とコレクション名の大文字/小文字ポリシーを構成できます。デフォルトでは、[DTS デフォルトポリシー] が選択されています。ソースまたはターゲットデータベースのデフォルトポリシーに合わせることも選択できます。詳細については、「ターゲットオブジェクト名の大文字/小文字変換ポリシー」をご参照ください。

          ソースオブジェクト

          「ソース オブジェクト」ボックスで、移行するオブジェクトをクリックし、右向きの小さな矢印 をクリックして、「選択済みオブジェクト」ボックスに移動します。

          説明

          DATABASE または COLLECTION の粒度で移行オブジェクトを選択できます。

          選択中のオブジェクト

          • ターゲットインスタンスでの移行オブジェクトの名前を設定したり、ターゲットインスタンスでデータを受け取るオブジェクトを指定したりするには、選択中のオブジェクト ボックスで移行オブジェクトを右クリックして変更します。詳細については、「オブジェクト名マッピング」をご参照ください。

          • 選択した移行オブジェクトを削除するには、選択中のオブジェクト ボックス内のオブジェクトをクリックし、次に image をクリックして ソースオブジェクト ボックスに移動します。

          説明

          • データベースまたはコレクションレベルで増分移行操作を選択するには、選択中のオブジェクト ボックスでオブジェクトを右クリックし、表示されるダイアログボックスで選択します。

          • フィルター条件を設定するには (完全移行中のみサポートされ、増分移行ではサポートされません)、選択中のオブジェクト ボックスでテーブルを右クリックし、表示されるダイアログボックスで条件を構成します。手順については、「フィルター条件の設定」をご参照ください。

          • オブジェクト名マッピング (データを受け取るデータベースまたはコレクションを指定) を使用する場合、このオブジェクトに依存する他のオブジェクトの移行が失敗する可能性があります。

        • 詳細設定へ をクリックして、詳細パラメーターを構成します。

          構成

          説明

          タスクのスケジュールに使用する専用クラスターの選択

          デフォルトでは、DTS は共有クラスターでタスクをスケジュールします。選択する必要はありません。より安定したタスクが必要な場合は、専用クラスターを購入して DTS 移行タスクを実行できます。

          失敗した接続の再試行時間

          移行タスクが開始された後、ソースまたはターゲットデータベースへの接続が失敗した場合、DTS はエラーを報告し、直ちに接続のリトライを開始します。デフォルトのリトライ時間は 720 分です。リトライ時間を 10 分から 1440 分の間の値にカスタマイズできます。30 分以上に設定することを推奨します。指定された時間内に DTS がソースおよびターゲットデータベースに再接続した場合、移行タスクは自動的に再開されます。そうでない場合、タスクは失敗します。

          説明

          • 同じソースまたはターゲットを共有する複数の DTS インスタンスの場合、ネットワークリトライ時間は最後に作成されたタスクの設定によって決まります。

          • 接続リトライ期間中もタスクは課金されるため、ビジネスニーズに基づいてリトライ時間をカスタマイズするか、ソースおよびターゲットデータベースインスタンスがリリースされた後できるだけ早く DTS インスタンスをリリースすることを推奨します。

          移行元データベースと移行先データベースで他の問題が発生した場合の、再試行までの待機時間です。

          移行タスクが開始された後、DDL または DML 実行例外など、接続以外の問題がソースまたはターゲットデータベースで発生した場合、DTS はエラーを報告し、直ちに操作のリトライを開始します。デフォルトのリトライ時間は 10 分です。リトライ時間を 1 分から 1440 分の間の値にカスタマイズできます。10 分以上に設定することを推奨します。指定されたリトライ時間内に関連操作が成功した場合、移行タスクは自動的に再開されます。そうでない場合、タスクは失敗します。

          重要

          移行元データベースと移行先データベースで他の問題が発生した場合の、再試行までの待機時間です。 の値は、失敗した接続の再試行時間 の値より小さくする必要があります。

          完全移行率を制限するかどうか

          完全移行中、DTS はソースおよびターゲットデータベースの読み取りおよび書き込みリソースを消費し、データベースの負荷が増加する可能性があります。必要に応じて、完全移行タスクの速度制限を有効にすることができます。1 秒あたりのソースデータベースのクエリ率 QPS、1 秒あたりの完全移行の行数 RPS、および 1 秒あたりの完全移行データ量 (MB) BPS を設定して、ターゲットデータベースの負荷を軽減できます。

          説明

          • この設定項目は、移行タイプ で 完全データ移行 を選択した場合にのみ利用可能です。

          • 移行インスタンスの実行後に 完全移行速度を調整することもできます。

          同期するデータのうち、同一テーブル内のプライマリキー_id のデータ型が一意かどうか

          移行対象のデータ内の同じコレクション内で、プライマリキー _id のデータ型が一意であるかどうかを示します。

          重要

          • 必要に応じて選択してください。そうしないと、データ損失が発生する可能性があります。

          • この構成は、移行タイプ に 完全データ移行 が含まれている場合にのみ利用可能です。

          • ○：一意。完全移行中、DTS はソースデータベースのプライマリキーのデータ型をスキャンしません。各コレクションについて、DTS は 1 つのプライマリキーデータ型に対応するデータのみを移行します。

          • ×：一意ではない。完全移行中、DTS はソースデータベースのプライマリキーのデータ型をスキャンし、すべてのデータを移行します。

          増分移行率を制限するかどうか

          必要に応じて、増分移行タスクの速度制限を設定することもできます。1 秒あたりの増分移行の行数 RPS と 1 秒あたりの増分移行データ量 (MB) BPS を設定して、ターゲットデータベースの負荷を軽減できます。

          説明

          • この設定項目は、移行タイプ で 増分データ移行 を選択した場合にのみ利用可能です。

          • 移行インスタンスの実行後に 増分移行速度を調整することもできます。

          環境タグ

          状況に応じて、インスタンスを識別するための環境ラベルを選択します。この例では選択は不要です。

          ETL 機能の設定

          ビジネスニーズに基づいて、データを処理するために ETL 機能を構成するかどうかを選択します。

          • ○：ETL 機能を構成します。テキストボックスにデータ処理文を入力する必要もあります。

          • ×：ETL 機能を構成しません。

          監視アラート

          ビジネスニーズに基づいて、アラートを設定し、アラート通知を受け取るかどうかを選択します。

          • ×：アラートを設定しません。

          • ○：アラートしきい値とアラート通知を設定してアラートを構成します。移行が失敗した場合や遅延がしきい値を超えた場合、システムはアラート通知を送信します。

        • [次へ: データ検証] をクリックして、データ検証タスクを構成します。

          データ検証機能の詳細については、「データ検証の構成」をご参照ください。

      2. タスクを保存し、事前チェックを実行します。

        • API 操作を呼び出す際にこのインスタンスを構成するためのパラメーターを表示するには、次：タスク設定の保存と事前チェック ボタンにポインターを合わせ、表示されるバブル内の OpenAPI パラメーターのプレビュー をクリックします。

        • API パラメーターを表示する必要がない場合、または表示が完了した場合は、ページ下部の 次：タスク設定の保存と事前チェック をクリックします。

        説明

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

        • 事前チェックが失敗した場合、失敗したチェック項目の横にある 詳細を表示 をクリックし、プロンプトに基づいて問題を修正してから、再度事前チェックを実行してください。

        • 事前チェック中に警告が報告された場合：

          • 無視できないチェック項目の場合、失敗した項目の横にある 詳細を表示 をクリックし、プロンプトに基づいて問題を修正してから、再度事前チェックを実行してください。

          • 無視できるチェック項目の場合、アラートの詳細を確認、無視、OK、および 再度事前チェックを実行 をクリックして、アラート項目をスキップし、再度事前チェックを実行できます。警告を無視することを選択した場合、データ不整合などの問題が発生し、ビジネスにリスクをもたらす可能性があります。

      3. インスタンスを購入します。

        1. 成功率 が 100% になったら、次：インスタンスの購入 をクリックします。

        2. 購入 ページで、データ移行インスタンスのリンク仕様を選択します。詳細については、次の表をご参照ください。

          カテゴリ

          パラメーター

          説明

          新しいインスタンスクラス

          リソースグループの設定

          インスタンスが属するリソースグループを選択します。デフォルト値はデフォルトリソースグループです。詳細については、「Resource Management とは」をご参照ください。

          インスタンスクラス

          DTS は、異なるパフォーマンスレベルの移行仕様を提供します。リンク仕様は移行速度に影響します。ビジネスシナリオに基づいて仕様を選択できます。詳細については、「データ移行リンク仕様」をご参照ください。

        3. 構成が完了したら、Data Transmission Service (従量課金) 利用規約 を読み、選択します。

        4. 購入して起動 をクリックします。表示される OK ダイアログボックスで、[OK] をクリックします。

          データ移行タスク リストページで移行タスクの進捗状況を確認できます。

          説明

          • 移行タスクに増分移行が含まれていない場合、完全移行が完了すると自動的に停止します。タスクが停止すると、その ステータス は 完了 に変わります。

          • 移行タスクに増分移行が含まれている場合、自動的に停止しません。増分移行タスクは実行を続けます。増分移行タスクが実行中である間、タスクの ステータス は 実行中 です。

      よくある質問

      • データベースにデータが書き込まれていないのに、なぜタスクの遅延やデータ不整合が発生するのですか？

        • 原因：MongoDB コレクションの TTL インデックスの自動削除メカニズムと DTS のデータ同期メカニズムの間の競合が、同期または移行タスクで遅延やデータ不整合を引き起こす可能性があります。

          • 増分書き込み中の DELETE 操作の失敗による効率低下：ソースインスタンスの TTL インデックスが期限切れのデータを削除すると、Oplog に DELETE レコードが生成されます。DTS はこの DELETE 操作を同期します。ターゲットインスタンスの TTL インデックスがすでに同じデータを削除している場合、DTS からの DELETE 操作は削除するデータを見つけられません。MongoDB エンジンは予期しない影響行数を返し、これにより例外処理プロセスがトリガーされ、移行効率が低下します。

          • 期限切れデータの非同期削除によるデータ不整合：TTL インデックスはデータをリアルタイムで削除しません。期限切れのデータがターゲットインスタンスで既に削除されているにもかかわらず、ソースインスタンスにまだ存在する可能性があります。これにより、データ不整合が発生します。

            例：

            MongoDB の Oplog または ChangeStream は、UPDATE 操作の更新されたフィールドのみを記録し、更新前後の完全なドキュメントは記録しません。したがって、UPDATE 操作がターゲットでターゲットデータを見つけられない場合、DTS はその操作を無視します。

            タイミング

            ソースインスタンス

            ターゲットインスタンス

            1

            サービスがデータを挿入

            2

            DTS が INSERT 操作を同期

            3

            データは期限切れだが、TTL インデックスによってまだ削除されていない

            4

            サービスがデータを更新 (例：TTL インデックスフィールドを更新して有効期限を変更)

            5

            TTL インデックスがデータを削除

            6

            DTS が UPDATE を同期するが、データが見つからないため操作は無視される

            結果として、このドキュメントはターゲットの MongoDB インスタンスから欠落します。

        • ソリューション：効率と一貫性を確保するために、同期または移行中にターゲットの TTL インデックスの有効期限を一時的に変更する必要があります。詳細については、「MongoDB がソースの場合に TTL インデックスを持つコレクションを同期/移行するためのベストプラクティス」をご参照ください。