Data Transmission Service:ApsaraDB for MongoDB インスタンスから Lindorm インスタンスへのデータ移行

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

以下のいずれかの方法を使用してください。

ステップ 2：ソースおよび宛先データベースの構成

タスクの作成 をクリックし、以下の表に記載されているパラメーターを構成してください。

ソースデータベースのパラメーター

宛先データベースのパラメーター

ステップ 3：接続性のテストと続行

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

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

ステップ 4：移行対象オブジェクトの構成

オブジェクトの構成 ページで、以下のパラメーターを設定してください。

移行タイプおよびオブジェクト

パラメーター	説明
移行タイプ	一度限りの移行には 完全なデータ移行 を選択します。移行中にソースと宛先を同期させ、ダウンタイムを最小限に抑えるには、完全なデータ移行 および 増分データ移行 の両方を選択します。
競合するテーブルの処理モード	構成は不要です。
宛先インスタンスにおけるオブジェクト名の大文字小文字の扱い	宛先のデータベース名およびコレクション名の大文字・小文字の使用ポリシー。デフォルト: [DTS デフォルトポリシー]。「宛先インスタンスでのオブジェクト名の大文字・小文字の使用方法を指定する」をご参照ください。
ソースオブジェクト	移行するコレクションを選択し、 をクリックして 選択済みのオブジェクト に移動します。

選択済みのオブジェクトの構成

選択済みのオブジェクト 内の各コレクションについて、スキーマ名、テーブル名、およびカラムマッピングを構成します。

以下は、ソースの MongoDB 文書が Lindorm のワイドテーブルの行にどのようにマップされるかを示す例です。

ソース文書（ApsaraDB for MongoDB）

{
  "_id": "62cd344c85c1ea6a2a9f****",
  "person": {
    "name": "neo",
    "age": "26",
    "sex": "male"
  }
}

宛先テーブルの行（Lindorm）

スキーマ、テーブル名、カラムマッピングを構成するには、以下の手順を実行します。

1. スキーマ名の編集：

   1. 選択済みのオブジェクト で、コレクションを含むデータベースを右クリックします。

   2. スキーマ編集ダイアログボックスで、スキーマ名 フィールドに、Lindorm インスタンスで使用するデータベース名を入力します。

   3. （任意）同期する DDL および DML 操作の選択 で、増分データ移行中に移行する操作を選択します。

   4. OK をクリックします。

2. テーブル名の編集：

   1. 選択済みのオブジェクト で、コレクションを右クリックします。

   2. テーブル名編集ダイアログボックスで、テーブル名 フィールドに、Lindorm インスタンスで使用するテーブル名を入力します。

   3. （任意）フィルター条件を指定します。「フィルター条件の指定」をご参照ください。

   4. （任意）同期する DDL および DML 操作の選択 で、増分データ移行中に移行する操作を選択します。

