自主管理 MongoDB シャードクラスターから ApsaraDB for MongoDB への移行 - Data Transmission Service

Data Transmission Service (DTS) を使用して、セルフマネージド MongoDB シャードクラスターから ApsaraDB for MongoDB のレプリカセットまたはシャードクラスターインスタンスへデータを移行します。DTS は、サービスを中断することなく、既存データと増分データの両方を移行します。

前提条件

開始する前に、次の点を確認してください。

移行先の ApsaraDB for MongoDB レプリカセットインスタンスまたはシャードクラスターインスタンスが作成されていること。詳細については、「レプリカセットインスタンスの作成」または「シャードクラスターインスタンスの作成」をご参照ください。
移行元のセルフマネージド MongoDB データベースのシャードにアクセスするためのデータベースアカウントが作成され、すべてのシャードで同じアカウントとパスワードが共有されていること。
(推奨) 移行先の ApsaraDB for MongoDB シャードクラスターインスタンスの利用可能なストレージ領域が、移行元データベースの総データサイズより少なくとも 10% 大きいこと。

移行先がシャードクラスターインスタンスの場合は、次の点も確認してください。

各シャードに十分なストレージ領域があること。例えば、移行元の最大のシャードが 500 GB を使用している場合、移行先のすべてのシャードに 500 GB を超えるストレージ領域が必要です。
シャーディング対象のデータベースとコレクションが作成され、データシャーディングが設定され、バランサーが有効化され、事前シャーディングが実行されます。詳細については、「シャードのパフォーマンスを最大化するためのシャーディング設定」をご参照ください。

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

課金

移行タイプ	タスク設定料金	データ転送料金
スキーマ移行と全量データ移行	無料	無料
増分データ移行	有料。「課金概要」をご参照ください。	無料

移行タイプ

移行タイプ	説明
スキーマ移行	DTS は、選択したすべてのオブジェクトのスキーマをソースから宛先インスタンスに移行します。
フルデータ移行	DTS は、選択したすべてのオブジェクトの既存データを移行します。サポート対象オブジェクト：データベース、コレクション
増分データ移行	フルデータ移行が完了すると、DTS はソースからの増分変更を継続的に移行します。サポート対象操作：データベースの削除、コレクションの作成・削除・リネーム、ドキュメントの作成・削除・更新、インデックスの作成・削除、コレクションにおけるドキュメントの挿入・更新・削除

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

データベース	スキーマ移行	完全データ移行	増分データ移行
セルフマネージド MongoDB データベース	移行対象のデータベースと config データベースの読み取り	ソースデータベースの読み取り	ソースデータベース、admin データベース、および local データベースの読み取り
ApsaraDB for MongoDB instance	dbAdminAnyDatabase 権限および local データベースに対する読み取り権限

データベースアカウントを作成して権限を付与するには：

セルフマネージド MongoDB データベース： db.createUser()
ApsaraDB for MongoDB instance： MongoDB データベースのユーザー権限の管理

説明

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

制限

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

サーバーには十分なアウトバウンド帯域幅が必要です。帯域幅が不足すると、移行速度が低下します。
移行対象のコレクションにはプライマリーキーまたは一意性制約が必要であり、その制約を構成するフィールドの組み合わせは一意でなければなりません。これを満たさない場合、宛先データベースに重複レコードが出現する可能性があります。
DTS は、フルデータ移行中にソースデータベースと宛先データベースの両方で読み取りおよび書き込みリソースを使用するため、サーバー負荷が増加します。移行はオフピーク時間に実行してください。
ソースデータベースと宛先データベースで異なる MongoDB バージョンまたはストレージエンジンを使用している場合は、まず互換性を確認してください。「MongoDB のバージョンとストレージエンジン」をご参照ください。
増分データ移行を行う場合、ソースデータベースで oplog を有効にし、少なくとも 7 日間 oplog を保持する必要があります。oplog が有効になっていない場合、事前チェック中にエラーメッセージが返され、データ移行タスクを開始できません。DTS が oplog を取得できない場合、タスクは失敗し、データ不整合またはデータ損失が発生する可能性があります。これらの保持要件は、DTS サービスレベルアグリーメント (SLA) の対象外です。
移行対象としてコレクションを選択し、宛先データベースでそれらを編集する (リネームなど) 予定がある場合、1 つのタスクは最大 1,000 個のコレクションをサポートします。1,000 個を超えるコレクションを移行する場合は、複数のタスクを設定するか、データベース全体を移行してください。
admin データベースまたは local データベースをソースまたは宛先として使用しないでください。
ソースのセルフマネージド MongoDB データベースには、10 個を超える mongos ノードを含めることはできません。
TTL インデックスを持つコレクションは移行しないでください。TTL インデックスは、移行後にソースと宛先の間でデータ不整合を引き起こす可能性があります。
ソースデータベースまたは宛先シャードクラスターインスタンスに孤立ドキュメントが存在しないことを確認してください。孤立ドキュメントは、データ不整合またはタスクの失敗を引き起こす可能性があります。「MongoDB のドキュメント」および「シャードクラスターアーキテクチャにデプロイされた MongoDB データベースの孤立ドキュメントを削除する方法」をご参照ください。

