すべてのプロダクト
Search

このプロダクト

    Data Transmission Service:RDS for PostgreSQL から RDS for MySQL への移行

    ドキュメントセンター

    Data Transmission Service:RDS for PostgreSQL から RDS for MySQL への移行

    最終更新日:Jul 11, 2026

    Data Transmission Service (DTS) を使用して、ApsaraDB RDS for PostgreSQL インスタンスから ApsaraDB RDS for MySQL インスタンスへデータを移行します。DTS は完全データ移行と増分データ移行の両方をサポートしており、ゼロダウンタイムでのデータベース移行が可能です。

    ソースデータベースとターゲットデータベース

    DTS は、以下のシナリオで PostgreSQL から MySQL への移行をサポートしています。このトピックでは、ApsaraDB RDS for PostgreSQL インスタンスから ApsaraDB RDS for MySQL インスタンスへの移行を例として説明します。

    • ApsaraDB RDS for PostgreSQL インスタンスから ApsaraDB RDS for MySQL インスタンスへのデータ移行

    • セルフマネージド PostgreSQL データベースからセルフマネージド MySQL データベースへのデータ移行

    前提条件

    制限事項

    説明

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

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

    タイプ

    説明

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

    • ソースデータベースをホストするサーバーには、十分なアウトバウンド帯域幅が必要です。 帯域幅が不十分な場合、移行速度に影響する可能性があります。

    • 移行する各テーブルには、プライマリキーまたは一意制約が必要です。 移行先データベースでのデータ重複を防ぐため、キーまたは制約のすべてのフィールドは一意である必要があります。

    • テーブルレベルでオブジェクトを移行し、列名のマッピングなどの編集を実行する必要がある場合、単一の移行タスクでサポートされるテーブルは最大 1,000 です。 この制限を超えると、タスクの送信時にエラーが報告されます。 この場合、テーブルを複数のタスクに分割するか、データベース全体を移行するようにタスクを設定できます。

    • 増分データ移行では、先行書き込みログ (WAL) を設定する必要があります：

      • WAL 機能を有効にする必要があります。

      • 増分データ移行のみのタスクでは、Data Transmission Service (DTS) では、ソースデータベースの WAL ログを 24 時間以上保持する必要があります。 全量データ移行と増分データ移行の両方を含むタスクでは、DTS ではログを 7 日間以上保持する必要があります。 全量データ移行が完了した後、保持期間を 24 時間以上に戻すことができます。 保持期間が短すぎると、DTS が必要な WAL ログを取得できず、タスクが失敗したり、データ不整合やデータ損失につながったりする可能性があります。 要件より短い WAL 保持期間が原因で発生した問題は、DTS のサービスレベルアグリーメント (SLA) の対象外です。

    • ソースデータベースでの操作上の制限事項：

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

      • 全量データ移行のみを実行する場合は、データ不整合を避けるために、ソースインスタンスに新しいデータを書き込まないでください。 リアルタイムのデータ整合性を維持するためには、スキーマ移行、全量データ移行、増分データ移行を選択することを推奨します。

      • 移行タスクがスムーズに実行され、プライマリ/セカンダリ切り替えによる論理サブスクリプションの中断を防ぐために、ソースの PolarDB for PostgreSQL (Compatible with Oracle) クラスターで 論理レプリケーションスロットのフェイルオーバーをサポートし、有効にしておく必要があります。

        説明

        ソースの PolarDB for PostgreSQL (Compatible with Oracle) クラスターが論理レプリケーションスロットのフェイルオーバーをサポートしていない場合 (たとえば、クラスターの データベースエンジン が Oracle 構文互換 2.0 の場合)、ソースデータベースでの高可用性 (HA) 切り替えにより、移行インスタンスが失敗し、回復できなくなる可能性があります。

      • 論理サブスクリプションの制限により、増分データ移行を含む移行インスタンスが実行中で、増分変更後に移行される単一行のサイズが 256 MB を超えると、移行インスタンスは回復不能なエラーで失敗するため、再設定する必要があります。

    • 増分データ移行中にソースデータベースに長時間実行されるトランザクションが存在する場合、これらのトランザクションがコミットされる前に生成された先行書き込みログ (WAL) レコードはクリアできません。 これにより、WAL ファイルが蓄積され、ソースデータベースのディスク容量を使い果たす可能性があります。

    その他の制限事項

    • 単一のデータ移行タスクで移行できるデータベースは 1 つだけです。 複数のデータベースを移行するには、それぞれに個別の移行タスクを設定する必要があります。

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

    • これらのテーブルは、タスクを設定する際にコンソールに表示されません。

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

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

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

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

      説明

      • コマンド内の schema と table は、移行するデータのスキーマ名とテーブル名に置き換えてください。

      • この操作はオフピーク時に実行してください。

    • DTS は、増分データの DDL ステートメント、増分テーブルの構造、ハートビートなどの情報を取得するために、ソースデータベースに次の仮テーブルを作成します。 移行中にこれらの仮テーブルを削除しないでください。削除するとタスクが失敗します。 テーブルは、DTS インスタンスが解放された後に自動的に削除されます。

      public.dts_pg_class、public.dts_pg_attribute、public.dts_pg_type、public.dts_pg_enum、public.dts_postgres_heartbeat、public.dts_ddl_command、public.dts_args_session、および public.aliyun_dts_instance。

    • 増分データ移行のレイテンシメトリックの正確性を確保するために、DTS はソースデータベースに dts_postgres_heartbeat という名前のハートビートテーブルを作成します。

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

      説明

      • 移行中にタスクで使用されるソースデータベースアカウントのパスワードを変更した場合、またはソースデータベースの IP アドレスホワイトリストから DTS の IP アドレスを削除した場合、レプリケーションスロットは自動的にクリーンアップされません。 この場合、ログの蓄積を防ぐために、ソースデータベースでレプリケーションスロットを手動でクリーンアップする必要があります。ログが蓄積されるとディスク容量が枯渇し、ソースデータベースが利用できなくなる可能性があります。

      • ソースデータベースでプライマリ/セカンダリ切り替えが発生した場合は、セカンダリデータベースにログインして手動でレプリケーションスロットをクリーンアップする必要があります。

    • 移行を開始する前に、ソースと移行先の両方のデータベースのパフォーマンスを評価してください。 移行はピーク時を避けて実行することを推奨します。 全量データ移行中、DTS は両方のデータベースで読み取りおよび書き込みリソースを消費するため、負荷が増加する可能性があります。

    • 全量データ移行中の同時 INSERT 操作によってテーブルの断片化が起こり、結果として移行先データベースがソースインスタンスよりも多くのストレージ容量を使用する場合があります。

    • FLOAT または DOUBLE データ型の列の移行精度がビジネス要件を満たしていることを確認してください。 DTS は ROUND(COLUMN,PRECISION) 関数を使用してこれらの列から値を読み取ります。 精度が明示的に定義されていない場合、DTS は FLOAT には 38、DOUBLE には 308 の精度を使用します。

    • DTS は、失敗した移行タスクを最大 7 日間再開しようとします。 ビジネスワークロードを移行先インスタンスに切り替える前に、タスクを終了または解放するか、revoke コマンドを使用して DTS が移行先インスタンスにアクセスするために使用するアカウントの書き込み権限を取り消す必要があります。 これにより、自動的に再開されたタスクが移行先インスタンスのデータを上書きするのを防ぎます。

    • DTS の検証ではデータ内容をチェックしますが、シーケンスなどのオブジェクトのメタデータ検証はサポートしていません。 これらのオブジェクトは手動で検証する必要があります。

    • ワークロードを移行先インスタンスに切り替えた後、新たに書き込まれるシーケンスは、ソースデータベースの対応するシーケンスの最大値からインクリメントされません。 ワークロードを切り替える前に、移行先データベースのシーケンス値を更新する必要があります。 詳細については、「移行先データベースのシーケンス値を更新する」をご参照ください。

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

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

      説明

      変更されるのは DTS タスクのパラメーターのみであり、データベースのパラメーターは変更されません。調整される可能性のあるパラメーターは、「インスタンスパラメーターの変更」に記載されています。

    • パーティションテーブルを移行する場合、データ不整合を防ぐために、親テーブルとそのすべての子パーティションを移行オブジェクトとして含める必要があります。

      重要

      • PolarDB for PostgreSQL (Compatible with Oracle) では、パーティションテーブルの親テーブルはデータを直接保存しません。 データは子パーティションに保存されます。 移行タスクには、データ損失やソースデータベースと移行先データベース間の不整合を防ぐために、親テーブルとそのすべての子パーティションを含める必要があります。

      • 異なるデータベースに分散しているパーティションテーブルまたは継承テーブル (親テーブルと子テーブル) の移行はサポートしていません。 パーティションテーブルとそのすべてのパーティション、および親テーブルとそのすべての子テーブルが同じデータベースにあることを確認してください。

    料金

    移行タイプ

    リンク構成料金

    パブリックネットワークトラフィック料金

    構造移行および全量データ移行

    料金は発生しません。

    パブリックネットワーク経由で Alibaba Cloud から移行されるデータには料金がかかります。詳細については、「課金概要」をご参照ください。

    増分データ移行

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

    移行タイプ

    • スキーマ移行

      Data Transmission Service (DTS) は、移行オブジェクトのスキーマ定義をソースデータベースからターゲットデータベースに移行します。

      • DTS は、テーブル、ビュー、トリガー、ストアドプロシージャ、および関数のスキーマ移行をサポートしています。

        説明

        ストアドプロシージャの routine_body、関数の routine_body、およびビューの select_statement は変更されません。

      • スキーマ移行中、DTS は移行対象のビュー、ストアドプロシージャ、および関数の DEFINER を INVOKER に変更します。この操作により、SQL SECURITY の値が INVOKER に変更されます。また、DTS は DEFINER を移行タスク用のターゲットデータベースアカウントに設定します。

        説明

        ソースデータベースのセキュリティ認証方法および DEFINER は変更されません。

      • DTS はユーザー情報を移行しないため、ターゲットデータベースでビュー、ストアドプロシージャ、および関数を呼び出すには、呼び出し元に読み取りおよび書き込み権限を付与する必要があります。

    • 完全移行

      DTS は、指定された移行オブジェクトのすべての既存データをソースデータベースからターゲットデータベースに移行します。

    • 増分移行

      完全移行が完了した後、DTS はソースデータベースからターゲットデータベースに増分データを移行します。増分移行により、セルフマネージドアプリケーションを中断することなく、円滑にデータを移行できます。

    増分移行の SQL 操作

    操作タイプ

    SQL ステートメント

    DML

    INSERT、UPDATE、DELETE

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

    データベース

    完全データ移行

    増分データ移行

    アクション

    ApsaraDB RDS for PostgreSQL インスタンス

    移行対象オブジェクトの SELECT 権限。

    選択したデータベースを所有する特権アカウント。

    説明

    ApsaraDB RDS for PostgreSQL 9.4 ソースインスタンスからの増分 DML 移行では、REPLICATION 権限のみが必要です。

    アカウントを作成し、データベースを作成します。

    ApsaraDB RDS for MySQL インスタンス

    読み取りおよび書き込み権限

    アカウントを作成し、アカウント権限を変更します。

    手順

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

      DTS コンソールから

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

      2. 左側メニューで、 データの移行 をクリックします。

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

      DMS コンソールから

      説明

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

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

      2. 上部メニューで、[データ + AI] > [Data Transmission (DTS)] > [データ移行] の順に選択します。

      3. データ移行タスク の右側で、移行インスタンスがあるリージョンを選択します。

    2. タスクの作成 をクリックし、タスク設定ページに移動します。

    3. オプション：ページの右上隅にある 新バージョンの設定ページを試してみる をクリックします。

      説明

      • すでに新しい設定ページが表示されている場合 (右上隅のボタンが 旧バージョンの設定ページに戻る の場合)、この手順はスキップできます。

      • 新旧の設定ページではパラメーターが異なります。新しい設定ページを使用することを推奨します。

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

      警告

      ソースインスタンスとターゲットインスタンスを選択したら、ページ上部の 制限事項 を読み、移行タスクが問題なく作成および実行できることを確認してください。

      カテゴリ

      パラメーター

      説明

      N/A

      [タスク名]

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

      [ソースデータベース]

      [データベースタイプ]

      PostgreSQL を選択します。

      [接続タイプ]

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

      [インスタンスリージョン]

      ソースの ApsaraDB RDS for PostgreSQL インスタンスのリージョンを選択します。

      [インスタンス ID]

      ソースの ApsaraDB RDS for PostgreSQL インスタンスのインスタンス ID を選択します。

      [データベース名]

      移行対象のオブジェクトが含まれる、ソースの ApsaraDB RDS for PostgreSQL インスタンスのデータベース名を入力します。

      [データベースアカウント]

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

      [データベースパスワード]

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

      [暗号化]

      接続方法を選択します。この例では、 非暗号化 が選択されています。

      SSL 暗号化を使用してデータベースに接続する必要がある場合は、 SSL 暗号化 を選択し、必要に応じて CA 証明書、クライアント証明書、クライアント証明書の秘密鍵 をアップロードします。次に、クライアント証明書の秘密鍵のパスワード を入力します。

      説明

      • 自己管理 PostgreSQL データベースで SSL 暗号化 を選択した場合は、 CA 証明書 をアップロードする必要があります。

      • クライアント証明書を使用する必要がある場合は、 クライアント証明書 と クライアント証明書の秘密鍵 の両方をアップロードし、 クライアント証明書の秘密鍵のパスワード を入力する必要があります。

      • RDS for PostgreSQL インスタンスの SSL 暗号化機能については、「SSL接続の暗号化」をご参照ください。

      [ターゲットデータベース]

      [データベースタイプ]

      MySQL を選択します。

      [接続タイプ]

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

      [インスタンスリージョン]

      ターゲットの ApsaraDB RDS for MySQL インスタンスのリージョンを選択します。

      [RDS インスタンス ID]

      ターゲットの ApsaraDB RDS for MySQL インスタンスのインスタンス ID を選択します。

      [データベースアカウント]

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

      [データベースパスワード]

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

      [接続方法]

      データベースの要件に基づいて、 非暗号化 または SSL 暗号化 を選択します。このパラメーターを SSL 暗号化 に設定する場合は、事前に RDS for MySQL インスタンスで SSL 暗号化を有効にする必要があります。詳細については、「クラウド証明書を使用してSSL暗号化を迅速に有効にする」をご参照ください。

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

      説明

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

      • ソースまたはターゲットデータベースが自己管理データベースの場合 (アクセス方法 が Alibaba Cloud インスタンス ではない場合)、接続テスト ダイアログボックスで DTS サーバーの CIDR ブロック をクリックする必要もあります。

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

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

        パラメーター

        説明

        • 完全データ移行のみを実行する必要がある場合は、 スキーマ移行 と 完全データ移行 の両方を選択します。

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

        説明

        • スキーマ移行 を選択しない場合は、ターゲットデータベースにデータを受け取るためのデータベースとテーブルが存在することを確認する必要があります。選択中のオブジェクト ボックスでオブジェクト名マッピング機能を使用することもできます。

        • 増分データ移行 を選択しない場合は、データ移行中にソースインスタンスに新しいデータを書き込まないでください。

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

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

          説明

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

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

          警告

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

          • テーブルスキーマが一貫しており、ターゲットデータベースのレコードの主キー値がソースデータベースのレコードと同じ場合：

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

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

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

        [ソースオブジェクト]

        ソースオブジェクト ペインで、移行するオブジェクトを選択し、向右小箭头 をクリックして 選択中のオブジェクト ペインに移動します。

        説明

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

        [選択中のオブジェクト]

        説明

        • オブジェクト名のマッピングにより、依存オブジェクトの移行が失敗する可能性があります。

        • WHERE 句でデータをフィルタリングするには、選択中のオブジェクト セクションでテーブルを右クリックし、フィルタリング条件を指定します。「フィルタリング条件の設定」をご参照ください。

        • データベースまたはテーブルレベルで移行する SQL 操作を選択するには、選択中のオブジェクト セクションで移行オブジェクトを右クリックし、操作を選択します。

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

        パラメーター

        説明

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

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

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

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

        説明

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

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

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

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

        重要

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

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

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

        説明

        • この設定項目は、完全データ移行 を 移行タイプ で選択した場合にのみ設定できます。

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

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

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

        説明

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

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

        [環境タグ]

        オプション。インスタンスを識別するために環境タグを選択します。

        [ETL 機能の設定]

        ビジネスニーズに基づいて、ETL 機能を設定してデータを処理するかどうかを選択します。

        [監視アラート]

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

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

        • ○：アラートしきい値とアラート通知を設定してアラートを設定します。移行が失敗した場合やレイテンシがしきい値を超えた場合に、システムはアラート通知を送信します。

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

        データ検証機能を使用する場合、設定方法については「データ検証の設定」をご参照ください。

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

      • API 操作を呼び出してこのインスタンスを設定する際のパラメーターを表示するには、次：タスク設定の保存と事前チェック ボタンの上にポインターを移動し、表示されるバブルで OpenAPI パラメーターのプレビュー をクリックします。

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

      説明

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

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

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

        • 無視できないチェック項目の場合は、失敗した項目の横にある 詳細を表示 をクリックし、プロンプトに基づいて問題を修正してから、事前チェックを再度実行します。

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

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

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

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

        カテゴリ

        パラメーター

        説明

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

        [リソースグループの設定]

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

        [インスタンスクラス]

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

      3. 設定が完了したら、Data Transmission Service (従量課金) 利用規約 を読み、チェックボックスを選択します。

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

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

        説明

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

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