3. ソースフィールドと宛先カラムのマッピング： DTS は、ソースコレクション内の各フィールドを bson_value() 式を使用して自動的にマップし、カラムに割り当てます。bson_value() 式内で "" で囲まれたフィールド名は、ソースの MongoDB インスタンスにおけるフィールド名です。たとえば、bson_value("age") は age フィールドをマップします。（任意）カラムの横にある アイコンをクリックして、移行不要なフィールドを削除できます。また、bson_value() 式が要求される宛先カラムと一致していることを確認してください。

   1. 値の割り当て 列の bson_value() 式内で、MongoDB のフィールド名を確認します。

      "" 内のフィールドが MongoDB のフィールド名です。たとえば、式が bson_value("age") の場合、この式は MongoDB の age フィールドをマップします。

   2. （任意）移行不要なフィールドの横にある アイコンをクリックします。

      説明

      移行不要なフィールドを削除するには、そのフィールドの行にある をクリックします。

   3. 移行するフィールドを構成します。

      bson_value() 式が要件を満たすかどうかに応じて、次の手順を実行します。

      式が要件を満たすフィールド

      1. 宛先テーブルの カラム名 を入力します。

         説明

         • SQL で作成されたテーブルの場合：テーブルで定義されたカラム名を使用します。

         • Apache HBase API で作成されたテーブルの場合：プライマリキー列には ROW を使用し、その他のカラムには カラムファミリー:カラム名 形式（例：person:name）を使用します。まずカラムマッピングを設定してください。「Apache HBase API テーブルのカラムマッピングの追加」をご参照ください。

      2. カラムデータの 型 を選択します。

         重要

         宛先カラムのデータ型は、ソースフィールドの型と互換性がある必要があります。

      3. （任意）長さ および 精度 を設定します。

      4. すべての必要なフィールドをマップするまで、これらの手順を繰り返します。

      式が要件を満たさないフィールド

      説明

      たとえば、階層構造（親子構造）を持つフィールドです。

      1. カラムの横にある アイコンをクリックします。

      2. + カラムの追加 をクリックします。

      3. カラム名、型、長さ、および 精度 を設定します。

      4. 値の割り当て 下のテキストボックスに、bson_value() 式を入力します。詳細については、「値の割り当ての例」をご参照ください。

         重要

         • 常にプライマリキー列を bson_value("_id") として割り当てます。

         • ネストされたフィールドの場合は、式内でフィールドとサブフィールドの両方を指定します — たとえば、bson_value("person","name")。単に bson_value("person") を使用すると、サブフィールドのデータが失われます。

      5. 各フィールドについて、これらの手順を繰り返します。

4. OK をクリックします。

ステップ 5：高度な設定の構成

次へ：高度な設定 をクリックし、以下のパラメーターを構成します。

ステップ 6：事前チェックの実行と設定の保存

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

保存前にこのタスク構成の API パラメーターを表示するには、次へ：タスク設定の保存と事前チェック の上にポインターを合わせ、OpenAPI パラメーターのプレビュー をクリックします。

DTS は移行開始前に事前チェックを実行します。事前チェックの失敗項目に対処してください。

• 失敗した項目の場合： 詳細の表示 をクリックし、問題を修正した後、再び事前チェック をクリックします。

• 警告項目の場合：

  • 警告を無視できない場合は、問題を修正して再度事前チェックを実行してください。

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

ステップ 7：インスタンスの購入および起動

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

2. インスタンスの購入 ページで、以下のパラメーターを構成します。

   パラメーター	説明
   リソースグループ	データ移行インスタンスのリソースグループ。 デフォルト: [デフォルトリソースグループ]。 詳細については、「Resource Management とは
   インスタンスクラス	移行スループット階層です。クラスが高くなるほど、移行速度が速くなります。詳細については、「データ移行インスタンスのインスタンスクラス」をご参照ください。

3. Data Transmission Service（従量課金）サービス利用規約 を読み、チェックボックスをオンにしてください。

4. 購入および起動 をクリックし、確認ダイアログボックスで OK をクリックします。

移行ステータスの確認

データ移行 ページで、タスクのステータスを確認します。

• 完全なデータ移行のみ： 完了時にタスクが自動的に停止します。ステータスは 完了 に変わります。

• 完全 + 増分データ移行： 増分移行は継続的に実行され、停止しません。ステータスは 実行中 と表示されます。宛先データベースへの切り替え準備が整ったら、手動でタスクを停止またはリリースしてください。

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

• ソースサーバーには十分なアウトバウンド帯域幅が必要です。帯域幅が不足していると、移行速度が低下します。

• コレクションには PRIMARY KEY または UNIQUE 制約が必要であり、すべてのフィールドが一意である必要があります。そうでない場合、宛先に重複レコードが発生する可能性があります。

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

• DTS は SRV エンドポイント経由で MongoDB に接続できません。

• コレクションを移行対象として選択し、名前を変更する場合、1 つのタスクで最大 1,000 個のコレクションを移行できます。この上限を超えるとリクエストエラーが発生します。移行を複数のタスクに分割してください。