移行中は、ソースデータベースで以下のコマンドを実行しないでください。これらのコマンドはデータ分散を変更し、不整合を引き起こします。

shardCollection、reshardCollection、unshardCollection、moveCollection、movePrimary

スキーマ移行およびフルデータ移行中：

配列型の更新を含む、データベースまたはコレクションのスキーマ変更は実行しないでください。スキーマ変更は、タスクの失敗またはデータ不整合を引き起こします。
フルデータ移行のみを実行する場合 (増分データ移行なし)、ソースデータベースにデータを書き込まないでください。データ整合性を確保するには、スキーマ移行、フルデータ移行、および増分データ移行を組み合わせて選択してください。

移行中にソースデータベースのバランサーがアクティブな場合、チャンク移行によりレイテンシーが発生する可能性があります。

その他の制限

タスクを設定する前に DTS インスタンスを購入する場合は、購入時にシャード数を指定してください。
DTS は、SRV 接続文字列を使用して MongoDB データベースに接続することはできません。
移行を開始する前に、ソースデータベースのすべてのデータにシャードキーを追加してください。移行中、INSERT 操作にはシャードキーを含める必要があり、UPDATE 操作ではシャードキーを変更できません。
フルデータ移行中は、ソース MongoDB データベースのバランサーを無効にしてください。各サブタスクが増分データ移行フェーズに到達するまで、無効のままにしてください。早期に再度有効にすると、データ不整合が発生します。「ApsaraDB for MongoDB バランサーの管理」をご参照ください。
宛先データベースに、ソースと同じプライマリーキー (_id) を持つドキュメントが既に存在しないことを確認してください。重複が存在する場合は、移行を開始する前に、宛先データベース内の該当するドキュメントを削除してください。
トランザクション情報は保持されません。移行されたトランザクションは個別のレコードに変換されます。
DTS が宛先データベースに書き込む際にプライマリーキーまたは一意のインデックスの競合が発生した場合、DTS は競合する書き込みをスキップし、既存のデータを保持します。
移行タスクの実行中に ApsaraDB for MongoDB シャードクラスターインスタンスをスケーリングしないでください。スケーリングを行うと、タスクが失敗します。
宛先の ApsaraDB for MongoDB データベースでクエリのカウント結果を取得するには、db.$table_name.aggregate([{ $count:"myCount"}]) を使用してください。
DTS はデータを並行して書き込むため、宛先データベースで使用されるストレージ領域は、ソースデータベースよりも 5〜10% 大きくなります。
宛先コレクションに一意のインデックスがある場合、または capped 属性が true に設定されている場合、そのコレクションはシングルスレッド書き込みのみをサポートし、増分移行中の並行リプレイをサポートしません。これにより、移行レイテンシーが増加する可能性があります。
フルデータ移行は、両方のデータベースで読み取りおよび書き込みリソースを使用するため、サーバー負荷が増加します。移行はオフピーク時間に実行してください。
フルデータ移行中の並行 INSERT 操作は、テーブルの断片化を引き起こします。フルデータ移行後、宛先データベースのテーブルスペースは、ソースデータベースよりも大きくなります。
DTS は、失敗した移行タスクの再開を最大 7 日間試みます。ワークロードを宛先インスタンスに切り替える前に、失敗したタスクを停止または解放するか、宛先データベースに対する DTS の書き込み権限を取り消してください。そうしないと、失敗したタスクが再開されると、ソースデータが宛先データを上書きします。
DTS タスクが失敗した場合、DTS テクニカルサポートは 8 時間以内に復旧を試みます。復旧中、タスクが再起動され、タスクパラメータが変更される場合があります。

