シャードクラスタアーキテクチャを使用する自己管理型MongoDBデータベースからApsaraDB for MongoDBインスタンスへのデータの移行 - Data Transmission Service

このトピックでは、Data Transmission Service (DTS) を使用して、シャードクラスタアーキテクチャを使用する自己管理型MongoDBデータベースからApsaraDB for MongoDBレプリカセットまたはシャードクラスタインスタンスにデータを移行する方法について説明します。 DTSを使用すると、サービスを中断することなく、オンプレミスデータベースの既存および増分データをAlibaba Cloudに移行できます。

前提条件

移行先のApsaraDB for MongoDBレプリカセットまたはシャードクラスターインスタンスが作成されています。詳細については、「レプリカセットインスタンスの作成」または「シャードクラスターインスタンスの作成」をご参照ください。
重要
- 使用可能なストレージ容量がソース自己管理型MongoDBデータベースのデータの合計サイズよりも10% に大きいターゲットApsaraDB for MongoDBインスタンスを作成することを推奨します。
- サポートされているデータベースバージョンの詳細については、「データ移行シナリオの概要」をご参照ください。
ソースの自己管理型MongoDBデータベース内のシャードにアクセスするために使用されるアカウントが作成され、シャードは同じアカウントとパスワードを共有します。
ターゲットApsaraDB for MongoDBインスタンスがシャードクラスターインスタンスの場合:
- ターゲットシャードクラスターインスタンスの各シャードには、十分なストレージスペースがあります。
  説明
  たとえば、自己管理型MongoDBデータベースには3つのシャードがあり、そのうちの1つは最大500 GBのストレージ容量を占有します。この場合、ターゲットインスタンスの各シャードのストレージスペースは500 GBを超える必要があります。
- ビジネス要件に基づいて、シャーディング先ApsaraDB for MongoDBシャードクラスターインスタンスで、シャーディングするデータベースとコレクションが作成され、データシャーディングが設定されます。バランサーが有効になり、プリシャーディングが実行されます。詳細については、「シャードのパフォーマンスを最大化するようにシャーディングを構成する」および「シャードクラスターアーキテクチャにデプロイされたMongoDBデータベースのデータが均等に分散されない場合はどうすればよいですか」をご参照ください。「FAQ」トピックのセクション。
  説明
  シャードクラスターインスタンスのシャーディングを設定した後、移行されたデータは異なるシャード間で分散されます。これにより、シャードクラスターのパフォーマンスが最大になります。バランサーを有効にして事前シャーディングを実行し、データスキューを防ぐこともできます。

制限事項

