すべてのプロダクト
Search
ドキュメントセンター

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

最終更新日:Feb 05, 2026

このトピックでは、Data Transmission Service (DTS) を使用して、PolarDB for PostgreSQL クラスターから AnalyticDB for PostgreSQL インスタンスにデータを移行する方法について説明します。

前提条件

  • ソースの PolarDB for PostgreSQL インスタンスよりもディスク領域が大きいターゲットの AnalyticDB for PostgreSQL インスタンスを作成します。 詳細については、「インスタンスの作成」をご参照ください。

  • ソースの PolarDB for PostgreSQL クラスターの wal_level パラメーターを logical に設定します。 詳細については、「クラスターパラメーターの設定」をご参照ください。

  • 移行したデータを格納するために、ターゲットの AnalyticDB for PostgreSQL インスタンスにデータベースを作成します。 詳細については、「CREATE DATABASE」をご参照ください。

注意事項

説明
  • スキーマ移行中、DTS はソースデータベースからターゲットデータベースに外部キーを移行します。

  • 完全なデータ移行および増分データ移行中、DTS はセッションレベルで制約チェックと外部キーのカスケード操作を一時的に無効にします。 タスクの実行中にソースデータベースでカスケード更新または削除操作が発生すると、データ整合性が失われる可能性があります。

タイプ

説明

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

  • PolarDB for PostgreSQL クラスターでは、移行するテーブルにプライマリキーまたは NULL でない一意なインデックスが必要です。

  • ソースデータベースに長時間トランザクションがあり、インスタンスに増分移行タスクがある場合、長時間トランザクションがコミットされる前に生成された先行書き込みログ (WAL) が蓄積される可能性があります。 これにより、ソースデータベースのディスク領域が不足する可能性があります。

  • 移行タスクが期待どおりに実行され、プライマリ/セカンダリの切り替えによって論理レプリケーションが中断されるのを防ぐために、PolarDB for PostgreSQL クラスターは Logical Replication Slot Failover をサポートし、有効にする必要があります。

    説明

    ソース PolarDB for PostgreSQL クラスターが論理レプリケーションスロットのフェイルオーバーをサポートしていない場合(例:クラスターの [データベースエンジン]PostgreSQL 14 の場合)、ソースデータベースでの高可用性(HA)スイッチオーバーにより、移行インスタンスが失敗し、回復不能になる可能性があります。

  • ソースデータベースでの操作に関する制限:

    • スキーマ移行および完全移行中は、データベースまたはテーブルの構造を変更する DDL 操作を実行しないでください。 そうしないと、データ移行タスクは失敗します。

    • 完全なデータ移行のみを実行する場合は、ソースインスタンスに新しいデータを書き込まないでください。 そうしないと、ソースデータベースとターゲットデータベースの間でデータ整合性が失われます。 リアルタイムのデータ整合性を維持するために、スキーマ移行、完全なデータ移行、および増分データ移行を選択することを推奨します。

    • ソースデータベースの論理レプリケーションの固有の制限により、増分変更後に移行する単一のデータが 256 MB を超えると、移行インスタンスが失敗して回復不能になる可能性があります。 移行インスタンスを再設定する必要があります。