完全なデータ移行の制限事項

• 完全なデータ移行中に、配列型の更新を含むデータベースまたはコレクションのスキーマ変更を行わないでください。スキーマ変更により、タスクが失敗したりデータの不整合が発生したりする可能性があります。

• 完全なデータ移行のみを実行する場合、ソースデータベースへの書き込みを行わないでください。ソースへの書き込みにより、データの不整合が発生します。

• 完全移行中の同時 INSERT 操作により、宛先コレクションに断片化が発生します。宛先コレクションで使用されるストレージは、ソースよりも大きくなります。

増分データ移行の制限事項

• 文書に対する INSERT、UPDATE、DELETE 操作のみが移行されます。UPDATE 操作については、$set を使用した更新のみが移行されます。

• oplog 機能が有効化されており、操作ログが最低 7 日間保持されている必要があります。あるいは、change streams が有効化されており、DTS が過去 7 日間の変更をサブスクライブ可能である必要があります。これらの要件を満たさない場合、DTS が操作ログを取得できず、タスクが失敗する可能性があります。例外的なケースでは、データの不整合または損失が発生する可能性があります。

• 可能な限り、oplog 機能を使用してデータ変更を取得してください。change streams は、ソースが MongoDB v4.0 以降を実行している場合にのみ使用してください。

• トランザクション情報は保持されません。トランザクションは単一のレコードに変換されます。

• DTS は、宛先で最新に移行されたレコードのタイムスタンプとソースの現在のタイムスタンプに基づいて移行遅延を計算します。ソースで長期間更新が行われない場合、遅延値が不正確になる可能性があります。遅延を更新するには、ソースに更新を書き込んでください。

シャードクラスターの制限事項

• _id フィールドは、すべてのシャード間で一意である必要があります。_id 値が重複すると、データの不整合が発生します。

• Mongos ノードの数は 10 を超えてはなりません。

• タスク実行中に、移行対象のオブジェクトに対して以下のコマンドを実行しないでください：shardCollection、reshardCollection、unshardCollection、moveCollection、movePrimary。これらのコマンドはデータ分布を変更し、データの不整合を引き起こします。

• ソースのシャードクラスターで Balancer がアクティブな場合、移行遅延が発生する可能性があります。

Lindorm 宛先の制限事項

• 宛先の Lindorm インスタンスには、_id または _value という名前のカラムを含むコレクションを含めることはできません。このようなカラムが存在する場合、タスクは失敗します。

• 移行されたデータは、データリクエストの使用制限に準拠する必要があります。

• FLOAT の精度はデフォルトで 38 桁、DOUBLE の精度はデフォルトで 308 桁です。DTS はこれらの値を取得するために ROUND(COLUMN,PRECISION) を使用します。移行開始前に、精度設定がビジネス要件を満たしていることを確認してください。

• ソースに TTL インデックスが含まれている場合、移行後にデータの不整合が発生する可能性があります。

Azure Cosmos DB および Amazon DocumentDB の制限事項

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

• 弾力性のない Amazon DocumentDB クラスターの場合：change streams を有効化し、移行方法 を ChangeStream に、アーキテクチャ を シャードクラスター に設定します。

その他の運用に関する注意事項

• 移行を開始する前に、ソースおよび宛先データベースのパフォーマンスへの影響を評価してください。可能な場合は、ピーク時を避けて移行を実行してください。完全なデータ移行では、両方のデータベースで読み取りおよび書き込みリソースが使用され、サーバー負荷が増加する可能性があります。

• DTS タスクが失敗した場合、DTS テクニカルサポートは 8 時間以内に復旧を試みます。復旧中、タスクが再起動される場合や、パラメーターが変更される場合があります。変更されるのは DTS タスクのパラメーターのみであり、データベースのパラメーターは変更されません。変更される可能性のあるパラメーターには、「DTS インスタンスのパラメーターを変更する」で説明されているものも含まれます。