カテゴリ	説明
ソースデータベースの制限	帯域幅要件: ソースデータベースが属するサーバーには、十分なアウトバウンド帯域幅が必要です。そうしないと、データ移行速度が低下します。移行するコレクションには、PRIMARY KEYまたはUNIQUE制約が必要であり、すべてのフィールドが一意である必要があります。そうでない場合、宛先データベースは重複するデータレコードを含み得る。 DTSは、完全データ移行中にソースデータベースとターゲットデータベースのリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。大量のデータを移行したり、サーバーの仕様がビジネス要件を満たしていない場合、データベースサービスが利用できなくなることがあります。データを移行する前に、移行元データベースと移行先データベースのパフォーマンスに対するデータ移行の影響を評価します。オフピーク時にデータを移行することを推奨します。ソースとターゲットのMongoDBデータベースが異なるバージョンのMongoDBを実行している場合、または異なるストレージエンジンを使用している場合は、MongoDBバージョンまたはストレージエンジンに互換性があることを確認してください。詳細については、「MongoDBのバージョンとストレージエンジン」をご参照ください。増分データを移行する場合は、操作ログを有効にする必要があります。それ以外の場合、事前チェック中にエラーメッセージが返され、データ移行タスクを開始できません。ソースデータベースの操作ログは、少なくとも7日間保持する必要があります。そうしないと、DTSは操作ログの取得に失敗し、タスクが失敗したり、データの不整合やデータの損失が発生する可能性があります。操作ログの保持期間は、上記の要件に基づいて設定してください。それ以外の場合、DTSのサービスレベル契約 (SLA) はサービスの信頼性またはパフォーマンスを保証しません。移行するオブジェクトとしてコレクションを選択し、コレクションの名前を変更するなど、移行先データベースのコレクションを編集する場合、1回のデータ移行タスクで最大1,000個のコレクションを移行できます。タスクを実行して1,000を超えるコレクションを移行すると、リクエストエラーが発生します。この場合、複数のタスクを構成してコレクションをバッチで移行するか、タスクを構成してデータベース全体を移行することをお勧めします。管理者データベースまたはローカルデータベースをソースデータベースまたはターゲットデータベースとして使用することはできません。ソースの自己管理型MongoDBデータベース内のmongosノードの数は10を超えることはできません。 TTL (time to live) インデックスを含むコレクションは移行できません。移行するデータベースにTTLインデックスが含まれている場合、ソースデータベースとターゲットデータベースのタイムゾーンとクロックの不一致により、ソースデータベースとターゲットデータベース間でデータの不一致が発生する可能性があります。ソース自己管理型MongoDBデータベースまたはターゲットApsaraDB for MongoDBシャードクラスターインスタンスに孤立したドキュメントが存在しないことを確認します。そうしないと、データの不一致やタスクの失敗が発生する可能性があります。詳細については、「MongoDBの公式ドキュメントの孤立ドキュメント」および「シャードクラスターアーキテクチャにデプロイされたMongoDBデータベースの孤立ドキュメントを削除する方法」をご参照ください。「FAQ」トピックのセクション。
その他の制限	DTSタスクを設定する前にDTSインスタンスを購入する場合、インスタンスの購入時にシャードの数を指定する必要があります。データ移行タスクを開始する前に、移行元データベースのデータにシャーディングキーを追加する必要があります。データ移行中に、INSERTステートメントを実行して移行するデータにデータを挿入する場合、移行するデータにはシャーディングキーが含まれている必要があります。 UPDATEステートメントを実行して移行するデータを変更する場合、シャーディングキーを変更することはできません。ソースMongoDBデータベースとターゲットMongoDBデータベースに同じプライマリキーがないことを確認してください。データが失われる可能性があります。デフォルトでは、_idフィールドにはドキュメントの主キーが格納されます。ソースデータベースとターゲットデータベースに同じプライマリキーがある場合は、ビジネスサービスを中断することなく、ターゲットデータベースの対応するドキュメントを削除します。トランザクション情報は保持されません。トランザクションがターゲットデータベースに移行されると、単一のレコードに変換されます。データ移行タスク中、タスクに関与するApsaraDB for MongoDBシャードクラスターインスタンスをスケーリングすることはできません。それ以外の場合、タスクは失敗します。 `db.$table_name.aggregate([{ $count:"myCount"}])` 構文を使用して、ターゲットMongoDBデータベースのcount操作の戻り値を照会する必要があります。データは、同時に宛先データベースに書き込まれる。したがって、移行先データベースで占有されるストレージスペースは、移行元データベースのデータのサイズよりも大きく10% 5% があります。ターゲットデータベースのコレクションに一意のインデックスがある場合、またはターゲットデータベースのコレクションの`capped`属性が`true`の場合、コレクションはシングルスレッドのデータ書き込みのみをサポートし、増分データ移行中の同時再生はサポートしません。これは、移行待ち時間を増加させ得る。データを移行する前に、移行元データベースと移行先データベースのパフォーマンスに対するデータ移行の影響を評価します。オフピーク時にデータを移行することを推奨します。完全データ移行中、DTSはソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。完全データ移行中、同時INSERT操作により、ターゲットデータベースのテーブルが断片化されます。完全なデータ移行が完了すると、移行先データベースのテーブルスペースは移行元データベースのテーブルスペースよりも大きくなります。 DTSは、過去7日以内に失敗したデータ移行タスクを再開しようとします。ワークロードをターゲットインスタンスに切り替える前に、失敗したタスクを停止またはリリースします。 `REVOKE`ステートメントを実行して、DTSがターゲットインスタンスにアクセスするために使用するアカウントの書き込み権限を取り消すこともできます。それ以外の場合、データ移行タスクが再開された後、ソースデータベースのデータがターゲットデータベースのデータを上書きします。

