Data Transmission Service:シャードキーのない MongoDB を MongoDB シャードクラスターに移行する

シャードキーの動作はターゲットの MongoDB バージョンに依存

DTS がデフォルトのシャードキー値をどのように処理するかは、ターゲットの MongoDB バージョンによって異なります：

• ターゲットの MongoDB が 4.4 より前の場合： [データベースとテーブルフィールドの設定] ステップで設定したデフォルトのシャードキー値が有効になります。DTS は元のデータにこのデフォルト値を入力し、ターゲットに書き込みます。

• ターゲットの MongoDB が 4.4 以降の場合： デフォルトのシャードキー値は有効になりません。DTS は元のデータをそのままターゲットに書き込みます。

続行する前に、ご利用のターゲットインスタンスにどちらの動作が適用されるかを評価してください。

データのシャーディングと事前シャーディング

ターゲットでシャーディングが必要な場合は、移行前にターゲットインスタンスにシャーディングが必要なデータベースとコレクションを作成してください。データのシャーディングを設定し、バランサーを有効にし、事前シャーディングを実行します。これにより、すべてのデータが単一のシャードに集中することを防ぎ、移行後のデータスキューを回避します。

詳細については、「シャードのパフォーマンスを最大化するためのデータシャーディングの設定」および「MongoDB シャードクラスターでの不均等なデータ分布に対処する方法」をご参照ください。

バージョンの互換性

ソースとターゲットの MongoDB のバージョンを同じにするか、古いバージョンから新しいバージョンに移行してください。新しいバージョンから古いバージョンへの移行は、互換性の問題を引き起こす可能性があります。

oplog を使用した増分移行

DTS は、以下の操作を通じて増分データをキャプチャします：

• CREATE COLLECTION、CREATE INDEX

• DROP DATABASE、DROP COLLECTION、DROP INDEX

• RENAME COLLECTION

• ドキュメントの挿入、更新、削除操作

更新されたドキュメントについては、DTS は $set からの更新のみを移行します。増分移行では、タスク開始後に作成されたデータベースからのデータはキャプチャされません。可能な限り増分移行には oplog を使用してください。oplog は、change stream よりも高速なログのプルと低いレイテンシーを提供します。

change stream を使用した増分移行

DTS は、以下の操作を通じて増分データをキャプチャします：

• DROP DATABASE、DROP COLLECTION

• RENAME COLLECTION

• ドキュメントの挿入、更新、削除操作

更新されたドキュメントについては、DTS は $set からの更新のみを移行します。

ソースデータベース

• 帯域幅： ソースサーバーには十分なアウトバウンド帯域幅が必要です。帯域幅が不足すると移行が遅くなります。

• プライマリキーまたは一意制約が必要： 移行するコレクションには、一意のフィールドを持つプライマリキーまたは UNIQUE 制約が必要です。そうでない場合、ターゲットに重複データが表示される可能性があります。

• タスクごとのコレクション制限： オブジェクト編集 (名前マッピングなど) を伴うコレクションレベルでの移行では、1 つのタスクで最大 1,000 コレクションまでサポートされます。この制限を超える場合は、コレクションを複数のタスクに分割するか、データベース全体を移行してください。

• ドキュメントサイズ制限： ソースの各ドキュメントは 16 MB 以下である必要があります。これより大きいドキュメントはタスクの失敗を引き起こします。

• Mongos ノード制限： ソースがシャードクラスターの場合、mongos ノードは 10 個以下である必要があります。

• 自己管理シャードクラスターのアクセス方法： [パブリック IP アドレス]、[Express Connect、VPN Gateway、または Smart Access Gateway]、および [Cloud Enterprise Network (CEN)] のみがサポートされています。

• oplog を使用した MongoDB 8.0+： ソースが MongoDB 8.0 以降を実行している自己管理シャードクラスターで、[移行方法] が [Oplog] の場合、シャードアカウントに directShardOperations 権限を付与します：username を移行タスクに使用するシャードアカウントに置き換えます。

    db.adminCommand({ grantRolesToUser: "username", roles: [{ role: "directShardOperations", db: "admin"}]})

• Azure Cosmos DB / Amazon DocumentDB エラスティッククラスター： 完全なデータ移行のみがサポートされています。

• 増分移行のための Oplog 保持期間： oplog 機能を有効にし、少なくとも 7 日間の操作ログ保持期間を設定する必要があります。または、7 日間のサブスクリプションウィンドウで change stream を有効にします。DTS がログにアクセスできない場合、タスクが失敗し、データ不整合またはデータ損失が発生する可能性があります。DTS SLA はこれらの問題をカバーしません。

• Change stream のバージョン要件： Change stream には MongoDB V4.0 以降が必要です。

• 非エラスティック Amazon DocumentDB クラスター: チェンジストリームを有効化し、[移行方法] を ChangeStream に設定し、[アーキテクチャ] を シャードクラスター に設定します。