変更される可能性があるのはタスクパラメータのみで、データベースパラメータは変更されません。変更される可能性のあるパラメータは、「インスタンスパラメータの変更」セクションに記載されています。
宛先がレプリカセットインスタンスの場合：
- Express Connect、VPN Gateway、Smart Access Gateway、パブリック IP アドレス、または Cloud Enterprise Network (CEN) 経由で接続する場合： [ドメイン名または IP] と [ポート番号] をプライマリノードの IP アドレスとポートに設定するか、高可用性エンドポイントを設定してください。「ソースまたは宛先データベースが高可用性 MongoDB データベースである DTS タスクを作成する」をご参照ください。
  DTS は、各シャードノードを 1 つずつ移行することで、クラスター全体を移行します。ここに最初のシャードノードのドメイン名または IP アドレスを入力します。後で 2 番目の移行タスクを作成するときは、2 番目のシャードノードのドメイン名または IP アドレスを入力します。すべてのシャードノードが移行されるまで、このプロセスを繰り返します。
  Create a DTS task in which the source or destination database is a high-availability MongoDB database
- ECS 上の自己管理型データベース経由で接続している場合は、[ポート番号] をプライマリノードのポートに設定します
宛先がシャードクラスターインスタンスの場合、アプリケーションの動作が ApsaraDB for MongoDB シャードクラスターの要件を満たしていることを確認してください。

データの移行

事前準備

Data Transmission Service (DTS) タスクを作成する前に、次の手順を完了します。

手順1：ソースデータベースのバランサーを無効にする

セルフマネージド MongoDB データベースのバランサーを無効にして、DTS タスク中にチャンク移行がデータ不整合に影響を与えないようにします。

警告

移行中にバランサーがアクティブな場合、チャンク移行が原因で DTS が不整合なデータを読み取る可能性があります。

手順については、「ApsaraDB for MongoDB バランサーの管理」をご参照ください。

手順2：ソースデータベースから孤立ドキュメントを削除する

チャンク移行の失敗によって残された孤立ドキュメントは、移行のパフォーマンスを低下させたり、重複した _id 値を作成したり、不要なデータが移行される原因となる可能性があります。

cleanupOrphaned.js ファイルをダウンロードします：

wget "https://docs-aliyun.cn-hangzhou.oss.aliyun-inc.com/assets/attach/120562/cn_zh/1564451237979/cleanupOrphaned.js"

cleanupOrphaned.js ファイルで、 test を、孤立ドキュメントの削除対象となるデータベースの名前に置き換えます。

複数のデータベースから孤立ドキュメントを削除するには、データベースごとにこの手順と次の手順を繰り返します。

各シャードで次のコマンドを実行して、指定されたデータベース内のすべてのコレクションから孤立ドキュメントを削除します：

このコマンドをすべてのシャードで実行します。

プレースホルダー	説明
`<Shardhost>`	シャードの IP アドレス
`<Primaryport>`	シャード内のプライマリノードのサービスポート
`<database>`	アカウントが属するデータベースの名前
`<username>`	セルフマネージド MongoDB データベースへのログインに使用するアカウント
`<password>`	セルフマネージド MongoDB データベースへのログインに使用するパスワード

mongo --host <Shardhost> --port <Primaryport> --authenticationDatabase <database> -u <username> -p <password> cleanupOrphaned.js

例： 3 つのシャードを持つソースデータベースの場合：

mongo --host 172.16.1.10 --port 27018  --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js
mongo --host 172.16.1.11 --port 27021 --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js
mongo --host 172.16.1.12 --port 27024  --authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js

手順3：ターゲットインスタンスでシャーディングを設定する (シャードクラスターの場合のみ)

