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 データベース | 移行対象データベースおよび設定データベースから読み取る | ソースデータベースの読み取り | ソースデータベース、管理用データベース、およびローカルデータベースでの読み取り |
| ApsaraDB for MongoDB インスタンス | dbAdminAnyDatabase 権限、移行先データベースに対する読み取りおよび書き込み権限、および local データベースに対する読み取り権限 |
データベースアカウントを作成して権限を付与するには：
自主管理 MongoDB データベース：db.createUser()
ApsaraDB for MongoDB インスタンス：MongoDB データベースのユーザー権限の管理
制限事項
ソースデータベースの制限事項
サーバーには十分なアウトバウンド帯域幅が必要です。帯域幅が不足すると、移行が遅くなります。
移行するコレクションには、プライマリキーまたは一意性制約が必要で、すべてのフィールドが一意である必要があります。そうでない場合、移行先に重複レコードが表示される可能性があります。
DTS は完全データ移行中にソースと移行先の両方のデータベースの読み取りおよび書き込みリソースを使用するため、サーバーの負荷が増加します。移行はオフピーク時間帯に実行してください。
ソースとターゲットのデータベースで異なる MongoDB バージョンまたはストレージエンジンを使用する場合は、まず互換性を確認してください。 詳細については、「MongoDB のバージョンとストレージエンジン」をご参照ください。
増分データ移行の場合、ソースデータベースで oplog を有効にし、oplog を少なくとも 7 日間保持してください。oplog が有効になっていない場合、事前チェック中にエラーメッセージが返され、データ移行タスクを開始できません。DTS が oplog を取得できない場合、タスクは失敗し、データの不整合や損失が発生する可能性があります。これらの保持要件は、DTS のサービスレベルアグリーメント (SLA) の対象外です。
移行オブジェクトとしてコレクションを選択し、移行先で編集 (名前の変更など) を計画している場合、1 つのタスクでサポートされるコレクションは最大 1,000 です。1,000 を超えるコレクションの場合は、複数のタスクを設定するか、データベース全体を移行してください。
admin または local データベースをソースまたは移行先として使用しないでください。
ソースの自主管理 MongoDB データベースには、10 を超える mongos ノードを含めることはできません。
TTL (Time To Live) インデックスを持つコレクションは移行しないでください。TTL インデックスは、移行後にソースと移行先の間でデータの不整合を引き起こす可能性があります。
ソースデータベースおよび送信先のシャードクラスターインスタンスに孤立ドキュメントが存在しないことを確認してください。孤立ドキュメントは、データの不整合やタスクの失敗を引き起こす可能性があります。詳細については、「MongoDB ドキュメント」および「シャードクラスターアーキテクチャでデプロイされた MongoDB データベースの孤立ドキュメントを削除する方法は？」をご参照ください。
移行中に、ソースデータベースで次のコマンドを実行しないでください。これらのコマンドはデータ分散を変更し、不整合を引き起こす原因となります。
shardCollection、reshardCollection、unshardCollection、moveCollection、movePrimary
スキーマ移行および完全データ移行中：
データベースやコレクションに対して、配列型の更新を含むスキーマ変更を行わないでください。スキーマ変更は、タスクの失敗やデータの不整合を引き起こします。
完全データ移行のみを実行する場合 (増分なし)、ソースデータベースにデータを書き込まないでください。データ整合性を確保するためには、スキーマ移行、完全データ移行、増分データ移行を一緒に選択してください。
移行中にソースデータベースのバランサーがアクティブな場合、チャンク移行によって遅延が発生する可能性があります。
その他の制限事項
タスクを設定する前に DTS インスタンスを購入する場合、購入時にシャード数を指定してください。
DTS は SRV 接続文字列を介して MongoDB データベースに接続できません。
移行を開始する前に、ソースデータベースのすべてのデータにシャードキーを追加してください。移行中、INSERT 操作にはシャードキーを含める必要があり、UPDATE 操作ではシャードキーを変更できません。
完全なデータ移行中は、ソース MongoDB データベースの Balancer を無効化します。各サブタスクが増分データ移行位相に達するまで、無効化を維持してください。事前に再度有効化すると、データの不整合が発生します。詳細については、「ApsaraDB for MongoDB Balancer の管理」をご参照ください。
移行先のデータベースに、ソースと同じプライマリキー (
_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] と [ポート番号] を設定します。
DTS は、各シャードノードを 1 つずつ移行することでクラスター全体を移行します。ここでは、最初のシャードノードのドメイン名または IP アドレスを入力します。後で 2 番目の移行タスクを作成するときに、2 番目のシャードノードのドメイン名または IP アドレスを入力します。すべてのシャードノードが移行されるまで、このプロセスを繰り返します。
をプライマリノードの IP アドレスとポートに設定するか、高可用性エンドポイントを設定します。詳細については、「ソースまたは移行先データベースが高可用性 MongoDB データベースである DTS タスクの作成[ECS 上の自己管理データベース] を介して接続する場合：[ポート番号] をプライマリノードのポートに設定します。
移行先がシャードクラスターインスタンスの場合、アプリケーションの動作が ApsaraDB for MongoDB シャードクラスターの要件を満たしていることを確認してください。
データ移行
事前準備
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（推奨）または ChangeStream を選択します。Oplog は、ソースで oplog が有効になっている場合（自己管理データベースおよび ApsaraDB for MongoDB インスタンスではデフォルトで有効）に利用可能で、低遅延の増分移行を実現します。ChangeStream は、チェンジストリームが有効になっている場合に利用可能です。詳細については、「Change Streams」をご参照ください。ソースが非エラスティックな Amazon DocumentDB クラスターの場合は、ChangeStream のみを選択してください。アーキテクチャー が シャードクラスター に設定されている場合、シャードアカウント および シャードパスワード パラメーターは不要です。 |
| エンドポイントタイプ | 環境に応じて、スタンドアロン または マルチノード を選択します。このパラメーターは、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 上の自己管理データベース または データベースゲートウェイ の場合は、代わりにシャードアクセスアカウントを入力してください。 |
| データベースパスワード | データベースアカウントのパスワードです。 |
| 複数のシャードノードへのアクセス | シャードノードへのアクセス情報です。ソースのアーキテクチャーが シャードクラスター、移行方法 が 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 が再接続できれば、タスクは再開されます。それ以外の場合は、タスクは失敗します。複数のタスクが同じデータベースを共有する場合、最も最近設定された再試行時間が適用されます。DTS は再試行中もインスタンスに対して課金されます。 |
| その他の問題発生時の再試行時間 | DDL または DML 操作の失敗に対する再試行ウィンドウです。有効値：1～1,440 分。デフォルト：10 分。10 分を超える値に設定してください。接続失敗時の再試行時間より短く設定する必要があります。 |
| 完全なデータ移行時のスロットリングを有効化 | 完全なデータ移行中の DTS リソース使用量を制限します。ソースデータベースへのクエリ数 (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%] に達するのを待ってから、[次へ：インスタンスの購入] をクリックします。
[インスタンスの購入] ページで、以下を設定します。
セクション パラメーター 説明 新規インスタンスクラス リソースグループ 移行インスタンスのリソースグループです。デフォルト値： デフォルトのリソースグループResource Management とは インスタンスクラス インスタンスクラスは移行速度を決定します。ご要件に応じて選択してください。詳細については、「データ移行インスタンスのインスタンスクラス」をご参照ください。 [Data Transmission Service (従量課金) 利用規約] を読み、チェックボックスを選択して同意します。
[購入して開始] をクリックし、確認ダイアログで [OK] をクリックします。
タスクが [データ移行] ページに表示されます。
完全データ移行のみ：タスクは自動的に停止します。ステータスは [完了] と表示されます。
増分データ移行：タスクは継続的に実行され、自動的に停止しません。ステータスは [実行中] と表示されます。
ステップ 8：残りのシャードのタスクを作成する (該当する場合)
[アクセス方法]がソースで「ECS 上のセルフマネージドデータベース」または「データベースゲートウェイ」の場合、残りの各シャードに対して手順 1～7 を繰り返します。
ステップ 9：移行タスクを停止する
[完全データ移行]
完全データ移行タスクを手動で停止しないでください。移行されたデータが不完全になる可能性があります。タスクが自動的に停止するのを待ちます。
[増分データ移行]
増分データ移行は自動的に停止しません。オフピーク時間帯や、ワークロードを移行先インスタンスに切り替える前など、適切なタイミングで手動で停止してください。
実行中 の進行状況バーに [増分データ移行] が表示され、操作情報 に 遅延なし が表示されるまで待機します。その後、ソースデータベースへのデータの書き込みを数分間停止します。
[増分データ移行] のステータスが [遅延なし] に戻った後、すべてのシャードに対して移行タスクを手動で停止します。
ステップ 10：ワークロードを移行先インスタンスに切り替える
移行が完了し、データを確認した後、ワークロードを移行先の ApsaraDB for MongoDB インスタンスに切り替えます。