ソースデータベースへの影響
DTSはフルデータ同期を実行する際に、一定のソースデータベースリソースを占有し、ソースデータベースの負荷上昇を引き起こし、データベース自体の圧力を高める可能性があります。データベースの設定が低すぎる場合は、ビジネスのオフピーク期にデータ移行を実行することをお勧めします。
ターゲットデータベースへの影響
移行プロセス中、DTSはシステムサービスアカウントを使用して、ターゲット側のTencentDTSDataデータベースにタスクIDでテーブルを作成します（例えばテーブル名はdts-xxxxx）。このテーブルはCHECKPOINTの記録に使用され、タスクが中断された場合に再開を実現します。
移行アーキテクチャ
1. シャード移行に関する説明は以下の通りです：
1.1 シャードクラスターの移行前に、ソースクラスターの孤立ドキュメント（Orphaned Document）を事前にクリーンアップすることをお勧めします。そうしないと、移行後のデータ検証に不一致が生じる可能性があります。孤立ドキュメントのクリーンアップ方法については、MongoDB公式ドキュメントcleanupOrphanedを参照してください。 1.2 シャード移行中は、ソース側で移行対象のデータベース・テーブルに対してシャードを有効にしないでください。ソース側とターゲット側のデータ分散の不一致を避けるためです。移行中に、ソース側で移行対象のデータベース・テーブルに対してシャードを有効にする操作が存在する場合は、ターゲット側でシャードの状態をチェックしてください。ターゲット側でシャードが有効になっていない場合は、手動でシャードを有効にする操作を実行してください。シャードを有効にする具体的な操作については、MongoDB公式ドキュメントShard a Collectionを参照してください。 1.3 ソース側がTencent Cloud MongoDB 3.2バージョンのシャードクラスターである場合、移行時はデフォルトですべてのシャードキーをハッシュシャードキーとして処理します。ターゲット側で範囲シャードキーを使用する場合は、データ移行前に、あらかじめターゲット側で範囲シャードキーを作成してください。
1.4 シャードクラスターの移行中はシャード数を増減しないでください。そうしないと、データの不一致が発生する可能性があります。
2. 単一ノードにはOplogがないため、自己構築インスタンスが単一ノードの場合は、増分移行をサポートしていません。
3. レプリカセットおよびシャードクラスター版（4.2以降のバージョン）MongoDBの移行では、増分移行はChange Streamによるデータ変更の取得をサポートします。
4. シャードクラスター版MongoDBの移行では、SRVアドレスによるMongoDBデータベースへの接続をサポートします。
注意事項
注意：
ソース側がAWS DocumentDBであり、増分移行にChange Stream移行方式を選択している場合は、必ずChange Streamを有効にしてください。そうしないと、増分データを同期できなくなります。
1. 移行中に以下の操作を行わないでください。行った場合、移行タスクが失敗する可能性があります。
ソースデータベースとターゲットデータベース内のユーザー情報（ユーザー名、パスワード、権限を含む）とポート番号を変更、削除しないでください。
ソースデータベース上でoplogを削除する操作を実行しないでください。
データ移行段階では、ターゲットデータベースTencentDTSDataを削除しないでください。
2. データ移行段階では、ターゲットデータを慎重に操作してください。最終的なデータの不一致を避けてください。