課金

移行タイプ	インスタンス設定料金	データ転送料金
スキーマ移行とフルデータ移行	無料です。	無料です。
増分データ移行	有料。詳細については、「課金の概要」をご参照ください。	無料です。

移行タイプ

移行タイプ	説明
スキーマの移行	DTSは、移行元の自己管理型MongoDBデータベースから移行先のApsaraDB for MongoDBインスタンスに移行するオブジェクトのスキーマを移行します。
フルデータ移行	DTSは、移行元の自己管理型MongoDBデータベースから移行先のApsaraDB for MongoDBインスタンスに移行するオブジェクトの既存のデータを移行します。説明 DTSは、データベースとコレクションの完全なデータ移行をサポートします。
増分データ移行	フルデータ移行が完了した後、DTSは増分データをソースのセルフマネージド型MongoDBデータベースからターゲットのApsaraDB for MongoDBインスタンスに移行します。説明 DTSは、次の操作によって生成された増分データを移行します。データベースの削除操作コレクションの作成、削除、および名前変更操作ドキュメントの作成、削除、および更新操作インデックスの作成および削除操作

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

データベース	スキーマ移行	完全なデータ移行	増分データ移行
自己管理型 MongoDB データベース	ソースデータベースの読み取り権限。	ソースデータベースの読み取り権限。	ソースデータベース、管理者データベース、およびローカルデータベースに対する読み取り権限。
ApsaraDB for MongoDBインスタンス	dbAdminAnyDatabaseアクセス許可、ターゲットデータベースの読み取りおよび書き込みアクセス許可、およびローカルデータベースの読み取りアクセス許可。

データベースアカウントを作成し、データベースアカウントに権限を付与する方法については、次のトピックを参照してください。

自己管理型MongoDBデータベース: db.createUser()
ApsaraDB for MongoDBインスタンス: MongoDBデータベースのユーザー権限の管理

準備

必須: 自己管理型MongoDBデータベースのbalancerを無効にします。これにより、チャンクの移行がデータの一貫性に与える影響を防ぎます。詳細については、「ApsaraDB For MongoDBバランサーの管理」をご参照ください。
警告
balancerが無効になっていない場合、チャンクの移行はDTSによって読み取られるデータの一貫性に影響します。
チャンク移行の失敗により生成された孤立したドキュメントを、自己管理型MongoDBデータベースから削除します。
説明
孤立したドキュメントを削除しないと、移行のパフォーマンスが低下します。また、_idの値が重複しているドキュメントがあり、移行しないデータが移行される場合があります。
1. cleanupOrphaned.jsファイルをダウンロードします。
```
wget " https://docs-aliyun.cn-hangzhou.oss.aliyun-inc.com/assets/attach/120562/cn_zh/1564451237979/cleanupOrphaned.js "
```
2. cleanupOrphaned.jsファイルのtestを、孤立したドキュメントを削除するデータベースの名前に置き換えます。
  説明
  複数のデータベースから孤立したドキュメントを削除する場合は、手順2のサブステップbとサブステップcを繰り返します。
3. シャードで次のコマンドを実行して、指定したデータベース内のすべてのコレクションから孤立したドキュメントを削除します。
  説明
  各シャードでこの手順を繰り返す必要があります。
```
mongo -- host <Shardhost> -- port <Primaryport> -- authenticationDatabase <database> -u <username> -p <password> cleanupOrphaned.js
```
  説明
  - <Shardhost>: シャードのIPアドレス。
  - <Primaryport>: シャード内のプライマリノードのサービスポート。
  - <database>: データベースアカウントが属するデータベースの名前。
  - <username>: 自己管理型MongoDBデータベースへのログインに使用されるアカウント。
  - <password>: 自己管理型MongoDBデータベースへのログインに使用されるパスワード。
  例：
  この例では、自己管理型MongoDBデータベースに3つのシャードがあり、各シャードの孤立したドキュメントを削除する必要があります。
