すべてのプロダクト
Search

このプロダクト

    Data Transmission Service:PolarDB for PostgreSQL (Oracle 互換) から AnalyticDB for MySQL V3.0 への移行

    ドキュメントセンター

    Data Transmission Service:PolarDB for PostgreSQL (Oracle 互換) から AnalyticDB for MySQL V3.0 への移行

    最終更新日:Apr 21, 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 つのデータ移行タスクでサポートされるテーブルは最大 1,000 個です。この制限を超えると、タスクの送信時にエラーが報告されます。この場合、テーブルを複数の移行タスクに分割するか、データベース全体を移行するタスクを構成してください。

    • 増分移行を実行する場合、WAL に関して次の点にご注意ください：

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

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

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

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

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

      • 移行タスクが期待どおりに実行され、フェールオーバーによって論理レプリケーションが中断されるのを防ぐために、PolarDB for PostgreSQL (Oracle 互換) は論理レプリケーションスロットのフェールオーバーをサポートし、有効にする必要があります。

        説明

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

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

    • ソースデータベースに長時間トランザクションがあり、インスタンスが増分移行を実行する場合、トランザクションコミット前の WAL が蓄積され、クリアできなくなる可能性があります。これにより、ソースデータベースのディスク領域が不足する可能性があります。

    その他の制限

    • 1 つのデータ移行タスクで移行できるデータベースは 1 つだけです。複数のデータベースを移行するには、データベースごとに個別のデータ移行タスクを構成してください。

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

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

    • 拡張機能のインストールによって作成されたスキーマは、移行の対象外です。タスクを構成する際に、コンソールでこれらのスキーマに関する情報を取得することはできません。

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

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

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

      説明

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

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

    • DTS は、増分データの DDL 文、増分テーブルの構造、およびハートビート情報を取得するために、ソースデータベースに以下の一時テーブルを作成します。移行中にこれらの一時テーブルを削除しないでください。そうしないと、DTS タスクが異常になります。一時テーブルは、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 アドレスを削除したりすると、レプリケーションスロットは自動的にクリーンアップされません。この場合、ソースデータベースでレプリケーションスロットを手動でクリーンアップする必要があります。これにより、スロットが継続的に蓄積されてディスク領域を消費し、ソースデータベースが利用できなくなるのを防ぎます。

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

    • 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 文は DELETE の後に INSERT が続く形に変換されます。

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

    データベース

    権限

    リファレンス

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

    特権アカウントが必要です。

    「データベースアカウントの作成」をご参照ください。

    AnalyticDB for MySQL 3.0

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

    「データベースアカウントの作成」をご参照ください。

    操作手順

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

      警告

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

      カテゴリ

      パラメーター

      説明

      N/A

      タスク名

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

      移行元データベース

      データベースタイプ

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

      アクセス方法

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

      インスタンスリージョン

      送信元の PolarDB for Oracle クラスターが存在するリージョンを選択します。

      インスタンス ID

      送信元の PolarDB for Oracle クラスターのインスタンス ID を選択します。

      データベース名

      送信元の PolarDB for Oracle クラスターから移行するオブジェクトが含まれるデータベースの名前を入力します。

      データベースアカウント

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

      データベースパスワード

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

      移行先データベース

      データベースタイプ

      AnalyticDB for MySQL 3.0 を選択します。

      アクセス方法

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

      インスタンスリージョン

      送信先の AnalyticDB for MySQL V3.0 クラスターが存在するリージョンを選択します。

      インスタンス ID

      送信先の AnalyticDB for MySQL V3.0 クラスターの ID を選択します。

      データベースアカウント

      送信先の AnalyticDB for MySQL V3.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 のデフォルトポリシー が選択されています。ソースまたはターゲットデータベースのデフォルトポリシーと大文字/小文字の区別を一致させることも選択できます。詳細については、「ターゲットデータベースのオブジェクト名の大文字/小文字の区別」をご参照ください。

        ソースオブジェクト

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

        重要

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

        • 移行タイプ で 増分データ移行 を選択しない場合、データベース、テーブル、または列レベルでオブジェクトを選択できます。

        • データベース全体を移行オブジェクトとして選択した場合、以下のデフォルトルールが適用されます：

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

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

        選択中のオブジェクト
        説明

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

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

        • データベースまたはテーブルレベルで移行する SQL 操作を選択するには、選択中のオブジェクト ボックスで移行オブジェクトを右クリックし、表示されるダイアログボックスで必要な 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) 機能を有効にするかどうかを選択します。詳細については、「ETL とは」をご参照ください。有効な値：

        監視アラート

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

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

        • ○：アラートのしきい値とアラート通知を設定してアラートを構成します。移行が失敗した場合、または遅延がしきい値を超えた場合、システムはアラート通知を送信します。

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

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

      4. オプション：上記の設定が完了したら、次：データベースおよびテーブルのフィールド設定 をクリックして、ターゲットデータベースのテーブルの タイプ、プライマリキー列の追加、配布キー、およびパーティションキー情報 (パーティションキー、パーティションルール、および パーティションのライフサイクル) を設定します。

        説明

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

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

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

      • API オペレーションを呼び出す際にこのインスタンスを構成するためのパラメーターを表示するには、次：タスク設定の保存と事前チェック ボタンにポインターを合わせ、表示されるバブルで OpenAPI パラメーターのプレビュー をクリックします。

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

      説明

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

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

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

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

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

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

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

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

        カテゴリ

        パラメーター

        説明

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

        リソースグループの設定

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

        インスタンスクラス

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

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

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

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

        説明

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

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