Data Transmission Service:ApsaraDB for MongoDB から AnalyticDB for PostgreSQL へのデータ移行

ソースデータベース

• 帯域幅：ソースデータベースサーバーには十分なアウトバウンド帯域幅が必要です。そうでないと、移行速度に影響が出ます。

• コレクション数の制限：名前マッピングを構成した場合、1 つの移行タスクで最大 1,000 コレクションを移行できます。この制限を超える場合は、オブジェクトを複数のタスクに分割してください。

• 完全移行のみ対応：スタンドアロンの MongoDB インスタンス、Azure Cosmos DB for MongoDB、Amazon DocumentDB エラスティッククラスターは、完全なデータ移行のみをサポートしています。

• 増分移行 — oplog／チェンジストリームの保持期間：ソースデータベースでは、oplog を有効化し、少なくとも 7 日間保持するか、またはチェンジストリームを有効化し、少なくとも 7 日間のサブスクライブ可能な履歴を確保する必要があります。この要件を満たさない場合、タスクが失敗したり、データ損失が発生したりする可能性があります。このような問題は Data Transmission Service (DTS) のサービスレベルアグリーメント (SLA) の対象外です。

  • 可能であれば oplog を使用してください。これにより、増分タスクのレイテンシを低減できます。

  • チェンジストリームは MongoDB 4.0 以降で必要です。

  • Amazon DocumentDB（非エラスティッククラスター）では、チェンジストリームを手動で有効化し、移行方法 を ChangeStreamチェンジストリーム に設定し、アーキテクチャ を Sharded Cluster に設定する必要があります。

• シャードクラスター — 一意の _id：移行対象のすべてのコレクションにおける _id フィールドは一意である必要があります。そうでないと、データの不整合が発生する可能性があります。

• シャードクラスター — Mongos ノード数：Mongos ノード数は 10 を超えてはなりません。

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

• 自己管理型シャードクラスター — 接続タイプ：パブリック IP、専用回線／VPN Gateway／Smart Gateway、CEN のみがサポートされています。

• 自己管理型シャードクラスター — MongoDB 8.0+ と oplog を併用：移行タスクで使用されるシャードアカウントには、directShardOperations 権限が必要です。以下のコマンドを実行して権限を付与します。

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

  username を実際のシャードアカウント名に置き換えてください。

• SRV レコード：SRV レコードを使用した MongoDB への接続はサポートされていません。

• アクティブなバランサーを備えたシャードクラスター：移行中にバランサーがデータのリバランスを行っている場合、インスタンスのレイテンシが発生する可能性があります。

移行中の操作

• 完全なデータ移行中は、配列型データの更新を含む、データベースまたはコレクションのスキーマを変更しないでください。

• 完全移行のみ（増分移行なし）を行う場合、移行中にソースインスタンスへの新規データの書き込みは行わないでください。

• シャードクラスターをソースとする場合、移行インスタンスが実行中は、shardCollection、reshardCollection、unshardCollection、moveCollection、movePrimary のようなデータ分布を変更するコマンドを実行しないでください。

その他の制限事項

• コレクションレベルの移行のみがサポートされています。

• admin、config、local データベースは移行できません。

• トランザクション情報は保持されません。ソースからのトランザクションは、送信先で個別のレコードに変換されます。

• FLOAT 列は 38 桁の精度で移行され、DOUBLE 列は 308 桁の精度で移行されます。DTS はこれらの値を ROUND(COLUMN,PRECISION) を使用して読み取ります。移行を実行する前に、この精度がビジネス要件を満たすかどうかを確認してください。

• 完全なデータ移行では同時 INSERT 操作が使用されるため、断片化が発生する可能性があります。移行後、送信先テーブルが使用するディスク領域は、ソースコレクションよりも大きくなる場合があります。

• DTS は失敗したタスクを 7 日間以内に再開しようと試みます。ビジネストラフィックを送信先に切り替える前に、タスクを終了または解放するか、revoke コマンドを使用して送信先アカウントの書き込み権限を取り消すことで、自動再開後にソースが送信先データを上書きすることを防止してください。

• DTS は、最後に移行されたレコードのタイムスタンプと現在時刻を比較してレイテンシを算出します。ソースが長期間更新されていない場合、レイテンシの数値は不正確になる可能性があります。これを更新するには、ソースデータベースに対して更新操作を実行してください。

