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

Data Transmission Service:PolarDB for PostgreSQL クラスター間のデータ移行

最終更新日:Mar 06, 2026

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

前提条件

  • 移行先の PolarDB for PostgreSQL クラスターを作成済みである必要があります。移行先クラスターのストレージ領域は、移行元の PolarDB for PostgreSQL クラスターのストレージ領域より大きい必要があります。詳細については、「データベースクラスターの作成」をご参照ください。

  • 移行元の PolarDB for PostgreSQL クラスターの wal_level パラメーターを logical に設定済みである必要があります。詳細については、「クラスターのパラメーター設定」をご参照ください。

  • 移行先の PolarDB for PostgreSQL クラスターに、移行データを受信するためのデータベースを作成済みである必要があります。詳細については、「データベース管理」をご参照ください。

注意事項

説明

種別

説明

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

  • PolarDB for PostgreSQL クラスターでは、移行対象のテーブルにプライマリキーまたは NULL を許容しない一意なインデックスが存在する必要があります。

  • ソースデータベースに長時間トランザクションが存在し、かつインスタンスに増分移行タスクが実行中の場合、長時間トランザクションのコミット前に生成されたウォールアヘッドログ (WAL) が蓄積される可能性があります。これにより、ソースデータベースのディスク領域が不足するおそれがあります。

  • 移行タスクが正常に実行されることを保証し、プライマリ/セカンダリ間のスイッチオーバーによって論理レプリケーションが中断されないよう、PolarDB for PostgreSQL クラスターは「論理レプリケーションスロットのフェールオーバー」をサポートおよび有効化する必要があります。

    説明

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

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

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

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

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

その他の制限事項

  • 単一のデータ移行タスクでは、1 つのデータベースのみを移行できます。複数のデータベースを移行するには、各データベースごとに個別のデータ移行タスクを設定してください。

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

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

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

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

    • 移行対象がスキーマであり、そのスキーマ内に新しいテーブルが作成された場合、または既存のテーブルが RENAME コマンドで再構築された場合。

    説明
    • コマンド内の schema および table は、実際のスキーマ名およびテーブル名に置き換えてください。

    • この操作は、業務負荷の低い時間帯に実行することを推奨します。

  • 移行対象のテーブルに SERIAL 型のフィールドが含まれる場合、ソースデータベースは自動的にそのフィールド用の Sequence を作成します。そのため、ソースオブジェクト を設定する際に、スキーマ移行移行タイプ として選択する場合は、Sequence も選択するか、スキーマ全体を移行することを推奨します。そうでない場合、移行インスタンスが失敗する可能性があります。

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

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

  • DTS はデータ内容の検証を行いますが、Sequence などのメタデータの検証はサポートしていません。メタデータの検証は、お客様自身で実施する必要があります。

  • 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 アドレスを削除したりした場合、レプリケーションスロットが自動的にクリーンアップされません。この場合、ソースデータベースで手動でレプリケーションスロットをクリーンアップする必要があります。これにより、スロットが継続的に蓄積してディスク領域を消費し、ソースデータベースが利用不能になるのを防ぎます。

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

  • サービスをターゲットデータベースに切り替えた後、新規の Sequence はソースデータベースの最大 Sequence 値からインクリメントを開始しません。切り替え前に、ターゲットデータベースの Sequence 値を更新する必要があります。詳細については、「ターゲットデータベースの Sequence 値の更新」をご参照ください。

  • 完全移行または増分移行タスクにおいて、ソースデータベースの移行対象テーブルに外部キー、トリガー、またはイベントトリガーが含まれる場合、ターゲットデータベースのアカウントが特権アカウントまたはスーパーユーザ権限を持っている場合は、DTS がセッションレベルで一時的に session_replication_role パラメーターを replica に設定します。ターゲットデータベースのアカウントがこれらの権限を持っていない場合は、ターゲットデータベースで手動で session_replication_role パラメーターを replica に設定する必要があります。この期間中(session_replication_role が replica の状態)に、ソースデータベースでカスケード更新または削除操作が発生した場合、データ不整合が発生する可能性があります。DTS 移行タスクがリリースされた後、session_replication_role パラメーターを origin に戻すことができます。

  • タスクが失敗した場合、DTS サポートスタッフが 8 時間以内に復旧を試みます。復旧中、タスクを再起動したり、パラメーターを調整したりすることがあります。

    説明

    DTS タスクのパラメーターのみが変更され、データベースのパラメーターは変更されません。 調整される可能性のあるパラメーターについては、「インスタンスパラメーターの変更」をご参照ください。

  • パーティションテーブルを移行する場合、親テーブルとその子テーブルの両方を同期対象として含める必要があります。そうでない場合、パーティションテーブルでデータ不整合が発生する可能性があります。

    説明

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

