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

Data Transmission Service:PolarDB for PostgreSQL (Oracle 互換) クラスターから AnalyticDB for MySQL 3.0 クラスターへのデータ移行

最終更新日:Jan 18, 2026

Data Transmission Service (DTS) を使用して、PolarDB for PostgreSQL (Oracle 互換) クラスターから AnalyticDB for MySQL 3.0 クラスターにデータを移行できます。

前提条件

  • ターゲットの AnalyticDB for MySQL V3.0 クラスターが作成されていること。詳細については、「クラスターの作成」をご参照ください。

  • ソースの PolarDB for PostgreSQL (Oracle 互換) クラスターで、wal_level パラメーターが logical に設定されていること。これにより、論理レプリケーションに必要な情報が先行書き込みログ (WAL) に追加されます。詳細については、「クラスターパラメーターの設定」をご参照ください。

注意事項

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

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

タイプ

説明

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

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

  • 移行対象のテーブルには、プライマリキーまたは一意制約が必要です。キーまたは制約のフィールドには一意の値が必要です。そうでない場合、ターゲットデータベースに重複データが出現する可能性があります。

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

  • 増分移行の場合、先行書き込みログ (wal) を有効にする必要があります。

    • これは有効にする必要があります。

    • 増分移行タスクの場合、DTS はソースデータベースの wal ログを 24 時間以上保持することを要求します。完全移行と増分移行の両方を含むタスクの場合、DTS はソースデータベースの wal ログを少なくとも 7 日間保持することを要求します。完全移行が完了した後、ログの保持期間を 24 時間以上に設定できます。そうでない場合、DTS が wal ログを取得できないため、DTS タスクが失敗する可能性があります。極端なケースでは、データの不整合やデータ損失が発生する可能性があります。wal ログの保持期間が必要な期間より短いことに起因する問題は、DTS のサービスレベルアグリーメント (SLA) の対象外です。

  • ソースデータベースの操作制限:

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

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

    • 移行タスクが正常に実行され、プライマリ/セカンダリのスイッチオーバーによる論理サブスクリプションの中断を防ぐために、ご利用の PolarDB for PostgreSQL (Oracle 互換) インスタンスは、論理レプリケーションスロットのフェールオーバーをサポートし、有効にしている必要があります。詳細については、「論理レプリケーションスロットのフェールオーバーを有効にする」をご参照ください。

      説明

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

    • ソースデータベースの論理レプリケーションの制限により、移行中に移行対象の単一の増分データが 256 MB を超えると、DTS インスタンスが失敗し、回復できなくなる可能性があります。DTS インスタンスを再構成する必要があります。

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

その他の制限事項

  • 単一のデータ移行タスクでは、1 つのデータベースのみを移行できます。複数のデータベースを移行するには、各データベースに対してデータ移行タスクを構成してください。

  • ターゲットデータベースにカスタムプライマリキーを設定するか、テーブル・列設定 ステップで プライマリキー列の追加 を設定する必要があります。そうしないと、データ移行が失敗する可能性があります。

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

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

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

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

    説明
    • コマンドで、schematable を移行するデータのスキーマ名とテーブル名に置き換えてください。

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

  • 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_postgres_heartbeat という名前のハートビートテーブルを追加します。

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

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

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

  • AnalyticDB for MySQL 3.0 の制限により、AnalyticDB for MySQL 3.0 クラスター内のノードのディスク領域使用率が 80% を超えると、DTS タスクは異常になり、遅延が発生します。移行対象のオブジェクトに基づいて必要な領域を見積もり、ターゲットクラスターに十分なストレージ領域があることを確認してください。

  • DTS タスクの実行中にターゲットの AnalyticDB for MySQL 3.0 クラスターがバックアップされている場合、タスクは失敗します。

  • データを移行する前に、ソースデータベースとターゲットデータベースのパフォーマンスを評価してください。また、オフピーク時にデータを移行することを推奨します。そうでない場合、DTS は完全データ移行中にソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを消費し、データベースの負荷が増加する可能性があります。

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

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

  • DDL 文がターゲットデータベースに書き込めなかった場合、DTS タスクは実行を継続します。失敗した DDL 文はタスクログで確認できます。詳細については、「タスクログの照会」をご参照ください。

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

    説明

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

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

    説明

    PolarDB for PostgreSQL (Oracle 互換) のパーティションテーブルの親テーブルは、直接データを保存しません。すべてのデータは子パーティションに保存されます。同期タスクには、親テーブルとそのすべての子パーティションの両方を含める必要があります。そうでない場合、子パーティションのデータが欠落し、ソースとターゲットの間でデータの不整合が発生する可能性があります。

課金

移行タイプ

インスタンス構成料金

インターネットトラフィック料金

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

無料。

ターゲットデータベースのアクセス方法 パラメーターが パブリック IP アドレス に設定されている場合、インターネットトラフィックに対して課金されます。 詳細については、「課金の概要」をご参照ください。

増分データ移行

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

移行タイプ

移行タイプ

スキーマ移行

DTS は、移行オブジェクトのスキーマ定義をターゲットデータベースに移行します。現在、DTS はテーブルのスキーマ移行をサポートしています。

完全データ移行

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

説明

スキーマ移行と完全データ移行が完了するまで、移行オブジェクトに対して DDL 操作を実行しないでください。そうしないと、移行が失敗する可能性があります。

増分データ移行

完全データ移行後、DTS はソースデータベースから REDO ログをポーリングしてキャプチャし、増分データをターゲットデータベースに移行します。

増分データ移行により、アプリケーションを停止することなくデータをスムーズに移行できます。