```
mongo -- host 172.16.1.10 -- ポート27018 -- authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js
```
```
mongo -- host 172.16.1.11 -- ポート27021 -- authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js
```
```
mongo -- host 172.16.1.12 -- ポート27024 -- authenticationDatabase admin -u dtstest -p 'Test123456' cleanupOrphaned.js
```
ターゲットApsaraDB for MongoDBインスタンスでシャードするデータベースとコレクションを作成し、ビジネス要件に基づいてデータシャードを設定します。詳細は、シャードのパフォーマンスを最大化するためのシャーディングの構成をご参照ください。
説明
データ移行を開始する前にデータシャーディングを設定した場合、自己管理型MongoDBデータベース内のデータは、ターゲットシャードクラスターインスタンス内のシャードに均等に移行されます。これにより、単一のシャードの過負荷が防止されます。

手順

[データ移行タスク] ページに移動します。
1. データ管理 (DMS) コンソールにログインします。
2. 上部のナビゲーションバーで、[DTS] をクリックします。
3. 左側のナビゲーションウィンドウで、[DTS (DTS)] > [データ移行] を選択します。
説明
- 操作は、DMSコンソールのモードとレイアウトによって異なります。詳細については、「シンプルモード」および「DMSコンソールのレイアウトとスタイルのカスタマイズ」をご参照ください。
- に行くこともできます新しいDTSコンソールのデータ移行タスクページ。
[データ移行タスク] の横にあるドロップダウンリストから、データ移行インスタンスが存在するリージョンを選択します。
説明
新しいDTSコンソールを使用する場合は、左上隅にデータ移行インスタンスが存在するリージョンを選択する必要があります。

[タスクの作成] をクリックします。タスクの作成ウィザードで、ソースデータベースとターゲットデータベースを設定します。下表にパラメーターを示します。

警告

ソースデータベースとターゲットデータベースを設定した後、ページの上部に表示される制限を読むことを推奨します。そうしないと、タスクが失敗したり、データの不一致が発生します。