その他の制限

  • 1 つのデータ移行タスクで移行できるデータベースは 1 つだけです。 複数のデータベースを移行するには、データベースごとに個別のデータ移行タスクを設定します。

  • DTS は、TimescaleDB 拡張テーブル、スキーマ間の継承を持つテーブル、または式に基づく一意なインデックスを持つテーブルの移行をサポートしていません。

  • プラグインをインストールして作成されたスキーマは移行できません。 タスクを設定する際に、コンソールでこれらのスキーマに関する情報を取得することはできません。

  • DTS は、DATATYPE、SEQUENCE、INDEX、PROCEDURE、FUNCTION、VIEW、OPERATOR、DEFAULT_CONSTRAINT、UK、PK、RULE、DOMAIN、AGGREGATE、EXTENSION、FK、または TRIGGER の移行をサポートしていません。

  • 移行インスタンスに増分データ移行タスクが含まれている場合は、データを書き込む前に、ソースデータベースの移行対象テーブルで ALTER TABLE schema.table REPLICA IDENTITY FULL; コマンドを実行する必要があります。 これにより、データ整合性が確保されます。 このコマンドは、次のシナリオで実行します。 このコマンドの実行中は、デッドロックを避けるためにテーブルロック操作を実行しないでください。 事前チェックで関連するチェックをスキップした場合、DTS はインスタンスの初期化中にこのコマンドを自動的に実行します。

    • インスタンスが初めて実行されるとき。

    • 移行オブジェクトがスキーマであり、スキーマ内に新しいテーブルが作成されるか、RENAME コマンドを使用して既存のテーブルが再構築されるとき。

    説明
    • コマンドで、schematable を実際のスキーマ名とテーブル名に置き換えてください。

    • この操作はオフピーク時間に実行することを推奨します。

  • 移行するテーブルにプライマリキーがある場合、ターゲットテーブルのプライマリキー列はソーステーブルと同じでなければなりません。 移行するテーブルにプライマリキーがない場合、ターゲットテーブルのプライマリキー列は分散キーと同じでなければなりません。

  • プライマリキー列を含む一意なキーには、分散キーのすべての列が含まれている必要があります。

  • 完全なデータ移行では同時 INSERT 操作が実行されるため、ターゲットデータベースでテーブルの断片化が発生します。 その結果、完全移行が完了すると、ターゲットデータベースのテーブルスペースはソースデータベースよりも大きくなります。

  • DTS は 7 日以内に失敗したタスクを自動的に回復しようとします。 したがって、ビジネスをターゲットインスタンスに切り替える前に、タスクを終了またはリリースするか、revoke コマンドを使用して DTS がターゲットインスタンスにアクセスするために使用するアカウントの書き込み権限を取り消す必要があります。 これにより、タスクが自動的に回復された後、ソースデータがターゲットインスタンスのデータを上書きするのを防ぎます。

  • DTS はデータ内容を検証しますが、シーケンスなどのメタデータの検証はサポートしていません。 メタデータはご自身で検証する必要があります。

  • DTS は、増分データの DDL 文、増分テーブルの構造、およびハートビート情報を取得するために、ソースデータベースに次の一時テーブルを作成します。 移行中にこれらの一時テーブルを削除しないでください。 そうしないと、DTS タスクが異常になります。 一時テーブルは、DTS インスタンスがリリースされた後に自動的に削除されます。

    public.dts_pg_classpublic.dts_pg_attributepublic.dts_pg_typepublic.dts_pg_enumpublic.dts_postgres_heartbeatpublic.dts_ddl_commandpublic.dts_args_session、および public.aliyun_dts_instance

  • 増分データ移行中、DTS はソースデータベースにプレフィックス dts_sync_ を持つレプリケーションスロットを作成してデータをレプリケーションします。 DTS はこのレプリケーションスロットを使用して、過去 15 分間の増分ログをソースデータベースから取得します。 データ移行が失敗した場合、または移行インスタンスがリリースされた場合、DTS はこのレプリケーションスロットを自動的にクリーンアップしようとします。

    説明
    • データ移行中にソースデータベースアカウントのパスワードを変更したり、ソースデータベースの IP アドレスホワイトリストから DTS の IP アドレスを削除したりすると、レプリケーションスロットは自動的にクリーンアップできません。 この場合、ソースデータベースでレプリケーションスロットを手動でクリーンアップする必要があります。 これにより、スロットが継続的に蓄積されてディスク領域を消費し、ソースデータベースが利用できなくなるのを防ぎます。

    • ソースデータベースでフェールオーバーが発生した場合は、セカンダリデータベースにログインしてスロットを手動でクリーンアップする必要があります。

  • ビジネスをターゲットインスタンスに切り替えた後、新しいシーケンスはソースデータベースの対応するシーケンスの最大値から増分を開始しません。 切り替え前に、ソースデータベースで対応するシーケンスの最大値をクエリし、それをターゲットデータベースのシーケンスの初期値として使用します。 次のコマンドは、ソースデータベースのシーケンス値をクエリします:

    do language plpgsql $$
    declare
      nsp name;
      rel name;
      val int8;
    begin
      for nsp,rel in select nspname,relname from pg_class t2 , pg_namespace t3 where t2.relnamespace=t3.oid and t2.relkind='S'
      loop
        execute format($_$select last_value from %I.%I$_$, nsp, rel) into val;
        raise notice '%',
        format($_$select setval('%I.%I'::regclass, %s);$_$, nsp, rel, val+1);
      end loop;
    end;
    $$;
    説明

    上記のコマンドによって出力される SQL 文には、ソースデータベースのすべてのシーケンスが含まれています。 必要に応じて、ターゲットデータベースで必要な SQL 文を実行してください。

  • ターゲットテーブルは AO テーブルをサポートしていません。

  • ソースとターゲットのテーブルスキーマが一致しない場合、または完全でないテーブル移行に列マッピングを使用する場合、ソーステーブルには存在するがターゲットテーブルには存在しない列のデータは失われます。

  • タスクが失敗した場合、DTS テクニカルサポートは 8 時間以内に回復を試みます。 回復プロセス中に、タスクの再起動やパラメーターの調整などの操作が実行される場合があります。

    説明

    パラメーターが調整される際、DTS タスクのパラメーターのみが変更され、データベースのパラメーターは変更されません。変更される可能性のあるパラメーターには、「インスタンスパラメーターの変更」で説明されているものが含まれますが、これらに限定されません。

  • パーティションテーブルを移行する場合、親テーブルとその子テーブルの両方を同期オブジェクトとして含めてください。 そうしないと、パーティションテーブルでデータ整合性が失われる可能性があります。

    説明

    PostgreSQL では、パーティションテーブルの親テーブルは直接データを格納しません。 すべてのデータは子テーブルに格納されます。 同期タスクには、親テーブルとそのすべての子テーブルを含める必要があります。 そうしないと、子テーブルのデータが同期されず、ソースとターゲットの間でデータ整合性が失われる可能性があります。

