すべてのプロダクト
Search

このプロダクト

    Data Transmission Service:MongoDB レプリカセットからレプリカセットまたはシャードクラスターへの移行

    ドキュメントセンター

    Data Transmission Service:MongoDB レプリカセットからレプリカセットまたはシャードクラスターへの移行

    最終更新日:Jul 21, 2026

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

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

    ソースデータベース (レプリカセット)

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

    ApsaraDB for MongoDB

    ApsaraDB for MongoDB

    ECS インスタンス上の自己管理データベース

    ECS インスタンス上の自己管理データベース

    Express Connect、VPN Gateway、または Smart Access Gateway を使用して接続された自己管理データベース

    Express Connect、VPN Gateway、または Smart Access Gateway を使用して接続された自己管理データベース

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

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

    このトピックでは、ソースの ApsaraDB for MongoDB レプリカセットとターゲットの ApsaraDB for MongoDB インスタンス (レプリカセットまたはシャードクラスター) の設定例を示します。他のデータソースの設定プロセスも同様です。

    前提条件

    • ソースの 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 エラスティッククラスターの場合、完全なデータ移行のみがサポートされます。

    • 増分データ移行を実行するには：

      ソースデータベースでは、oplog が有効になっており、少なくとも 7 日間の保持期間が必要です。または、Change Stream が有効になっており、DTS が Change Stream を使用して過去 7 日以内のソースデータベースからのデータ変更をサブスクライブできる必要があります。これらの要件が満たされない場合、ソースからデータ変更を取得できないため、移行タスクが失敗する可能性があります。極端な場合には、データの不整合やデータ損失につながる可能性があります。これに起因する問題は、DTS サービスレベルアグリーメント (SLA) の対象外です。

      重要

      • ソースデータベースからデータ変更を取得するには、oplog を使用することを推奨します。

      • Change Stream を介したデータ変更の取得は、MongoDB 4.0 以降のバージョンでのみサポートされています。

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

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

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

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

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

    その他の制限事項

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

      • 孤立ドキュメントは移行性能に影響を与える可能性があるため、クリアする必要があります。移行中に _id が競合するドキュメントが検出された場合、データの不整合やタスクの失敗が発生する可能性があります。

      • タスクを開始する前に、ターゲットの各シャードコレクションについて、ソースデータにシャードキーを追加する必要があります。ソースデータにシャードキーを追加できない場合は、「シャードキーのない MongoDB インスタンスから MongoDB シャードクラスターインスタンスへのデータ移行」をご参照ください。

      • タスク開始後、INSERT コマンドにはシャードキーを含める必要があります。UPDATE コマンドでシャードキーを変更することはできません。

    • ターゲットインスタンスがレプリカセットアーキテクチャの場合：

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

      • アクセス方法 が ECS 上の自己管理データベース の場合、ポート番号 をプライマリノードのポートに設定する必要があります。

    • DTS は、SRV レコードを使用した MongoDB データベースへの接続をサポートしていません。

    • 互換性を確保するため、ソースデータベースとターゲットデータベースの MongoDB バージョンを一致させるか、古いバージョンから新しいバージョンに移行してください。新しいバージョンから古いバージョンへの移行は、互換性の問題を引き起こす可能性があります。

    • DTS は、admin、config、または local データベースからのデータ移行をサポートしていません。

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

    • DTS はトランザクション情報を保持しません。ソースデータベースからのトランザクションを、ターゲットデータベースの個別の文に変換します。

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

    • ソースデータベースが MongoDB 3.6 より前のバージョンで、ターゲットデータベースが MongoDB 3.6 以降の場合、移行されたデータのフィールド順序がソースと異なる場合があります。フィールドと値のペアは正しいままです。これは、データベースエンジンの実行計画の違いによるものです。アプリケーションロジックにネストされた構造のテキストマッチングが含まれる場合は、このフィールド順序の変更による潜在的な影響を評価してください。

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

    • 完全なデータ移行中、DTS は同時 INSERT 操作を実行するため、ターゲットコレクションで断片化が発生する可能性があります。その結果、ターゲットコレクションはソースインスタンスのコレクションよりも多くのストレージ容量を占有する場合があります。

    • DTS が 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 以降で、ターゲットデータベースがそれより前のバージョンの場合、Capped Collection を移行することはできません。これにより、タスクが失敗したり、データの不整合が発生したりする可能性があります。これは、MongoDB 5.0 で Capped Collection の動作が変更され、明示的な削除や更新時のドキュメントサイズの増加が許可されるようになったためです。以前のデータベースカーネルは、これらの特徴と互換性がありません。

    • MongoDB 5.0 で導入された時系列コレクションは、移行に対応していません。

    特殊なケース

    ソースデータベースが自主管理 MongoDB データベースの場合：

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

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

    説明

    データベース全体を移行する場合は、定期的に (たとえば 1 秒ごとに) 更新されるハートビートテーブルを作成することもできます。

    課金

    移行タイプ

    インスタンス設定料金

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

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

    無料。

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

    増分データ移行

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

    移行タイプ

    タイプ

    説明

    スキーマ移行

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

    説明

    スキーマ移行は、データベース、コレクション、およびインデックスでサポートされています。

    完全なデータ移行

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

    説明

    完全なデータ移行は、データベースおよびコレクション内のデータでサポートされています。

    増分データ移行

    完全移行に加えて、ソースの ApsaraDB for MongoDB からターゲットの ApsaraDB for MongoDB への増分更新を移行できます。

    Oplog

    増分移行は、タスク開始後に作成されたデータベースをサポートしません。以下の増分更新がサポートされています：

    • CREATE COLLECTION および CREATE INDEX

    • DROP DATABASE、DROP COLLECTION、および DROP INDEX

      説明

      dropTarget オプションを true に設定した RENAME COLLECTION 操作はサポートされていません。

    • RENAME COLLECTION

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

      説明

      増分ドキュメント更新では、$set コマンドを使用して行われた変更のみがレプリケートされます。

    Change Stream

    以下の増分更新がサポートされています：

    • DROP DATABASE および DROP COLLECTION

    • RENAME COLLECTION

      説明

      dropTarget オプションを true に設定した RENAME COLLECTION 操作はサポートされていません。

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

      説明

      増分ドキュメント更新では、$set コマンドを使用して行われた変更のみがレプリケートされます。

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

    データベース

    スキーマ移行

    完全なデータ移行

    増分データ移行

    ソース ApsaraDB for MongoDB インスタンス

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

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

    ターゲット ApsaraDB for MongoDB インスタンス

    dbAdminAnyDatabase、ターゲットデータベースの読み書き、およびローカルデータベースの読み取り。

    ソースおよびターゲットの ApsaraDB for MongoDB インスタンスのデータベースアカウントを作成し、権限を付与するには、「DMS を使用した MongoDB データベースユーザーの管理」をご参照ください。

    説明

    増分移行方法として ChangeStream を使用する場合、ソースデータベースアカウントにはインスタンス全体の Change Stream 読み取り権限 (例：readAnyDatabase) が必要です。ソースがカスタムアカウントを持つ ApsaraDB for MongoDB インスタンスの場合、アカウントに admin データベースに対する読み取り権限も付与する必要があります。詳細については、「インスタンス作成時に指定されたルートアカウントの権限」をご参照ください。

    操作手順

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

      DTS コンソールから

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

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

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

      DMS コンソールから

      説明

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

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

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

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

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

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

      警告

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

      カテゴリ

      パラメーター

      説明

      N/A

      タスク名

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

      移行元データベース

      既存の接続情報の選択

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

        説明

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

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

      データベースタイプ

      MongoDB を選択します。

      アクセス方法

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

      インスタンスリージョン

      ソースの ApsaraDB for MongoDB インスタンスが配置されているリージョンを選択します。

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

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

      アーキテクチャ

      レプリカセット を選択します。

      • レプリカセット：このアーキテクチャは、複数のノードを使用して高可用性を確保し、読み書き分離を可能にします。詳細については、「レプリカセットアーキテクチャ」をご参照ください。

      • シャードクラスター：このアーキテクチャは、mongos、shard、および ConfigServer コンポーネントで構成されます。mongos および shard ノードの数と設定をカスタマイズできます。詳細については、「シャードクラスターアーキテクチャ」をご参照ください。

      移行方法

      要件に基づいて、増分データ移行の方法を選択します。

      • Oplog (推奨):

        このオプションは、ソースデータベースで oplog が有効になっている場合に使用できます。

        説明

        oplog は、自主管理 MongoDB データベースと ApsaraDB for MongoDB インスタンスの両方でデフォルトで有効になっています。この方法では、ログのプルが高速なため、増分データ移行のレイテンシーが低くなります。したがって、Oplog を選択することをお勧めします。

      • ChangeStream: このオプションは、ソースデータベースで Change Streams が有効になっている場合に利用できます。

        説明

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

        • ソースデータベースの アーキテクチャ を シャードクラスター に設定した場合、Shardアカウント や Shardパスワード を入力する必要はありません。

      Instance ID

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

      認証データベース

      ソースの ApsaraDB for MongoDB インスタンスのデータベースアカウントが属するデータベースの名前を入力します。デフォルト値は admin です。

      データベースアカウント

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

      データベースパスワード

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

      暗号化

      DTS は、非暗号化、SSL 暗号化、Mongo Atlas SSL の 3 つの接続方法をサポートしています。暗号化 のオプションは、選択した アクセス方法 と アーキテクチャ によって異なります。コンソールに表示されるオプションが優先されます。

      説明

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

      • ソースが自主管理 MongoDB データベース (アクセス方法 が Alibaba Cloud インスタンス ではない) で、アーキテクチャが レプリカセット であり、かつ SSL 暗号化 を選択した場合、DTS では、CA 証明書をアップロードして接続を検証することもできます。

      移行先データベース

      既存の接続情報の選択

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

        説明

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

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

      データベースタイプ

      MongoDB を選択します。

      アクセス方法

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

      インスタンスリージョン

      ターゲットの ApsaraDB for MongoDB インスタンスが配置されているリージョンを選択します。

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

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

      アーキテクチャ

      ビジネス要件に基づいてアーキテクチャを選択します。有効な値：

      • レプリカセット：このアーキテクチャは、複数のノードを使用して高可用性を確保し、読み書き分離を可能にします。詳細については、「レプリカセットアーキテクチャ」をご参照ください。

      • シャードクラスター：このアーキテクチャは、mongos、shard、および ConfigServer コンポーネントで構成されます。mongos および shard ノードの数と設定をカスタマイズできます。詳細については、「シャードクラスターアーキテクチャ」をご参照ください。

      Instance ID

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

      認証データベース

      ターゲットの ApsaraDB for MongoDB インスタンスのデータベースアカウントが属するデータベースの名前を入力します。デフォルト値は admin です。

      データベースアカウント

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

      データベースパスワード

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

      暗号化

      DTS は、非暗号化、SSL 暗号化、Mongo Atlas SSL の 3 つの接続方法をサポートしています。暗号化 のオプションは、選択した アクセス方法 と アーキテクチャ によって異なります。コンソールに表示されるオプションが優先されます。

      説明

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

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

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

      説明

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

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

    5. タスクオブジェクトを設定します。

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

      パラメーター

      説明

      移行タイプ

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

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

      説明

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

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

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

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

      • エラーの事前チェックと報告：ターゲットデータベースに同じ名前のコレクションが存在するかどうかを確認します。同じ名前のコレクションが存在しない場合、事前チェックは合格します。同じ名前のコレクションが存在する場合、事前チェック中にエラーが報告され、データ移行タスクは開始されません。

        説明

        ターゲットデータベースのコレクションが同じ名前で、簡単に削除または名前変更できない場合は、ターゲットデータベースのコレクションの名前を変更できます。詳細については、「オブジェクト名マッピング」をご参照ください。

      • エラーを無視して続行：同じ名前のコレクションのチェックをスキップします。

        警告

        エラーを無視して続行 を選択すると、データの不整合やビジネスリスクを引き起こす可能性があります。例：

        • ターゲットデータベースのレコードがソースデータベースのレコードと同じプライマリキー値を持つ場合、ターゲットデータベースのレコードが保持されます。ソースデータベースのレコードはターゲットデータベースに移行されません。

        • データ初期化が失敗したり、一部のデータのみが移行されたり、移行が失敗したりする可能性があります。

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

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

      ソースオブジェクト

      ソースオブジェクト ボックスで、移行したいオブジェクトをクリックし、向右小箭头 をクリックして 選択中のオブジェクト ボックスに移動します。

      説明

      DATABASE または COLLECTION レベルでオブジェクトを選択できます。

      選択中のオブジェクト

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

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

      説明

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

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

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

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

        パラメーター

        説明

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

        デフォルトでは、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. [次へ：データ検証] をクリックして、データ検証タスクを設定します。

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

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

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

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

      説明

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

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

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

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

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

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

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

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

        カテゴリ

        パラメーター

        説明

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

        リソースグループの設定

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

        インスタンスクラス

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

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

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

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

        説明

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

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

    よくある質問

    アプリケーションの書き込みがないのに、タスクの遅延やデータの不整合が発生するのはなぜですか？

    • 原因: この問題は、MongoDB コレクションの TTL インデックスにおける自動削除メカニズムと DTS のデータ同期メカニズムとの競合が原因で発生します。この競合により、同期/移行タスクでタスクの遅延やデータの不整合が発生する可能性があります。

      • 冗長な DELETE が効率を低下させる：ソースの TTL インデックスが期限切れのデータを削除すると、Oplog に DELETE レコードが書き込まれます。DTS はこの DELETE をターゲットでリプレイします。ターゲットの TTL インデックスがすでに同じデータを削除している場合、MongoDB は予期しない影響行数を返し、例外処理をトリガーして移行を遅くします。

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

        例：

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

        タイミング

        ソースインスタンス

        ターゲットインスタンス

        1

        サービスがデータを挿入

        2

        DTS が INSERT 操作を同期

        3

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

        4

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

        5

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

        6

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

        その結果、このドキュメントはターゲットの MongoDB インスタンスに存在しなくなります。

    • ソリューション：これを解決するには、同期/移行タスク中にターゲットの TTL インデックスの有効期限を一時的に変更します。これにより、同期効率とデータ整合性の両方が確保されます。詳細な手順については、「MongoDB ソースから TTL インデックスを持つコレクションを同期または移行するためのベストプラクティス」をご参照ください。