移行先がシャードクラスターインスタンスの場合、移行を開始する前に、シャーディング対象のデータベースとコレクションを作成してデータシャーディングを設定します。これにより、移行されたデータがシャード間で均等に分散され、単一のシャードが過負荷になるのを防ぐことができます。

詳細については、「シャードのパフォーマンスを最大化するためのシャーディングの設定」をご参照ください。

手順1：データ移行ページを開く

次のいずれかの方法を使用して [データ移行] ページを開き、移行インスタンスが存在するリージョンを選択します。

DTS コンソール

DTS コンソールにログインします。
左側メニューで、[データ移行] をクリックします。
左上隅で、データ移行インスタンスが存在するリージョンを選択します。

DMS コンソール

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

DMS コンソールにログインします。
上部メニューで、[データ + AI] > [DTS (DTS)] > [データ移行] に移動します。
[データ移行タスク] の右側にあるドロップダウンリストから、移行インスタンスが存在するリージョンを選択します。

手順2：タスクの作成

[タスクの作成] をクリックして、タスク設定ページを開きます。

手順3：ソースデータベースとターゲットデータベースの設定

警告

ソースデータベースとターゲットデータベースを設定した後、ページの上部に表示される [制限] をお読みください。この手順をスキップすると、タスクが失敗したり、データ不整合が発生したりする可能性があります。

次のパラメーターを設定します：

全般

パラメーター	説明
[タスク名]	DTS によりタスク名が自動的に生成されます。タスクを識別しやすくするために、わかりやすい名前を指定してください。一意の名前である必要はありません。

ソースデータベース

パラメーター	説明
[既存の接続を選択]	インスタンスが DTS に登録されている場合は、ドロップダウンリストから選択します。選択すると、DTS によって残りのパラメーターが自動的に入力されます。登録されていない場合は、以下のパラメーターを設定してください。DMS コンソールでは、[DMS データベースインスタンスの選択] リストから選択します。
[データベースタイプ]	[MongoDB] を選択します。
[アクセス方法]	接続方法を選択します。この例では [パブリック IP アドレス] を使用します。他の方法については、まずネットワーク環境をセットアップしてください。詳細については、「準備の概要」をご参照ください。
[インスタンスリージョン]	ソースデータベースが存在するリージョン。リージョンがリストにない場合は、地理的に最も近いリージョンを選択します。
[アーキテクチャ]	[シャードクラスター] を選択します。このオプションは、Express Connect、VPN Gateway、Smart Access Gateway、パブリック IP アドレス、または Cloud Enterprise Network (CEN) のアクセス方法でのみ表示されます。
[移行方法]	増分データを移行する方法を選択します： [Oplog] (推奨) または [変更ストリーム]。 [Oplog] は、ソースで Oplog が有効になっている場合 (セルフマネージドデータベースと ApsaraDB for MongoDB インスタンスの両方でデフォルトで有効) に使用でき、低レイテンシーの増分移行を提供します。 [変更ストリーム] は、変更ストリームが有効になっている場合に使用できます。ソースが非弾力的な Amazon DocumentDB クラスターの場合は、[変更ストリーム] のみを選択してください。 [アーキテクチャ] が [シャードクラスター] に設定されている場合、[シャードアカウント] と [シャードパスワード] パラメーターは不要です。
[エンドポイントタイプ]	セットアップに応じて [スタンドアロン] または [マルチノード] を選択します。このパラメーターは、Express Connect、VPN Gateway、Smart Access Gateway、パブリック IP アドレス、または Cloud Enterprise Network (CEN) のアクセス方法でのみ表示されます。
[Mongos ドメイン名または IP アドレス]	いずれかの mongos ノードのエンドポイントまたは IP アドレス。 [エンドポイントタイプ] が [スタンドアロン] の場合にのみ表示されます。 [ドメイン名または IP] をいずれかの mongos ノードのアドレスに、[ポート番号] をそのポートに設定します。
[ポート番号]	mongos ノードのサービスポート。 [エンドポイントタイプ] が [スタンドアロン] の場合にのみ表示されます。ポートはインターネット経由でアクセスできる必要があります。
[Mongos エンドポイント]	`<IP>:<Port>` 形式のソースデータベースのエンドポイント。 [エンドポイントタイプ] が [マルチノード] の場合にのみ表示されます。複数のエンドポイントは改行で区切ります。可能な場合は、パブリックにアクセス可能なドメイン名を使用してください。
[認証データベース]	ソースの認証データベース。デフォルト： [admin]。
[データベースアカウント]	mongos ノードにアクセスするためのアカウント。必要な権限については、「必要なデータベースアカウント権限」をご参照ください。 [アクセス方法] が [ECS 上のセルフマネージドデータベース] または [Database Gateway] の場合は、代わりにシャードアクセスアカウントを入力します。
[データベースパスワード]	データベースアカウントのパスワード。
[複数のシャードノードへのアクセス]	シャードノードのアクセス情報。ソースアーキテクチャが [シャードクラスター]、[移行方法] が [Oplog]、[エンドポイントタイプ] が [マルチノード] の場合にのみ使用できます。 [追加] をクリックし、各シャードノードのエンドポイントを `<IP>:<Port>` 形式で入力し (1 行に 1 つ)、すべてのシャードに対して繰り返します。
[シャードアクセス情報 (IP:Port)]	各シャードの IP アドレスとポートを `IP:Port` 形式で指定します。 [エンドポイントタイプ] が [スタンドアロン] の場合にのみ表示されます。複数のシャードはカンマで区切ります。
[シャードアカウント]	ソースデータベースのシャードにアクセスするためのアカウント。
[シャードパスワード]	シャードアカウントのパスワード。
[暗号化]	接続の暗号化方法： [非暗号化]、[SSL 暗号化]、または [Mongo Atlas SSL]。使用可能なオプションは、[アクセス方法] と [アーキテクチャ] の設定によって異なります。 [アーキテクチャ] が [シャードクラスター] で [移行方法] が [Oplog] の場合、ApsaraDB for MongoDB では [SSL 暗号化] は使用できません。ソースが [レプリカセット] アーキテクチャを使用し、[アクセス方法] が [Alibaba Cloud インスタンス] ではなく、[暗号化] が [SSL 暗号化] の場合は、CA 証明書をアップロードして接続を確認します。