増分移行可能な SQL 操作

操作タイプ

SQL 操作文

DML

INSERT、UPDATE、DELETE

説明

データがターゲットの AnalyticDB for MySQL クラスターに書き込まれると、UPDATE 文は自動的に REPLACE INTO 文に変換されます。UPDATE 文がプライマリキーに対して実行される場合、UPDATE 文は DELETE 文と INSERT 文に変換されます。

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

データベース

必要な権限

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

PolarDB for PostgreSQL (Oracle 互換) クラスター

特権アカウント。

詳細については、「データベースアカウントの作成」をご参照ください。

AnalyticDB for MySQL V3.0

移行オブジェクトを含むターゲットデータベースに対する読み取りおよび書き込み権限。

詳細については、「データベースアカウントの作成」をご参照ください。

操作手順

  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. ソースデータベースとターゲットデータベースを構成します。

    警告

    ソースインスタンスとターゲットインスタンスを選択した後、ページの上部に表示される制限事項をよくお読みになることを推奨します。そうしないと、タスクが失敗したり、データの不整合が発生したりする可能性があります。

    カテゴリ

    構成

    N/A

    タスク名

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

    ソースデータベース

    データベースタイプ

    PolarDB (Oracle と互換性) を選択します。

    アクセス方法

    クラウドインスタンス を選択します。

    インスタンスリージョン

    ソースの PolarDB for PostgreSQL (Oracle 互換) クラスターが配置されているリージョンを選択します。

    インスタンス ID

    ソースの PolarDB for PostgreSQL (Oracle 互換) クラスターのインスタンス ID を選択します。

    データベース名

    ソースの PolarDB for PostgreSQL (Oracle 互換) クラスター内の移行オブジェクトが属するデータベースの名前を入力します。

    データベースアカウント

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

    データベースパスワード

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

    ターゲットデータベース

    データベースタイプ

    AnalyticDB MySQL 3.0 を選択します。

    アクセス方法

    クラウドインスタンス を選択します。

    インスタンスリージョン

    ターゲットの AnalyticDB for MySQL 3.0 データベースが配置されているリージョンを選択します。

    インスタンス ID

    ターゲットの AnalyticDB for MySQL 3.0 クラスターの ID を選択します。

    データベースアカウント

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

    データベースパスワード

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

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

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

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

  5. タスクオブジェクトを構成します。

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

      構成

      移行タイプ

      要件と各エンジンでサポートされているタイプに基づいて移行タイプを選択します。

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

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

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

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

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

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

        説明

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

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

        警告

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

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

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

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

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

      同期する DDL および DML 操作

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

      説明

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

      テーブルの結合

      • を選択すると、DTS は各テーブルに __dts_data_source 列を追加してデータソースを記録します。詳細については、「複数テーブルのマージを有効にする」をご参照ください。

      • ×:これはデフォルトのオプションです。

      説明

      テーブルマージ機能はタスクレベルです。つまり、テーブルレベルでテーブルマージを実行することはできません。一部のテーブルをマージし、他のテーブルをマージしない場合は、2 つのデータ移行タスクを作成できます。

      警告

      ソースデータベースまたはテーブルのスキーマを変更する DDL 操作を実行しないでください。そうしないと、データの不整合やタスクの失敗が発生する可能性があります。

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

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

      ソースオブジェクト

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

      重要
      • 移行タイプ増分データ移行 を選択した場合、データテーブルは 1 つしか選択できません。

      • 移行タイプ増分データ移行 を選択しない場合、データベース、テーブル、および列を選択できます。

      • 移行オブジェクトがデータベース全体である場合、デフォルトの動作は次のとおりです:

        • ソースデータベースの移行対象テーブルにプライマリキー (単一列のプライマリキーや複合プライマリキーなど) がある場合、プライマリキー列が分散キーとして使用されます。

        • ソースデータベースの移行対象テーブルにプライマリキーがない場合、ターゲットテーブルに自動採番主キー列が自動的に生成されます。これにより、ソースデータベースとターゲットデータベースの間でデータの不整合が発生する可能性があります。

      選択中のオブジェクト

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

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

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

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

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

    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. 任意: 前の構成が完了したら、次:データベースおよびテーブルのフィールド設定 をクリックします。 次に、ターゲットデータベースに移行するテーブルの タイププライマリキー列の追加配布キー、およびパーティションキーパラメーターを設定します。 パーティションキーパラメーターには、パーティションキーパーティションルール、および パーティションのライフサイクル が含まれます。

      説明
      • このステップは、移行タイプスキーマ移行 を選択した場合にのみ利用可能です。変更するには、定義ステータスすべて を選択します。

      • プライマリキー列の追加 フィールドでは、複数の列を選択して複合プライマリキーを構成できます。 複合プライマリキーの場合、1 つ以上の プライマリキー列の追加配布キー および パーティションキー として選択する必要もあります。 詳細については、「CREATE TABLE」をご参照ください。

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

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

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

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

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

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

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

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

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

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

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

      カテゴリ

      パラメーター

      説明

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

      リソースグループの設定

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

      インスタンスクラス

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

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

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

      データ移行タスク リストページで移行インスタンスの進行状況を表示できます。

      説明
      • 移行インスタンスに増分移行タスクが含まれていない場合、インスタンスは自動的に停止し、そのステータス完了になります。

      • 移行インスタンスに増分移行タスクが含まれている場合、そのインスタンスは自動的に停止せず、増分移行タスクは実行を継続します。増分移行タスクが正常に実行されている間、インスタンスのステータス実行中です。