すべてのプロダクト
Search

このプロダクト

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

    ドキュメントセンター

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

    最終更新日:Apr 13, 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 を有効にし、Oplog が少なくとも 7 日間保持されるようにする必要があります。または、Change Streams を有効にし、DTS が過去 7 日間の移行元データベースのデータ変更を Change Streams を通じてサブスクライブできるようにする必要があります。そうでない場合、移行元からデータ変更を取得できないため、タスクが失敗する可能性があります。極端なケースでは、データの不整合やデータ損失が発生する可能性があります。これによって引き起こされる問題は、サービスレベルアグリーメント (SLA) の対象外です。

      重要

      • Oplog を使用して移行元データベースからデータ変更を取得します。

      • Change Streams を通じてデータ変更を取得できるのは、MongoDB 4.0 以降のみです。

      • 移行元データベースが Amazon DocumentDB (非エラスティッククラスター) の場合、手動で Change Streams を有効にし、移行方法 を 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 上の自己管理データベース の場合、ポート番号 にプライマリノードのポートを入力する必要があります。

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

    • 互換性を確保するために、移行元と移行先の MongoDB データベースのバージョンを同じにするか、古いバージョンから新しいバージョンに移行してください。新しいバージョンから古いバージョンに移行すると、互換性の問題が発生する可能性があります。

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

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

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

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

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

    • 移行前に、移行元と移行先のデータベースのパフォーマンスを評価してください。オフピーク時にデータを移行してください。完全データ移行中、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 データベースのシャードコレクションの要件に準拠していることを確認する必要があります。

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

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

    特殊なケース

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

    • 移行中の移行元データベースでのプライマリ/セカンダリの切り替えは、移行タスクの失敗を引き起こします。

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

    説明

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

    課金

    移行タイプ

    インスタンス設定料金

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

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

    無料。

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

    増分データ移行

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

    移行タイプ

    タイプ

    説明

    スキーマ移行

    DTS は、選択したオブジェクトのスキーマを移行元の ApsaraDB for MongoDB インスタンスから移行先の ApsaraDB for MongoDB インスタンスに移行します。

    説明

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

    完全データ移行

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

    説明

    DTS は、データベースとコレクションの完全データ移行をサポートしています。

    増分データ移行

    完全データ移行後、DTS は進行中のデータ変更を移行元の ApsaraDB for MongoDB インスタンスから移行先の ApsaraDB for MongoDB インスタンスにレプリケートします。

    Oplog の使用

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

    • CREATE COLLECTION および CREATE INDEX

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

    • RENAME COLLECTION

      説明

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

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

      説明

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

    Change Streams の使用

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

    • DROP DATABASE および DROP COLLECTION

    • RENAME COLLECTION

      説明

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

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

      説明

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

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

    データベース

    スキーマ移行

    完全データ移行

    増分データ移行

    移行元の ApsaraDB for MongoDB インスタンス

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

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

    移行先の ApsaraDB for MongoDB インスタンス

    dbAdminAnyDatabase 権限、移行先データベースに対する読み書き権限、および local データベースに対する読み取り権限。

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

    操作手順

    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: このオプションは、変更ストリームがソースデータベースで有効になっている場合に利用できます。

        説明

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

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

      [インスタンス ID]

      移行元の ApsaraDB for MongoDB インスタンスのインスタンス ID を選択します。

      [認証データベース名]

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

      データベースアカウント

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

      データベースパスワード

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

      暗号化

      移行先データベース

      既存の接続情報の選択

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

        説明

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

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

      データベースタイプ

      [MongoDB] を選択します。

      アクセス方法

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

      インスタンスリージョン

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

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

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

      アーキテクチャ

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

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

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

      インスタンス ID

      移行先の ApsaraDB for MongoDB インスタンスのインスタンス ID を選択します。

      [認証データベース名]

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

      データベースアカウント

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

      データベースパスワード

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

      暗号化

    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 インデックスを持つコレクションを同期/移行するためのベストプラクティス」をご参照ください。