ターゲットデータベース

パラメーター	説明
[既存の接続を選択]	インスタンスが DTS に登録されている場合は、ドロップダウンリストから選択します。それ以外の場合は、以下のパラメーターを設定します。
[データベースタイプ]	[MongoDB] を選択します。
[アクセス方法]	[Alibaba Cloud インスタンス] を選択します。
[インスタンスリージョン]	ターゲットの ApsaraDB for MongoDB インスタンスが存在するリージョン。
[Alibaba Cloud アカウント間でのデータレプリケーション]	現在のアカウント内のインスタンスを使用する場合は、[いいえ] を選択します。
[アーキテクチャ]	ターゲットインスタンスのアーキテクチャ。
[インスタンス ID]	ターゲットの ApsaraDB for MongoDB インスタンスの ID。
[認証データベース]	ターゲットの認証データベース。デフォルト： [admin]。
[データベース名]	移行されたオブジェクトを受け取るターゲットデータベースの名前。
[データベースアカウント]	ターゲットインスタンスのデータベースアカウント。必要な権限については、「必要なデータベースアカウント権限」をご参照ください。
[データベースパスワード]	ターゲットデータベースアカウントのパスワード。
[暗号化]	接続の暗号化方法。使用可能なオプションは、[アクセス方法] と [アーキテクチャ] の設定によって異なります。ターゲットが [シャードクラスター] アーキテクチャの ApsaraDB for MongoDB インスタンスの場合、[SSL 暗号化] は使用できません。

手順4：接続のテスト

[接続をテストして続行] をクリックします。

DTS サーバーの CIDR ブロックがソースデータベースとターゲットデータベースのセキュリティ設定に追加されていることを確認してください。詳細については、「DTS サーバーの CIDR ブロックの追加」をご参照ください。ソースまたはターゲットが [Alibaba Cloud インスタンス] を使用して接続されていないセルフマネージドデータベースの場合は、[DTS サーバーの CIDR ブロック] ダイアログボックスで [接続をテスト] をクリックします。

手順5：移行対象の設定

[オブジェクトの設定] ページで、次のパラメーターを設定します：

