Data Transmission Service:ApsaraDB for MongoDB から AnalyticDB for MySQL 3.0 への移行

仕組み

MongoDB はドキュメント指向型データベースであり、AnalyticDB for MySQL V3.0 はリレーショナル分析データベースです。移行の設定を行う前に、MongoDB の概念とリレーショナルデータベースの概念との対応関係を理解してください。

DTS はソースの ApsaraDB for MongoDB インスタンスからデータを読み取り、bson_value() 式を使用して各 BSON フィールドを宛先列にマッピングし、AnalyticDB for MySQL V3.0 のターゲットテーブルにデータを書き込みます。

前提条件

開始する前に、以下の条件を満たしていることを確認してください。

• （シャードクラスターをソースとする場合のみ）すべてのシャードノードのエンドポイント。シャードノード間でユーザー名とパスワードが一貫している必要があります。詳細については、「シャードまたは ConfigServer コンポーネントのエンドポイント申請」をご参照ください。

• ソースインスタンスの合計データサイズよりも大きな利用可能なストレージ容量を持つ、宛先の AnalyticDB for MySQL V3.0 クラスター。詳細については、「クラスターの作成」をご参照ください。

  宛先データベースの利用可能なストレージ容量は、ソースデータベースのデータ総量に対して少なくとも 10 % 大きくすることを推奨します。

• 宛先クラスター内に、プライマリキー列を備えたデータベースおよびテーブルを作成済みであること。詳細については、「CREATE DATABASE」および「CREATE TABLE」をご参照ください。

• 宛先クラスターで、次のコマンドを実行して複数ステートメント機能を有効化済みであること：

  複数ステートメント機能は、AnalyticDB for MySQL V3.1.9.3 以降を必要とします。マイナーバージョンの確認および更新については、「クラスターのマイナーバージョンを更新する」をご参照ください。

  SET ADB_CONFIG ALLOW_MULTI_QUERIES=true;

宛先テーブルの設計要件：

• プライマリキー列は単一列である必要があります（複合プライマリキーはサポートされていません）。プライマリキー列には bson_value("_id") を割り当ててください。

• 宛先テーブルのデータ型は、ソースデータと互換性がある必要があります。たとえば、MongoDB の _id フィールドが ObjectId 型の場合、AnalyticDB for MySQL の対応する列は VARCHAR 型である必要があります。

• 任意の列に _id または _value という名前を付けないでください。これらの名前を付けると、移行タスクが失敗します。

課金

移行タイプ

移行中のサービス継続性を確保するには、完全データ移行 および 増分データ移行 の両方を選択してください。完全データ移行のみを選択した場合、データの不整合を防ぐため、移行中にソースデータベースへの書き込みを停止してください。

必要なデータベースアカウント権限

MongoDB アカウントの管理については、「アカウント管理」をご参照ください。AnalyticDB for MySQL のアカウントについては、「データベースアカウントの作成」をご参照ください。

注意事項

ブロッキング問題 — 移行開始前に解決してください：

• 移行対象として選択できるのはコレクションのみです。データベースレベルでの選択はサポートされていません。

• コレクションを移行対象として選択し、宛先データベース内のコレクション名を変更するなどの操作を行う場合、1 つのタスクで最大 1,000 個のコレクションをサポートします。それ以上のコレクションを移行する場合は、複数のタスクを作成してください。

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

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

• スタンドアロンの MongoDB データベース、Azure Cosmos DB for MongoDB クラスター、Amazon DocumentDB エラスティッククラスターから、DTS を使用して完全なデータを移行できます。

• シャードクラスターソースでは、各コレクションの _id フィールドは一意である必要があります。Mongos ノードの数は 10 を超えることはできません。インスタンスに孤立ドキュメントが含まれていてはなりません。孤立ドキュメントの詳細については、MongoDB ドキュメントおよびDTS よくある質問をご参照ください。

• 宛先クラスターのディスク使用率が 80 % を超えると、DTS タスクが遅延し、エラーが返されます。開始前に必要なストレージ容量を見積もってください。

• 宛先クラスターのデータ型がソースデータと互換性がない場合、移行タスクは失敗します。

• DTS タスク実行中に宛先クラスターのバックアップが実行されている場合、移行タスクは失敗します。

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

増分データ移行の要件：

• ソースデータベースで oplog 機能が有効化されており、oplog エントリが少なくとも 7 日間保持されている必要があります。あるいは、チェンジストリームが有効化されており、DTS が過去 7 日間のデータ変更をサブスクライブできる必要があります。DTS が操作ログを取得できない場合、タスクは失敗します。例外的なケースでは、データの不整合や損失が発生する可能性があり、これらは DTS のサービスレベルアグリーメント (SLA) の対象外となります。

• 可能であれば、oplog メソッドを使用してください。これはチェンジストリームよりも遅延が低くなります。

• チェンジストリームは、ソースデータベースが MongoDB V4.0 以降を実行している場合にのみサポートされます。

• Amazon DocumentDB の非エラスティッククラスターでは、チェンジストリームを使用する必要があります：移行方法 を ChangeStreamChange Streams に、アーキテクチャ を Sharded Cluster に設定します。