• TTL インデックス： ソースの TTL インデックスは、移行後にソースとターゲット間でデータ不整合を引き起こす可能性があります。

• 孤立ドキュメント: ソースシャードクラスターに孤立ドキュメントが存在しないことを確認してください。そうしないと、データ不整合またはタスクの失敗が発生する可能性があります。詳細については、「孤立ドキュメント」および「MongoDB シャードクラスターで孤立ドキュメントをクリーンアップする方法」をご参照ください。

• バランサーのアクティビティ： ソースのシャードクラスターのバランサーがアクティブにデータをリバランスしている場合、インスタンスのレイテンシーが増加する可能性があります。

移行中の制限

• スキーマ移行と完全なデータ移行： データベースやコレクションに対して、配列型の更新を含むスキーマ変更を行わないでください。スキーマ変更はタスクの失敗やデータ不整合を引き起こす可能性があります。

• シャードクラスターソース： 移行インスタンスの実行中に、shardCollection、reshardCollection、unshardCollection、moveCollection、または movePrimary を実行してデータ分布を変更しないでください。そうしないと、データ不整合が発生する可能性があります。

• 完全移行のみ (増分なし)： ソースに新しいデータを書き込まないでください。リアルタイムの整合性を維持するには、[スキーマ移行]、[完全なデータ移行]、[増分データ移行] の 3 つの移行タイプすべてを選択してください。

一般的な制限事項

• 移行中の新しいコレクション： タスク開始後にソースに追加されたコレクションに対して、デフォルトのシャードキー値を設定することはできません。

• SRV アドレス： DTS は SRV アドレスを介した MongoDB への接続をサポートしていません。

• 非シャードソースからシャードターゲットへ： ソースが非シャードクラスターで、ターゲットが Alibaba Cloud シャードクラスターの場合、タスクは [データベースとテーブルフィールドの設定] ステップに進みます。

• 除外されるデータベース： DTS は admin、config、または local データベースからデータを移行できません。

• トランザクション： トランザクション情報は保持されません。ソースのトランザクションは、ターゲットでは個別のレコードに変換されます。

• プライマリキー/ユニークキーの競合： 競合が発生した場合、DTS は競合する書き込みをスキップし、ターゲットの既存データを保持します。

• フィールドの順序 (ソース < 3.6、ターゲット >= 3.6)： ソースが MongoDB 3.6 より前で、ターゲットが 3.6 以降を実行している場合、データベースエンジンの実行計画の違いにより、移行後にフィールドの順序が不整合になる可能性があります。ビジネスロジックにネストされた構造でのマッチクエリが含まれる場合は、その影響を評価してください。

• 同時書き込みによるストレージオーバーヘッド： 完全移行は同時 INSERT 操作を実行するため、コレクションの断片化が発生します。ターゲットはソースよりも 5% から 10% 多いストレージを占有します。

• タスクの自動再試行： DTS は過去 7 日以内に失敗したタスクを再試行します。ワークロードをターゲットに切り替える前に、タスクを停止またはリリースするか、ターゲットアカウントの書き込み権限を取り消してください。これにより、自動再開によってターゲットデータが上書きされるのを防ぎます。

• 一意なインデックスまたは capped コレクション： 一意なインデックスを持つコレクション、または capped 属性が true に設定されているコレクションは、増分移行中にシングルスレッド書き込みのみをサポートし (同時再生なし)、レイテンシーが増加する可能性があります。

• ドキュメント数のクエリ： ターゲットのドキュメント数をクエリするには、db.$table_name.aggregate([{ $count:"myCount"}]) を使用します。

• 重複するプライマリキー (_id)： ターゲットにソースと同じ _id 値を持つドキュメントがないことを確認してください。重複する _id 値はデータ損失を引き起こします。ビジネスに影響がない場合は、移行前にターゲットの競合するドキュメントをクリアしてください。

• DTS タスクの障害復旧: タスクに障害が発生した場合、DTS のテクニカルサポートは 8 時間以内に復旧を試みます。復旧中、タスクが再起動されたり、DTS タスクパラメーターが変更されたりすることがあります。データベースパラメーターは変更されません。変更されるパラメーターには、インスタンスパラメーターを変更するに記載されているものなどが含まれます。

• シャード化されたコレクションのコンプライアンス： ビジネスをターゲットに切り替えた後、すべてのビジネス運用はその MongoDB データベースのシャード化されたコレクションの要件に準拠する必要があります。

自己管理 MongoDB ソース

• 移行中のフェイルオーバー： 移行中にプライマリ/セカンダリのフェイルオーバーが発生した場合、タスクは失敗します。