課金

移行タイプ

リンク構成料金

データ転送コスト

スキーマ移行および完全なデータ移行

無料です。

この例は無料です。

増分データ移行

有料機能です。詳細については、「課金概要」をご参照ください。

サポートされる移行対象

SCHEMA、TABLE

説明
  • これは、PRIMARY KEY、UNIQUE KEY、FOREIGN KEY、DATATYPE(組み込みデータ型)、DEFAULT CONSTRAINT を含みます。

  • このデータベースタイプをソースとして使用した場合のサポート機能は、ターゲットデータベースタイプによって異なります。コンソールページに表示される機能が優先されます。

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

操作タイプ

SQL 文

DML

INSERT、UPDATE、DELETE

DDL

  • DDL 移行は、2020 年 10 月 1 日以降に作成されたデータ移行タスクでのみサポートされています。

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

    • 増分移行では BIT データ型はサポートされていません。

  • DDL 移行には、ソースデータベースの特権アカウントが必要です。サポートされる 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 文はサポートされていません。

    • 関数呼び出しによって実行された DDL 文はサポートされていません。

    • 単一のトランザクションに DML 文と DDL 文の両方が含まれている場合、DDL 文は移行されません。

    • 単一のトランザクションに移行対象外のオブジェクトに対する DDL 文が含まれている場合、その DDL 文は移行されません。

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

データベース

必要な権限

作成および権限付与方法

ソース:PolarDB for PostgreSQL

特権アカウント

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

ターゲット:PolarDB for PostgreSQL

操作手順

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

    DTS コンソールから

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

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

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

    DMS コンソールから

    説明

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

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

    2. トップメニューバーで、Data + AI > Data Transmission (DTS) > データ移行 を選択します。

    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 データベースインスタンスの選択 です。

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

    データベースタイプ

    PolarDB for PostgreSQL を選択します。

    アクセス方法

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

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

    ターゲットの PolarDB for PostgreSQL クラスターが配置されているリージョンを選択します。

    インスタンス ID

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

    データベース名

    データを受信するターゲットの PolarDB for PostgreSQL クラスター内のデータベース名を入力します。

    データベースアカウント

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

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

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

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

    説明

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

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

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

      設定

      説明

      移行タイプ

      • 完全移行のみを実行する場合は、スキーマ移行 および 完全データ移行 の両方を選択します。

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

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

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

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

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

        説明

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

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

        警告

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

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

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

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

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

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

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

      ソースオブジェクト

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

      説明
      • スキーマレベルまたはテーブルレベルで移行対象のオブジェクトを選択できます。テーブルを移行対象として選択した場合、ビュー、トリガー、ストアドプロシージャなどの他のオブジェクトはターゲットデータベースに移行されません。

      • 移行対象のテーブルに SERIAL フィールドが含まれており、スキーマ移行移行タイプ として選択する場合、Sequence も選択するか、スキーマ全体を移行することを推奨します。

      選択中のオブジェクト

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

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

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

      • 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. 次へ:データ検証 をクリックして、データ検証タスクを設定します。

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

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

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

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

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

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

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

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

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

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

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

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

      カテゴリ

      パラメーター

      説明

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

      リソースグループの設定

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

      インスタンスクラス

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

    3. 設定が完了したら、Data Transmission Service (従量課金) 利用規約 を読み、同意してください。

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

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

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

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