移行中の運用制限：

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

• ソースデータベースがシャードクラスターであり、Balancer がデータのリバランスを積極的に行っている場合、増分移行の遅延が増加する可能性があります。

• DTS はソースおよび宛先データベースの読み取り・書き込みリソースを使用します。本番ワークロードへの影響を最小限に抑えるため、非ピーク時間帯に移行を実行してください。

• 完全なデータ移行中、同時実行の INSERT 操作により、宛先コレクションに断片化が発生します。移行後、宛先のストレージ使用量がソースよりも大きくなる可能性があります。

浮動小数点および倍精度：

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

失敗したタスクの動作：

• DTS は、最大 7 日間、失敗したタスクを自動的に再試行します。ワークロードを宛先に切り替える前に、失敗したタスクを停止または解放するか、DTS アカウントの書き込み権限を取り消してください。そうしないと、タスクが再開された際にソースデータが宛先データを上書きする可能性があります。

• DTS タスクが失敗した場合、DTS のテクニカルサポートが 8 時間以内に復旧を試みます。復旧中、タスクが再起動され、タスクパラメーター（データベースパラメーターではない）が変更される場合があります。

移行遅延の測定：

DTS は、宛先で最新に移行されたレコードのタイムスタンプとソースの現在時刻を比較することで、増分移行の遅延を計算します。ソースで長期間更新が行われていない場合、報告される遅延は不正確になる可能性があります。遅延の読み取りを更新するには、ソースで更新操作を実行してください。

移行タスクの作成

ステップ 4：移行対象の構成

対象の構成 ページで、以下のパラメーターを設定します。

パラメーター	説明
移行タイプ	履歴データのみを移行する場合は、完全データ移行 を選択します。移行中に宛先を同期状態に保つ場合は、完全データ移行 および 増分データ移行 の両方を選択します。完全データ移行のみを選択した場合、移行中にソースへの書き込みを行わないでください。
同期対象の DDL および DML 操作	増分データ移行中に、インスタンスレベルで移行する DDL および DML 操作です。コレクションレベルで操作を構成するには、選択済みのオブジェクト 内のコレクションを右クリックし、移行する操作を選択します。
テーブルのマージ	いいえ（デフォルト）: 各コレクションを個別のテーブルに移行します。はいアラート通知設定: 複数のソースコレクションを 1 つの送信先テーブルにマージします。DTS は、データソースを識別するために __dts_data_source 列を追加します。「複数テーブルマージ機能を有効化する」をご参照ください。[はい] を選択した場合、タスクで選択されたすべてのソーステーブルが 1 つの送信先テーブルにマージされます。マージしないコレクションについては、別のタスクを作成してください。
競合するテーブルの処理モード	[事前チェックとエラーの報告]：送信先にソースと同じ名前のコレクションが存在する場合、事前チェックは失敗します。必要に応じて、オブジェクト名マッピングを使用して移行されるコレクションの名前を変更してください。詳細については、「オブジェクト名のマップ」をご参照ください。[エラーを無視して続行]：重複するコレクション名に対する事前チェックをスキップします。DTS は、送信先の既存レコードと同じプライマリキーを持つレコードをスキップします。データの不整合が発生する可能性があります。
ソースオブジェクト	ソースオブジェクト から 1 つ以上のコレクションを選択し、 をクリックして 選択済みのオブジェクト に追加します。

選択済みのオブジェクトセクションの構成：

1. 宛先データベース（スキーマ）の名前変更：

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

   2. スキーマ名 を、宛先の AnalyticDB for MySQL V3.0 クラスター内のデータベース名に設定します。

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

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

2. 宛先テーブルの名前変更：

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

   2. テーブル名 を、宛先クラスター内のテーブル名に設定します。

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

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

3. ソースフィールドと宛先列のマッピング： DTS は各フィールドに対して bson_value() 式を自動生成します。各列のマッピングを確認および調整してください。各列について：フィールドに異なる式が必要な場合（たとえば、ネストされたサブフィールド）：

   1. 列の横にある をクリックし、+ 列の追加 をクリックします。

   2. 列名、型、長さ、および 精度 を設定します。

   3. 値の割り当て 列に bson_value() 式を入力します。「フィールドマッピングの例」セクションを参考にしてください。

   4. 各フィールドについて繰り返します。

   重要

   プライマリキー列には bson_value("_id") を割り当ててください。サブフィールドには、ネストされた bson_value() 式を使用します：bson_value("parent", "child")。単独で bson_value("parent") を使用すると、サブフィールドの増分変更をキャプチャできません。

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

データ型のマッピング

フィールドマッピングの例

この例では、ネストされたオブジェクトを含む MongoDB ドキュメントのフィールドを、AnalyticDB for MySQL V3.0 のテーブルの列にマッピングする方法を示します。

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

次のステップ

移行タスクのステータスが 実行中 になり、増分移行の遅延がほぼ 0 になった時点で、宛先の AnalyticDB for MySQL V3.0 クラスターはソースと同期状態になります。ワークロードを宛先クラスターに切り替え、DTS タスクを停止してください。