パラメーター	説明
[移行タイプ]	要件に基づいて移行タイプを選択します。フルデータ移行のみを実行するには、[スキーマ移行] と [フルデータ移行] を選択します。移行中にサービスを実行し続けるには、[スキーマ移行]、[フルデータ移行]、および [増分データ移行] を選択します。 [スキーマ移行] が選択されていない場合は、タスクを開始する前にターゲットにデータベースとコレクションを作成し、[選択したオブジェクト] でオブジェクト名のマッピングを有効にします。 [増分データ移行] が選択されていない場合は、移行中にソースにデータを書き込まないでください。
[競合するテーブルの処理モード]	[事前チェックしてエラーを報告]：ターゲットにソースと同じ名前のコレクションがあるかどうかをチェックします。重複が存在する場合、事前チェックは失敗します。ターゲットコレクションを削除または名前変更せずに名前の競合を解決するには、オブジェクト名マッピング機能を使用します。詳細については、「オブジェクト名のマッピング」をご参照ください。 [エラーを無視して続行]：重複するコレクション名の事前チェックをスキップします。フルデータ移行中に、レコードのプライマリキーがターゲットの既存レコードと同じ場合、既存のレコードが保持されます。増分データ移行中、既存のレコードは上書きされます。ソースとターゲットのスキーマが異なる場合、特定の列の移行に失敗する可能性があります。
[ターゲットインスタンスでのオブジェクト名の大文字化]	ターゲットインスタンスでのデータベース名とコレクション名の大文字と小文字を制御します。デフォルト： [DTS のデフォルトポリシー]。詳細については、「ターゲットインスタンスでのオブジェクト名の大文字と小文字の指定」をご参照ください。
[ソースオブジェクト]	1 つ以上のオブジェクト (コレクションまたはデータベース) を選択し、アイコンをクリックして [選択したオブジェクト] に追加します。
[選択したオブジェクト]	オブジェクトを右クリックして、ターゲットで名前を変更したり、別のターゲットオブジェクトにマッピングしたりします。詳細については、「オブジェクト名のマッピング」をご参照ください。オブジェクトを右クリックして、データベースとコレクションの増分移行モードを設定します。コレクションを右クリックして、フル移行の WHERE フィルタ条件を指定します。詳細については、「フィルタ条件の指定」をご参照ください。オブジェクトを削除するには、オブジェクトをクリックしてからアイコンをクリックします。オブジェクト名のマッピングが使用されている場合、マッピングされたオブジェクトに依存している他のオブジェクトの移行が失敗する可能性があります。

[次へ：高度な設定] をクリックして、以下を設定します：

パラメーター	説明
[タスクスケジューリング用の専用クラスター]	DTS はデフォルトでタスクを共有クラスターにスケジュールします。安定性を高めるには、専用クラスターを購入してください。詳細については、「DTS 専用クラスターとは」をご参照ください。
[接続失敗時の再試行時間]	タスク開始後の接続失敗の再試行期間。有効な値： 10～1,440 分。デフォルト： 720 分。 30 分以上に設定してください。 DTS がこの期間内に再接続すると、タスクは再開されます。そうでない場合、タスクは失敗します。複数のタスクが同じデータベースを共有する場合、最後に設定された再試行時間が適用されます。再試行中もインスタンスへの課金は継続されます。
[その他の問題の再試行時間]	DDL または DML 操作の失敗に対する再試行期間。有効な値： 1～1,440 分。デフォルト： 10 分。 10 分を超える値に設定してください。 [接続失敗時の再試行時間] より短くする必要があります。
[フルデータ移行のスロットリングを有効にする]	フルデータ移行中の DTS リソース使用量を制限します。 [ソースデータベースへの 1 秒あたりのクエリ数 (QPS)]、[フルデータ移行の RPS]、および [フル移行のデータ移行速度 (MB/s)] を設定します。 [フルデータ移行] が選択されている場合にのみ使用できます。
[同期するデータのテーブル内のプライマリキー _id のデータ型は 1 つだけ]	各コレクションで `_id` プライマリキーが一意のデータ型を持つかどうかを指定します。 [はい]： DTS はプライマリキーのデータ型のスキャンをスキップし、コレクションごとに単一の型を移行します。 [いいえ]： DTS はプライマリキーのすべてのデータ型をスキャンして移行します。データの実態に応じて有効にしてください。設定を誤ると、データ損失を引き起こす可能性があります。 [フルデータ移行] が選択されている場合にのみ使用できます。
[増分データ移行のスロットリングを有効にする]	増分データ移行中の DTS リソース使用量を制限します。 [増分データ移行の RPS] と [増分移行のデータ移行速度 (MB/s)] を設定します。 [増分データ移行] が選択されている場合にのみ使用できます。
[環境タグ]	DTS インスタンスを識別するためのタグ。オプション。
[ETL の設定]	抽出、変換、ロード (ETL) 機能を有効にします。 [はい] を選択して、コードエディターにデータ処理ステートメントを入力します。詳細については、「データ移行またはデータ同期タスクでの ETL の設定」をご参照ください。 [いいえ] を選択して ETL をスキップします。
[監視とアラート]	タスクのアラートを設定します。 [はい] を選択して、アラートのしきい値と通知の連絡先を設定します。詳細については、「DTS タスク作成時の監視とアラートの設定」をご参照ください。