• レイテンシーの計算： DTS は、最後に移行されたエントリのタイムスタンプと現在時刻を比較してレイテンシーを計算します。ソースが長期間更新されていない場合、表示されるレイテンシーが不正確になることがあります。ソースで更新を実行してレイテンシーをリフレッシュしてください。

• データベース全体の移行のためのハートビート： 定期的にデータ (例えば、1 秒ごと) を更新または書き込むハートビートコレクションを作成して、レイテンシーを正確に保ちます。

ステップ 1：データ移行ページを開く

以下のいずれかの方法で [データ移行] ページに移動します。

DTS コンソール：

1. DTS コンソールにログインします。

2. 左側のナビゲーションウィンドウで、[データ移行] をクリックします。

3. 左上隅で、データ移行インスタンスが存在するリージョンを選択します。

DMS コンソール：

実際の操作は、DMS コンソールのモードとレイアウトによって異なる場合があります。詳細については、「シンプルモード」および「ビジネス要件に基づいた DMS コンソールの設定」をご参照ください。

1. DMS コンソールにログインします。

2. 上部のナビゲーションバーで、[データ + AI] > [DTS (DTS)] > [データ移行] にカーソルを合わせます。

3. [データ移行タスク] の横にあるドロップダウンリストから、データ移行インスタンスが存在するリージョンを選択します。

ステップ 2：移行タスクを作成する

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

ステップ 3：ソースデータベースとターゲットデータベースを設定する

ソースデータベースとターゲットデータベースに以下のパラメーターを設定します。

タスク設定

ソースデータベース

ターゲットデータベース

ステップ 4：接続性をテストする

ページ下部の [接続性をテストして続行] をクリックします。

DTS サーバーの CIDR ブロックが、ソースおよびターゲットデータベースのセキュリティ設定に追加されていることを確認してください。詳細については、「DTS サーバーの CIDR ブロックをオンプレミスデータベースのセキュリティ設定に追加する」をご参照ください。ソースまたはターゲットが自己管理データベースであり、その [アクセス方法] が [Alibaba Cloud インスタンス] でない場合は、[DTS サーバーの CIDR ブロック] ダイアログボックスで [接続テスト] をクリックします。

ステップ 5：移行オブジェクトを設定する

[オブジェクトの構成] ページで、以下の設定を行います。

ステップ 6：詳細設定を行う

[次へ：詳細設定] をクリックし、以下のパラメーターを設定します。

ステップ 7：データ検証を設定する

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

ステップ 8：デフォルトのシャードキー値を設定する

次：データベースおよびテーブルのフィールド設定 をクリックして、シャードキーのないコレクションのデフォルトのシャードキー値を設定します。

1. ターゲットコレクションの行で、デフォルト値の設定 をクリックします。

   コレクションの ShardKey の数 が [0] の場合、そのコレクションにはシャードキーがなく、デフォルト値は必要ありません。

2. ShardKey デフォルト値タイプ を選択します。

   [string] と [int] 型のみがサポートされています。

3. シャードキーの デフォルト値 を入力します。

ステップ 9：事前チェックを実行する

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

このタスクの API パラメーターをプレビューするには、ボタンにカーソルを合わせ、[OpenAPI パラメーターのプレビュー] をクリックします。

DTS は移行を開始する前に事前チェックを実行します。タスクは事前チェックに合格した後にのみ開始されます。

• 事前チェックが失敗した場合、失敗した各項目の横にある [詳細の表示] をクリックし、問題をトラブルシューティングして、再度事前チェックを実行します。

• 事前チェック項目で警告がトリガーされた場合：

  • 警告を無視できない場合は、[詳細の表示] をクリックし、問題を修正して、再度事前チェックを実行します。

  • 警告を無視できる場合は、[アラート詳細の確認] > [無視] > [OK] をクリックし、次に [再度事前チェック] をクリックします。警告を無視すると、データ不整合が発生する可能性があります。

ステップ 10：インスタンスを購入して移行を開始する

1. [成功率] が [100%] に達するまで待ってから、[次へ：インスタンスの購入] をクリックします。

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

   パラメーター	説明
   [リソースグループ]	データ移行インスタンスが属するリソースグループです。デフォルト値は [デフォルトリソースグループ] です。詳細については、「Resource Management の概要」をご参照ください。
   [インスタンスクラス]	必要な移行速度に応じてインスタンスクラスを選択します。詳細については、「データ移行インスタンスのインスタンスクラス」をご参照ください。

3. [Data Transmission Service (従量課金) サービス規約] を読み、同意します。

4. [購入して開始] をクリックし、確認ダイアログで [OK] をクリックします。

タスクは [データ移行] ページに表示され、進行状況を監視できます。

• タスクに増分移行が含まれていない場合、自動的に停止し、[ステータス] は [完了] と表示されます。

• タスクに増分移行が含まれている場合、継続的に実行され、[ステータス] は [実行中] と表示されます。タスクは自動的に停止しません。