セクション	パラメーター	説明
N/A	タスク名	タスクの名前。 DTSはタスクに名前を自動的に割り当てます。タスクを簡単に識別できるように、わかりやすい名前を指定することをお勧めします。一意のタスク名を指定する必要はありません。
移行元データベース	既存の DMS データベースインスタンスを選択します。(任意です。DMS データベースインスタンスが未登録の場合は、このオプションを無視して、以下のセクションでデータベース設定を行ってください。)	使用するデータベースインスタンス。ビジネス要件に基づいて、既存のインスタンスを使用するかどうかを選択できます。既存のインスタンスを選択すると、DTSはデータベースのパラメーターを自動的に入力します。既存のインスタンスを選択しない場合は、ソースデータベースのパラメーターを設定する必要があります。
	データベースタイプ	移行元ディスクのタイプを設定します。 MongoDB を選択します。
	アクセス方法	ソースデータベースのアクセス方法。この例では、パブリック IP アドレスが選択されています。説明ソースの自己管理型MongoDBデータベースにアクセスする別の方法を選択した場合は、データベースのネットワーク環境をデプロイする必要があります。詳細については、「準備の概要」をご参照ください。
	インスタンスのリージョン	ソースの自己管理型MongoDBデータベースが存在するリージョン。説明自己管理型MongoDBデータベースが存在するリージョンがドロップダウンリストに表示されていない場合は、自己管理型MongoDBデータベースに地理的に最も近いリージョンを選択します。
	アーキテクチャ	ソースデータベースがデプロイされるアーキテクチャ。シャードクラスターを選択します。説明このパラメーターは、アクセス方法パラメーターをExpress Connect、VPN Gateway、または Smart Access Gateway、パブリック IP アドレス、またはCloud Enterprise Network (CEN) に設定した場合にのみ表示されます。
	ドメイン名または IP アドレス	自己管理型MongoDBデータベース内のmongosノードのエンドポイントまたはIPアドレス。この例では、mongosノードのパブリックIPアドレスが使用されます。説明ドメイン名または IP アドレスおよびポート番号パラメーターを、ソースデータベースの任意のmongosノードのエンドポイントまたはIPアドレスおよびポート番号に設定します。
	ポート番号	自己管理型MongoDBデータベースのサービスポート番号。説明 mongosノードのサービスポートは、インターネット経由でアクセスできる必要があります。
	認証データベース	ソースの自己管理型MongoDBデータベースのデータベースアカウントとパスワードを格納する認証データベースの名前。以前に認証データベースの名前を変更しなかった場合、デフォルト値はadminです。
	データベースアカウント	自己管理型MongoDBデータベース内のmongosノードにアクセスするために使用されるアカウント。アカウントに必要な権限の詳細については、このトピックの「データベースアカウントに必要な権限」をご参照ください。説明アクセス方法パラメーターをECS 上の自己管理データベースまたはデータベースゲートウェイに設定した場合、self-managed MongoDBデータベースのシャードへのアクセスに使用するアカウントを入力します。
	データベースのパスワード	データベースアカウントのパスワードを設定します。
	シャードのアクセス情報	シャードのIPアドレスとポート番号など、自己管理型MongoDBデータベース内のシャードに関するアクセス情報。形式は`IPアドレス: ポート番号`です。説明複数のシャードのアクセス情報をコンマ (,) で区切ります。
	シャードアカウント	ソースの自己管理型MongoDBデータベース内のシャードにアクセスするために使用されるアカウント。
	シャードパスワード	ソースの自己管理型MongoDBデータベース内のシャードにアクセスするために使用されるパスワード。
移行先データベース	既存の DMS データベースインスタンスを選択します。(任意です。DMS データベースインスタンスが未登録の場合は、このオプションを無視して、以下のセクションでデータベース設定を行ってください。)	使用するデータベースインスタンス。ビジネス要件に基づいて、既存のインスタンスを使用するかどうかを選択できます。既存のインスタンスを選択すると、DTSはデータベースのパラメーターを自動的に入力します。既存のインスタンスを選択しない場合は、ソースデータベースのパラメーターを設定する必要があります。
	データベースタイプ	ターゲットデータベースのタイプ。 MongoDB を選択します。
	アクセス方法	ターゲットデータベースのアクセス方法。 Alibaba Cloud インスタンスを選択します。
	インスタンスのリージョン	ターゲットApsaraDB for MongoDBインスタンスが存在するリージョン。
	アーキテクチャ	ターゲットApsaraDB for MongoDBインスタンスがデプロイされているアーキテクチャ。
	インスタンス ID	移行先のApsaraDB for MongoDBインスタンスのID。
	認証データベース	ターゲットApsaraDB for MongoDBインスタンスのデータベースアカウントとパスワードを格納する認証データベースの名前。以前に認証データベースの名前を変更しなかった場合、デフォルト値はadminです。
	データベース名	移行先ApsaraDB for MongoDBインスタンスの移行済みオブジェクトが属するデータベースの名前。
	データベースアカウント	移行先ApsaraDB for MongoDBインスタンスのデータベースアカウント。アカウントに必要な権限の詳細については、このトピックの「データベースアカウントに必要な権限」をご参照ください。
	データベースのパスワード	データベースアカウントのパスワードを設定します。

ページの下部で、接続をテストして続行 をクリックします。
自己管理データベースにIPアドレスホワイトリストが設定されている場合は、DTSサーバーのCIDRブロックをIPアドレスホワイトリストに追加します。次に、[テスト接続と続行] をクリックします。
警告
DTSサーバーのパブリックCIDRブロックがデータベースインスタンスのホワイトリストまたはECSインスタンスのセキュリティグループルールに自動的または手動で追加されると、セキュリティリスクが発生する可能性があります。したがって、DTSを使用してデータを移行する前に、潜在的なリスクを理解して認識し、ユーザー名とパスワードのセキュリティの強化、公開されるポートの制限、API呼び出しの認証、ホワイトリストまたはセキュリティグループルールの定期的なチェック、CIDRブロックの禁止、またはExpress Connectを使用したデータベースインスタンスのDTSへの接続、VPNゲートウェイ、またはSmart Access Gateway。