課金

移行タイプ

リンク設定料金

データ転送料金

スキーマ移行と完全なデータ移行

無料です。

このシナリオは無料です。

増分データ移行

課金されます。 詳細については、「課金の概要」をご参照ください。

増分移行でサポートされる SQL 操作

操作タイプ

SQL 操作

DML

INSERT、UPDATE、および DELETE

説明

データがターゲットの AnalyticDB for PostgreSQL インスタンスに書き込まれると、UPDATE 文は自動的に REPLACE INTO 文に変換されます。 プライマリキーが更新されると、文は DELETE 文と INSERT 文に変換されます。

DDL

  • 2020 年 10 月 1 日以降に作成されたデータ移行タスクのみが DDL 操作の移行をサポートします。

    重要
    • 2023 年 5 月 12 日より前に作成されたデータ移行タスクの場合、移行タスクを設定する前に、ソースデータベースにトリガーと関数を作成して DDL 情報をキャプチャする必要があります。 詳細については、「トリガーと関数を使用した PostgreSQL の増分 DDL 移行の実装」をご参照ください。

    • bit データ型は増分データ移行中に移行できません。

  • ソースデータベースアカウントが特権アカウントの場合、移行タスクは次の DDL 文をサポートします:

    • CREATE TABLE、DROP TABLE

    • ALTER TABLE (RENAME TABLE、ADD COLUMN、ADD COLUMN DEFAULT、ALTER COLUMN TYPE、DROP COLUMN、ADD CONSTRAINT、ADD CONSTRAINT CHECK、および ALTER COLUMN DROP DEFAULT を含む)

    • TRUNCATE TABLE (ソースが PostgreSQL 11 以降の場合)

    • CREATE INDEX ON TABLE

    重要
    • CASCADE や RESTRICT などの DDL 文内の追加情報は移行されません。

    • SET session_replication_role = replica コマンドを使用するセッションの DDL 文は移行されません。

    • FUNCTION または他のメソッドを呼び出して実行される DDL 文は移行されません。

    • ソースデータベースで単一のトランザクションで送信された複数の SQL 文に DML 文と DDL 文の両方が含まれている場合、DDL 文は移行されません。

    • ソースデータベースで単一のトランザクションで送信された複数の SQL 文に非移行オブジェクトの DDL 文が含まれている場合、DDL 文は移行されません。

データベースアカウントの権限

データベース

必要な権限

アカウント作成と権限付与の方法

ソースの PolarDB for PostgreSQL クラスター

特権アカウント。