• 時系列コレクション（MongoDB 5.0 で導入）の移行はサポートされていません。

• タスクが失敗した場合、DTS サポートスタッフは 8 時間以内にそのタスクを復旧しようと試みます。復旧中、タスクが再起動されるか、またはそのパラメーターが調整される場合があります。変更されるのは DTS タスクのパラメーターのみであり、データベースパラメーターは変更されません。調整可能なパラメーターの一覧については、「DTS インスタンスのパラメーターを変更する」をご参照ください。

ステップ 1：移行タスク一覧へ移動

DTS コンソールまたは DMS コンソールのいずれかを使用します。

ステップ 2：タスクの作成

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

ステップ 3：ソースおよび送信先データベースの構成

構成を完了したら、接続テストと続行 をクリックします。

DTS サーバーからのアクセスを許可するために、DTS サービスの IP アドレス範囲がソースデータベースとターゲットデータベースのセキュリティ設定に自動または手動で追加されていることを確認してください。 自己管理データベース ([アクセス方法] が [Alibaba Cloud インスタンス] ではない場合) では、[DTS サーバーの CIDR ブロック] ダイアログで [接続テスト] もクリックしてください。 詳細については、「DTS サーバーの IP アドレスをホワイトリストに追加する」をご参照ください。

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

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

選択済みオブジェクト で、オブジェクト名マッピングおよびフィールドマッピングを構成します。

データベース名をスキーマにマップ：

1. 選択済みオブジェクト 内のデータベースを右クリックします。

2. データベース名 を、AnalyticDB for PostgreSQL のターゲットスキーマの名前に変更します。

3. （任意）同期対象の DDL および DML 操作の選択 で、増分移行の対象となる操作を選択します。

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

コレクション名をテーブルにマップ：

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

2. テーブル名 を、AnalyticDB for PostgreSQL のターゲットテーブルの名前に変更します。

3. （任意）フィルター条件を設定します。詳細については、「フィルター条件の設定」をご参照ください。

4. （任意）同期対象の DDL および DML 操作の選択 で、増分移行の対象となる操作を選択します。

フィールドマッピングの構成：

DTS はコレクションのフィールドを送信先の列に自動的にマップします。 bson_value() 式を確認し、各フィールドについて 列名、型、長さ、および 精度 を構成します。

OK をクリックします。

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

次へ：高度な設定 をクリックし、以下の設定を行います。

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

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

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

DTS はタスク開始前に事前チェックを実行します。事前チェックが失敗した場合：

• 失敗した項目の横にある 詳細の表示 をクリックし、問題を修正してから 再チェック をクリックします。

• 無視可能な警告項目については：警告の詳細の確認、無視、OK、および 再チェック の順にクリックします。警告を無視すると、データの不整合が発生する可能性があります。

ステップ 7：インスタンスの購入

1. 成功率 が 100 % になったら、次へ：インスタンスの購入 をクリックします。

2. 購入 ページで、インスタンスを構成します。

   パラメーター	説明
   リソースグループ設定項目	インスタンスのリソースグループを選択します。デフォルト：デフォルトリソースグループ。詳細については、「Resource Management とは」をご参照ください。
   インスタンスクラス	必要な移行速度に基づいてリンク仕様を選択します。より高い仕様ほど、高速な移行をサポートします。詳細については、「データ移行リンク仕様」をご参照ください。

3. Data Transmission Service（従量課金）利用規約 を読み、同意します。

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

タスクは データ移行タスク 一覧ページに表示されます。そこで進行状況を監視できます。

完全移行のみのタスクの場合、完全移行が完了するとタスクは自動的に停止します。ステータス は 完了 に変わります。

増分移行を含むタスクの場合、タスクは継続して実行されます。ステータス は手動で停止するまで 実行中 のままです。

ソース MongoDB ドキュメント

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

送信先 AnalyticDB for PostgreSQL のテーブルスキーマ

移行後の送信先テーブルのデータ

上記のソースドキュメントを基に、移行後の送信先テーブルの内容を以下に示します。

この例では、sex は、対応する列が構成されていないため移行されません。

フィールドマッピングの構成