移行するオブジェクトと詳細設定を設定します。

パラメーター	説明
移行タイプ	フルデータ移行のみを実行するには、[スキーマ移行] と [フルデータ移行] を選択します。データ移行中のサービスの継続性を確保するには、[スキーマ移行] 、[フルデータ移行] 、および [増分データ移行] を選択します。説明増分データ移行を選択しない場合、データ移行中にソースデータベースにデータを書き込まないことを推奨します。これにより、ソースデータベースとターゲットデータベース間のデータの整合性が確保されます。
競合するテーブルの処理モード	エラーの事前チェックと報告: ターゲットデータベースに、ソースデータベースのテーブルと同じ名前を使用するテーブルが含まれているかどうかを確認します。ソースデータベースとターゲットデータベースに同じテーブル名のテーブルが含まれていない場合は、事前チェックに合格します。それ以外の場合、事前チェック中にエラーが返され、データ移行タスクを開始できません。説明ソースデータベースとターゲットデータベースに同じ名前のテーブルが含まれていて、ターゲットデータベース内のテーブルを削除または名前変更できない場合は、オブジェクト名マッピング機能を使用して、ターゲットデータベースに移行されるテーブルの名前を変更できます。詳細については、「マップオブジェクト名」をご参照ください。エラーを無視して続行: ソースデータベースとターゲットデータベースの同じテーブル名の事前チェックをスキップします。警告エラーを無視して続行を選択すると、データの不整合が発生し、ビジネスが次の潜在的なリスクにさらされる可能性があります。ソースデータベースとターゲットデータベースのスキーマが同じである場合、DTSは、ターゲットデータベースのデータレコードと同じ主キーを持つデータレコードを移行しません。ソースデータベースとターゲットデータベースのスキーマが異なる場合、特定の列のみが移行されるか、データ移行タスクが失敗します。作業は慎重に行ってください。
移行先インスタンスでのオブジェクト名の大文字化	ターゲットインスタンスのデータベース名とコレクション名の大文字化。デフォルトでは、DTSデフォルトポリシーが選択されています。他のオプションを選択して、オブジェクト名の大文字化がソースまたはターゲットデータベースの大文字化と一致していることを確認できます。詳細については、「ターゲットインスタンスのオブジェクト名の大文字化の指定」をご参照ください。
ソースオブジェクト	ソースオブジェクトセクションから1つ以上のオブジェクトを選択し、アイコンをクリックして選択中のオブジェクトセクションにオブジェクトを追加します。説明移行するオブジェクトとして、コレクションまたはデータベースを選択できます。
選択中のオブジェクト	移行先インスタンスに移行するオブジェクトの名前を変更するには、[選択済みオブジェクト] セクションでオブジェクトを右クリックします。詳細については、「単一オブジェクトの名前のマッピング」をご参照ください。一度に複数のオブジェクトの名前を変更するには、[選択済みオブジェクト] セクションの右上隅にある [一括編集] をクリックします。詳細については、「一度に複数のオブジェクト名をマップする」をご参照ください。説明オブジェクト名マッピング機能を使用してオブジェクトの名前を変更すると、そのオブジェクトに依存する他のオブジェクトの移行に失敗する可能性があります。 ApsaraDB for MongoDBインスタンスでサポートされているフィルターステートメントは、標準のSQL WHEREステートメントとは異なります。データをフィルタリングするWHERE条件を指定するには、[選択済みオブジェクト] セクションでオブジェクトを右クリックします。表示されるダイアログボックスで、条件を指定します。詳細については、「フィルター条件の設定」をご参照ください。

クリック次へ：詳細設定詳細設定を設定します。

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