[次のステップ：データ検証] をクリックして、データ検証を設定します。詳細については、「データ検証タスクの設定」をご参照ください。

手順6：事前チェックの実行

[次へ：タスク設定を保存して事前チェック] をクリックします。

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

DTS は移行が開始される前に事前チェックを実行します。事前チェックに合格するまでタスクは開始できません。

事前チェック項目が失敗した場合は、その横にある [詳細の表示] をクリックし、問題を解決してから、再度事前チェックを実行します。
事前チェック項目がアラートをトリガーした場合：
- アラートを無視できない場合は、[詳細の表示] をクリックし、問題を解決してから、事前チェックを再実行します。
- アラートを無視できる場合は、[アラート詳細の確認] をクリックし、ダイアログボックスで [無視] をクリックして、[OK] をクリックします。 [再度事前チェック] をクリックして続行します。アラートを無視すると、データ不整合につながる可能性があります。

手順7：インスタンスの購入

[成功率] が [100%] に達したら、[次へ：インスタンスの購入] をクリックします。

[インスタンスの購入] ページで、以下を設定します：

セクション	パラメーター	説明
[新しいインスタンスクラス]	[リソースグループ]	移行インスタンスのリソースグループ。デフォルト： [デフォルトリソースグループ]。詳細については、「リソース管理とは」をご参照ください。
[新しいインスタンスクラス]	[インスタンスクラス]	インスタンスクラスは移行速度を決定します。ニーズに応じて選択してください。詳細については、「データ移行インスタンスのインスタンスクラス」をご参照ください。

[Data Transmission Service (Pay-as-you-go) 利用規約] を読み、同意する場合は、チェックボックスをオンにします。
[購入して開始] をクリックし、確認ダイアログで [OK] をクリックします。

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

フルデータ移行のみ：タスクは自動的に停止します。ステータスには [完了] と表示されます。
増分データ移行：タスクは継続的に実行され、自動的に停止することはありません。ステータスには [実行中] と表示されます。

手順8：残りのシャードのタスクを作成する (該当する場合)

ソースの [アクセス方法] が [ECS 上のセルフマネージドデータベース] または [Database Gateway] の場合は、残りの各シャードに対して手順 1～7 を繰り返します。

手順9：移行タスクの停止

[フルデータ移行]

フルデータ移行タスクは手動で停止しないでください。移行されたデータが不完全になる可能性があります。タスクが自動的に停止するのを待ちます。

[増分データ移行]

増分データ移行は自動的に停止しません。オフピーク時間中や、ワークロードをターゲットインスタンスに切り替える前など、適切なタイミングで手動で停止します。

[実行中] のプログレスバーに [増分データ移行] が表示され、[操作情報] に [遅延なし] が表示されるまで待ちます。その後、数分間、ソースデータベースへのデータの書き込みを停止します。
[増分データ移行] のステータスが [遅延なし] に戻ったら、すべてのシャードの移行タスクを手動で停止します。

手順10：ワークロードをターゲットインスタンスに切り替える

移行が完了し、データを確認した後、ワークロードをターゲットの ApsaraDB for MongoDB インスタンスに切り替えます。