データベースアカウントの作成

ターゲットの AnalyticDB for PostgreSQL インスタンス

ターゲットデータベースに対する読み取りおよび書き込み権限。

ユーザーの作成と管理 および ユーザー権限の管理

説明

RDS_SUPERUSER 権限を持つアカウントも使用できます。 このタイプのアカウントを作成する方法の詳細については、「ユーザー権限の管理」をご参照ください。

操作手順

  1. 次のいずれかの方法で、ターゲットリージョンの移行タスクリストページに移動します。

    DTS コンソールから

    1. Data Transmission Service (DTS) コンソールにログインします。

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

    3. ページの左上隅で、移行インスタンスが配置されているリージョンを選択します。

    DMS コンソールから

    説明

    実際の操作は、DMS コンソールのモードとレイアウトによって異なる場合があります。 詳細については、「シンプルモードコンソール」および「DMS コンソールのレイアウトとスタイルをカスタマイズ」をご参照ください。

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

    2. 上部メニューバーで、[Data + AI] > [Data Transmission (DTS)] > [Data Migration] を選択します。

    3. データ移行タスク」の右側で、移行インスタンスが配置されているリージョンを選択します。

  2. データ移行タスク」の右側で、移行インスタンスが配置されているリージョンを選択します。

  3. ソースデータベースとターゲットデータベースを設定します。

    カテゴリ

    構成

    説明

    なし

    タスク名

    DTS は自動的にタスク名を生成します。 簡単に識別できるように、わかりやすい名前を指定することを推奨します。 名前は一意である必要はありません。

    移行元データベース

    既存の接続情報の選択

    • システムに追加された (作成または保存された) データベースインスタンスを使用するには、ドロップダウンリストから目的のデータベースインスタンスを選択します。 以下のデータベース情報が自動的に設定されます。

      説明

      DMSコンソールでは、このパラメーターの名前は DMS データベースインスタンスの選択 です。

    • データベースインスタンスをシステムに登録していない場合、または登録済みのインスタンスを使用する必要がない場合は、以下のデータベース情報を手動で設定します。

    データベースタイプ

    PolarDB for PostgreSQL を選択します。

    アクセス方法

    Alibaba Cloud インスタンス を選択します。

    インスタンスのリージョン

    ソースの PolarDB for PostgreSQL クラスターが存在するリージョンを選択します。

    Alibaba Cloud アカウント間でデータを複製

    本トピックでは、同じ Alibaba Cloud アカウント内でデータを移行する方法について説明します。× を選択します。

    インスタンス ID

    ソースの PolarDB for PostgreSQL クラスターの ID を選択します。

    データベース名

    ソースの PolarDB for PostgreSQL クラスターで移行するオブジェクトを含むデータベースの名前を入力します。

    データベースアカウント

    ソースの PolarDB for PostgreSQL クラスターのデータベースアカウントを入力します。 必要な権限については、「データベースアカウントの権限」をご参照ください。

    データベースのパスワード

    データベースアカウントのパスワードを入力します。

    移行先データベース

    既存の接続情報の選択

    • システムに追加された (作成または保存された) データベースインスタンスを使用するには、ドロップダウンリストから目的のデータベースインスタンスを選択します。 以下のデータベース情報が自動的に設定されます。

      説明

      DMS コンソールでは、このパラメーターは DMS データベースインスタンスの選択 という名前です。

    • データベースインスタンスをシステムに登録していない場合、または登録済みのインスタンスを使用する必要がない場合は、以下のデータベース情報を手動で設定します。

    データベースタイプ

    AnalyticDB for PostgreSQL を選択してください。

    アクセス方法

    Alibaba Cloud インスタンス を選択してください。

    インスタンスのリージョン

    ターゲットの AnalyticDB for PostgreSQL インスタンスが存在するリージョンを選択します。

    インスタンス ID

    ターゲットの AnalyticDB for PostgreSQL インスタンスの ID を選択します。

    データベース名

    ターゲットの AnalyticDB for PostgreSQL インスタンスでデータを受信するために使用されるデータベースの名前を入力します。

    データベースアカウント

    ターゲットの AnalyticDB for PostgreSQL インスタンスのデータベースアカウントを入力します。 必要な権限については、「データベースアカウントの権限」をご参照ください。

    データベースのパスワード

    データベースアカウントのパスワードを入力します。

  4. 構成を完了したら、ページの下部で接続をテストして続行をクリックします。

    説明

    DTS サーバーからのアクセスを許可するために、DTS サーバーの IP アドレスセグメントがソースおよびターゲットデータベースのセキュリティ設定に自動または手動で追加されていることを確認してください。 詳細については、「DTS サーバーの IP アドレスをホワイトリストに追加」をご参照ください。

  5. タスクオブジェクトを設定します。

    1. オブジェクト設定] ページで、移行するオブジェクトを設定します。

      構成

      説明

      移行タイプ

      • 完全移行のみが必要な場合は、スキーマ移行完全データ移行 の両方を選択してください。

      • ダウンタイムなしで移行を実行するには、スキーマ移行完全データ移行、および増分データ移行を選択します。

      説明
      • スキーマ移行」を選択しない場合、データを受信するデータベースおよびテーブルがターゲットデータベースに存在することを確認する必要があります。必要に応じて、「選択中のオブジェクト」ボックス内のオブジェクト名マッピング機能を使用することもできます。

      • 増分データ移行」を選択しない場合、データ整合性を確保するために、データ移行中にソースインスタンスに新しいデータを書き込まないでください。

      同期する DDL および DML 操作

      インスタンスレベルで増分移行の SQL 操作を選択します。 サポートされている操作については、「増分移行でサポートされる SQL 操作」をご参照ください。

      説明

      テーブルレベルで増分移行の SQL 操作を選択するには、選択中のオブジェクト ボックス内の移行オブジェクトを右クリックし、表示されるダイアログボックスで SQL 操作を選択します。

      競合するテーブルの処理モード

      • エラーの事前チェックと報告: ターゲットデータベースに同名のテーブルが存在するかどうかをチェックします。同名のテーブルが存在しない場合、事前チェックに合格します。同名のテーブルが存在する場合、事前チェック中にエラーが報告され、データ移行タスクは開始されません。

        説明

        ターゲットデータベースのテーブルが同じ名前で、簡単に削除または名前変更できない場合は、ターゲットデータベースのテーブルの名前を変更できます。 詳細については、「オブジェクト名マッピング」をご参照ください。

      • エラーを無視して続行: 同名のテーブルのチェックをスキップします。

        警告

        エラーを無視して続行 を選択すると、データ不整合やビジネスリスクが生じる可能性があります。 例:

        • テーブルスキーマが一致し、ターゲットデータベースのレコードがソースデータベースのレコードと同じプライマリキー値を持つ場合:

          • 完全移行中、DTS はターゲットデータベースのレコードを保持します。 ソースデータベースのレコードは移行されません。

          • 増分移行中、DTS はターゲットデータベースのレコードを保持しません。 ソースデータベースのレコードがターゲットデータベースのレコードを上書きします。

        • テーブルスキーマが一致しない場合、データの一部の列のみが移行されるか、移行が失敗する可能性があります。 注意して進めてください。

      ストレージエンジンタイプ

      必要に応じて、送信先テーブルのストレージエンジンの種類を選択します。デフォルト値は [Beam] です。

      説明

      この設定項目は、宛先の AnalyticDB for PostgreSQL インスタンスのカーネル バージョンが v7.0.6.6 以降であり、かつ スキーマ移行移行タイプ で選択した場合にのみ利用できます。

      移行先インスタンスでのオブジェクト名の大文字化

      移行対象オブジェクト(データベース、テーブル、および列など)の名前の大文字小文字の区別ポリシーを、宛先インスタンスで設定できます。デフォルトでは、DTS のデフォルトポリシー が選択されています。また、ソースまたはターゲットデータベースのデフォルトポリシーと一致するように、大文字小文字の区別を維持することもできます。詳細については、「宛先データベースにおけるオブジェクト名の大文字小文字の区別」をご参照ください。

      ソースオブジェクト

      ソースオブジェクト ボックスで移行するオブジェクトをクリックし、Right arrow をクリックして 選択中のオブジェクト ボックスに移動します。

      説明

      移行オブジェクトはテーブルレベルで選択されます。

      選択中のオブジェクト

      • 宛先インスタンスに移行するオブジェクトの名前を変更するには、[選択済みオブジェクト] セクションでそのオブジェクトを右クリックします。詳細については、「個別のテーブル列マッピング」をご参照ください。

      • 一度に複数のオブジェクトの名前を変更するには、[選択したオブジェクト] セクションの右上隅にある [一括編集] をクリックします。詳細については、「一度に複数のオブジェクト名をマッピングする」をご参照ください。

      説明
      • オブジェクト名マッピング機能を使用すると、マッピングされたオブジェクトに依存する他のオブジェクトの移行が失敗する可能性があります。

      • 増分移行の SQL 操作を選択するには、選択中のオブジェクト ボックスで移行オブジェクトを右クリックし、表示されるダイアログボックスで SQL 操作を選択します。

      • データをフィルターするための WHERE 句を設定するには、選択中のオブジェクト ボックスで移行対象のテーブルを右クリックし、表示されるダイアログボックスでフィルター条件を設定します。 詳細については、「フィルター条件を設定する」をご参照ください。

    2. 詳細設定へ」をクリックして、詳細パラメーターを設定します。

      構成

      説明

      タスクのスケジュールに使用する専用クラスターの選択

      デフォルトでは、DTS は共有クラスターでタスクをスケジュールします。 選択する必要はありません。 より安定したタスクが必要な場合は、専用クラスターを購入して DTS 移行タスクを実行できます。

      失敗した接続の再試行時間

      移行タスクが開始された後、ソースまたはターゲットデータベースへの接続が失敗した場合、DTS はエラーを報告し、すぐに接続のリトライを開始します。 デフォルトのリトライ期間は 720 分です。 リトライ時間を 10 分から 1440 分の値にカスタマイズできます。 期間を 30 分以上に設定することを推奨します。 指定された期間内に DTS がソースおよびターゲットデータベースに再接続すると、移行タスクは自動的に再開されます。 そうでない場合、タスクは失敗します。

      説明
      • 同じソースまたはターゲットを共有する複数の DTS インスタンスの場合、ネットワークリトライ時間は最後に作成されたタスクの設定によって決まります。

      • 接続リトライ期間中はタスクに課金されるため、ビジネスニーズに基づいてリトライ時間をカスタマイズするか、ソースおよびターゲットデータベースインスタンスがリリースされた後できるだけ早く DTS インスタンスをリリースすることを推奨します。

      移行元データベースと移行先データベースで他の問題が発生した場合の、再試行までの待機時間です。

      移行タスクが開始された後、DDL または DML の実行例外など、接続以外の問題がソースまたはターゲットデータベースで発生した場合、DTS はエラーを報告し、すぐに操作のリトライを開始します。 デフォルトのリトライ期間は 10 分です。 リトライ時間を 1 分から 1440 分の値にカスタマイズできます。 期間を 10 分以上に設定することを推奨します。 指定されたリトライ期間内に関連する操作が成功すると、移行タスクは自動的に再開されます。 そうでない場合、タスクは失敗します。

      重要

      移行元データベースと移行先データベースで他の問題が発生した場合の、再試行までの待機時間です。 の値は、失敗した接続の再試行時間 の値より小さくする必要があります。

      完全移行率を制限するかどうか

      完全移行中、DTS はソースデータベースおよびターゲットデータベースの読み取りおよび書き込みリソースを消費するため、データベースの負荷が増加する場合があります。必要に応じて、完全移行タスクに対して速度制限を有効化できます。1 秒あたりのソースデータベースのクエリ率 QPS1 秒あたりの完全移行の行数 RPS、および1 秒あたりの完全移行データ量 (MB) BPS を設定して、ターゲットデータベースの負荷を軽減できます。

      説明
      • この設定項目は、完全データ移行移行タイプ に選択した場合にのみ利用可能です。

      • 移行インスタンスの実行後に 完全移行速度を調整することもできます。

      増分移行率を制限するかどうか

      必要に応じて、増分移行タスクの速度制限を設定することもできます。ターゲットデータベースへの負荷を軽減するために、1 秒あたりの増分移行の行数 RPS および 1 秒あたりの増分移行データ量 (MB) BPS を設定できます。

      説明
      • この設定項目は、増分データ移行移行タイプ で選択した場合にのみ利用できます。

      • 移行インスタンスの実行後に 増分移行速度を調整することもできます。

      環境タグ

      必要に応じて、インスタンスを識別するための環境タグを選択できます。 この例ではタグを選択する必要はありません。

      ETL 機能の設定

      抽出、変換、書き出し (ETL) 機能を有効にするかどうかを選択します。 詳細については、「ETL とは」をご参照ください。 有効な値:

      監視アラート

      ビジネスニーズに基づいて、アラートを設定し、アラート通知を受信するかどうかを選択します。

      • ×: アラートを設定しません。

      • : アラートしきい値アラート通知を設定して、アラートを設定します。移行が失敗した場合や遅延時間がしきい値を超えた場合、システムがアラート通知を送信します。

    3. [次: データ検証] をクリックして、データ検証タスクを設定します。

      データ検証機能の詳細については、「データ検証の設定」をご参照ください。

    4. 任意: 前述の構成を完了したら、次:データベースおよびテーブルのフィールド設定 をクリックして、AnalyticDB for PostgreSQL インスタンスの宛先テーブルの タイププライマリキー列の追加、および 配布キー を設定します。

      説明
      • このステップは、タスクオブジェクトを設定する際に、スキーマ移行移行タイプ として選択した場合にのみ利用できます。 定義ステータスすべて に設定してから変更を加えることができます。

      • 複数の列を選択して、プライマリキー列の追加の複合プライマリキーを構成できます。プライマリキー列の追加から1つ以上の列を配布キーとして選択する必要があります。詳細については、「データテーブルの管理」および「テーブルのディストリビューションの定義」をご参照ください。

  6. タスクを保存して事前チェックを実行します。

    • このインスタンスを構成するためのパラメーターを API 操作呼び出し時に表示するには、次:タスク設定の保存と事前チェック ボタンにポインターを移動させ、表示される吹き出し内の OpenAPI パラメーターのプレビュー をクリックします。

    • API パラメーターを表示する必要がない場合、または表示を完了した場合は、ページの下部で 次:タスク設定の保存と事前チェック をクリックします。

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

    • 事前チェックが失敗した場合は、失敗したチェック項目の横にある詳細を表示 をクリックしてプロンプトに基づき問題を修正し、再度事前チェックを実行してください。

    • 事前チェック中に警告が報告された場合:

      • 無視できないチェック項目については、失敗した項目の横にある詳細を表示をクリックし、表示されたメッセージに従って問題を修正した後、事前チェックを再度実行してください。

      • 無視できるチェック項目については、アラートの詳細を確認無視OK、および 再度事前チェックを実行 をクリックして、アラート項目をスキップし、事前チェックを再実行できます。 警告を無視すると、データ不整合などの問題が発生し、お客様のビジネスにリスクをもたらす可能性があります。

  7. インスタンスを購入します。

    1. 成功率」が 100% の場合、「次:インスタンスの購入」をクリックします。

    2. 購入」ページで、データ移行インスタンスのリンク仕様を選択します。詳細については、以下の表をご参照ください。

      カテゴリ

      パラメーター

      説明

      新しいインスタンスクラス

      リソースグループの設定

      インスタンスが属するリソースグループを選択します。 デフォルト値はデフォルトリソースグループです。 詳細については、「Resource Management とは」をご参照ください。

      インスタンスクラス

      DTS は、さまざまなパフォーマンスレベルの移行仕様を提供します。 リンク仕様は移行速度に影響します。 ビジネスシナリオに基づいて仕様を選択できます。 詳細については、「データ移行リンクの仕様」をご参照ください。

    3. 構成が完了したら、Data Transmission Service (従量課金) 利用規約 をお読みいただき、選択します。

    4. [購入して開始] をクリックします。表示される [OK] ダイアログボックスで、[OK] をクリックします。

      移行タスクの進捗状況は、データ移行タスク リストページで確認できます。

      説明
      • 移行タスクに増分移行が含まれていない場合、完全移行が完了すると自動的に停止します。タスクが停止すると、そのステータス完了に変化します。

      • 移行タスクに増分移行が含まれる場合、タスクは自動的に停止しません。増分移行タスクは引き続き実行されます。増分移行タスクが実行中の間、タスクのステータス実行中です。