詳細設定

パラメーター	説明
タスクのスケジュールに使用する専用クラスターの選択	デフォルトでは、DTSはタスクを共有クラスターにスケジュールします。このパラメーターを設定する必要はありません。データ移行タスクを実行するために必要な仕様の専用クラスターを購入して指定することもできます。詳細については、「DTS専用クラスターの概要」をご参照ください。
失敗した接続の再試行時間	失敗した接続のリトライ時間範囲。データ移行タスクの開始後にソースデータベースまたはターゲットデータベースの接続に失敗した場合、DTSは再試行時間範囲内ですぐに接続を再試行します。有効な値: 10 ~ 1440 単位は分です。デフォルト値: 720 パラメーターを30より大きい値に設定することを推奨します。指定した再試行時間内にDTSがソースデータベースとターゲットデータベースに再接続された場合、DTSはデータ移行タスクを再開します。それ以外の場合、データ移行タスクは失敗します。説明同じソースまたはターゲットデータベースを共有する複数のデータ移行タスクに対して異なるリトライ時間範囲を指定した場合、後で指定される値が優先されます。 DTSが接続を再試行すると、DTSインスタンスに対して課金されます。業務要件に基づいて再試行時間範囲を指定することを推奨します。ソースデータベースとターゲットインスタンスがリリースされた後、できるだけ早くDTSインスタンスをリリースすることもできます。
移行元データベースと移行先データベースで他の問題が発生した場合の、再試行までの待機時間です。	その他の問題の再試行時間範囲。たとえば、データ移行タスクの開始後にDDLまたはDML操作の実行に失敗した場合、DTSは再試行時間範囲内ですぐに操作を再試行します。有効な値: 1 ~ 1440 単位は分です。デフォルト値は 10 です。パラメーターを10より大きい値に設定することを推奨します。指定された再試行時間内に失敗した操作が正常に実行された場合、DTSはデータ移行タスクを再開します。それ以外の場合、データ移行タスクは失敗します。重要の値は、移行元データベースと移行先データベースで他の問題が発生した場合の、再試行までの待機時間です。パラメーターは、失敗した接続の再試行時間パラメーターの値より小さくする必要があります。
完全なデータ移行のためのスロットリングを有効化	フルデータ移行のスロットリングを有効にするかどうかを指定します。完全データ移行中、DTSはソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを使用します。これは、データベースサーバの負荷を増加させる可能性がある。ビジネス要件に基づいて、フルデータ移行のスロットリングを有効にできます。スロットリングを設定するには、1 秒あたりのソースデータベースのクエリ率 QPS 、1 秒あたりの完全移行の行数 RPS、1 秒あたりの完全移行データ量 (MB) BPS パラメーターを設定する必要があります。これにより、移行先データベースサーバーの負荷が軽減されます。説明このパラメーターは、移行タイプパラメーターに完全データ移行を選択した場合にのみ設定できます。
完全なデータ移行のスロットリングを有効化	増分データ移行のスロットリングを有効にするかどうかを指定します。スロットリングを設定するには、1 秒あたりの増分移行の行数 RPSと1 秒あたりの増分移行データ量 (MB) BPS パラメーターを設定する必要があります。これにより、移行先データベースサーバーの負荷が軽減されます。説明このパラメーターは、移行タイプパラメーターに増分データ移行を選択した場合にのみ設定できます。
環境タグ	DTSインスタンスを識別するために使用される環境タグ。ビジネス要件に基づいて環境タグを選択できます。この例では、環境タグは追加されません。
ETL の設定	抽出、変換、および読み込み (ETL) 機能を有効にするかどうかを指定します。詳細については、「」をご参照ください。ETLとは何ですか? 有効な値： Yes: ETL機能を設定します。コードエディターでデータ処理ステートメントを入力できます。詳細については、「データ移行またはデータ同期タスクでのETLの設定」をご参照ください。 No: ETL機能を設定しません。
監視アラート	データ移行タスクのアラートを設定するかどうかを指定します。タスクが失敗するか、移行の待ち時間が指定されたしきい値を超えると、アラート送信先は通知を受け取ります。有効な値： No: アラートを設定しません。 Yes: アラートを設定します。この場合、アラートしきい値とアラート通知設定詳細については、「DTSタスクの作成時のモニタリングとアラートの設定」をご参照ください。

ページの下部で、次：タスク設定の保存と事前チェック をクリックします。
ポインタを 次：タスク設定の保存と事前チェック に移動し、[OpenAPIパラメーターのプレビュー] をクリックして、関連するAPI操作を呼び出してDTSタスクを設定するときに指定するパラメーターを表示できます。
説明
- データ移行タスクを開始する前に、DTSは事前チェックを実行します。データ移行タスクは、タスクが事前チェックに合格した後にのみ開始できます。
- タスクが事前チェックに合格しなかった場合は、失敗した各項目の横にある [詳細の表示] をクリックします。チェック結果に基づいて原因を分析した後、問題のトラブルシューティングを行います。次に、もう一度プレチェックを実行します。
- 事前チェック中にアイテムに対してアラートが生成された場合は、シナリオに基づいて次の操作を実行します。
  アラートアイテムを無視できない場合は、失敗したアイテムの横にある [詳細の表示] をクリックして問題のトラブルシューティングを行います。次に、もう一度プレチェックを実行します。
  アラート項目を無視できる場合は、[アラート詳細の確認] をクリックします。 [詳細の表示] ダイアログボックスで、[無視] をクリックします。表示されたメッセージボックスで、[OK] をクリックします。次に、[再度事前チェック] をクリックして、事前チェックを再度実行します。アラート項目を無視すると、データの不整合が発生し、ビジネスが潜在的なリスクにさらされる可能性があります。
成功率が100% になるまで待ちます。次に、[次へ: インスタンスの購入] をクリックします。

[インスタンスの購入] ページで、データ移行インスタンスのインスタンスクラスパラメーターを設定します。下表にパラメーターを示します。

セクション	パラメーター	説明
新しいインスタンスクラス	リソースグループ設定	データ移行インスタンスが属するリソースグループ。デフォルト値: Default resource group 詳細については、「」をご参照ください。リソース管理とは
新しいインスタンスクラス	インスタンスクラス	DTSは、移行速度が異なるインスタンスクラスを提供します。ビジネスシナリオに基づいてインスタンスクラスを選択できます。詳細については、「データ移行インスタンスの仕様」をご参照ください。

読んで同意するデータ伝送サービス (従量課金) サービス規約チェックボックスを選択します。
[購入と開始] をクリックして、データ移行タスクを開始します。タスクリストでタスクの進行状況を確認できます。
オプション。 ソースの自己管理型MongoDBデータベースの アクセス方法 パラメーターを ECS 上の自己管理データベース または データベースゲートウェイ に設定した場合、手順1〜12を繰り返して残りのシャードのデータ移行タスクを作成する必要があります。
データ移行タスクを停止します。
- フルデータ移行
  フルデータ移行中は、手動でタスクを停止しないことをお勧めします。そうしないと、ターゲットデータベースに移行されたデータが不完全になる可能性があります。フルデータ移行タスクが自動的に停止するまで待つことができます。
- 増分データ移行
  増分データ移行中にタスクが自動的に停止することはありません。タスクを手動で停止する必要があります。
  説明
  データ移行タスクを手動で停止する適切な時期を選択することを推奨します。たとえば、オフピーク時やワークロードをApsaraDB For MongoDBインスタンスに切り替える前にタスクを停止できます。
  1. データ移行タスクのプログレスバーに 増分データ移行 と 遅延なし が表示されるまで待ちます。その後、ソースデータベースへのデータの書き込みを数分間停止します。増分データ移行のレイテンシは、プログレスバーに表示されてもよい。の
  2. 増分データ移行のステータスが再び遅延なしに変更された後、すべてのシャードの移行タスクを手動で停止します。
ワークロードをターゲットApsaraDB for MongoDBインスタンスに切り替えます。