すべてのプロダクト
Search

このプロダクト

    Data Transmission Service:PolarDB for MySQL から AnalyticDB for MySQL V3.0 への移行

    ドキュメントセンター

    Data Transmission Service:PolarDB for MySQL から AnalyticDB for MySQL V3.0 への移行

    最終更新日:Jul 18, 2026

    Data Transmission Service (DTS) を使用して、PolarDB for MySQL から AnalyticDB for MySQL 3.0 へデータを移行し、ビジネスインテリジェンス (BI)、インタラクティブなクエリ、リアルタイムレポートのためのシステムを構築します。

    前提条件

    • ソースとなる PolarDB for MySQL クラスターが必要です。詳細については、「従量課金クラスターの購入」および「サブスクリプションクラスターの購入」をご参照ください。

    • ターゲットとなる AnalyticDB for MySQL 3.0 クラスターを作成済みである必要があります。詳細については、「クラスターの作成」をご参照ください。

    • ターゲットの AnalyticDB for MySQL クラスターのストレージ容量は、ソースの PolarDB for MySQL クラスターで使用されている容量よりも大きくなければなりません。

    制限事項

    説明

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

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

    • スキーマ移行中、DTS はマテリアライズドビューを宛先の AnalyticDB for MySQL インスタンスへ移行することをサポートしていません。マテリアライズドビューを使用するには、移行完了後に手動で宛先インスタンスに作成してください。

    タイプ

    説明

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

    • ソースデータベースをホストするサーバーは十分なアウトバウンド帯域幅を備えていなければなりません。そうでない場合、データ移行速度に影響します。

    • 移行対象のテーブルにはプライマリキーまたは一意制約が設定されており、そのキーまたは制約内のフィールドが一意である必要があります。そうでない場合、宛先データベースに重複データが現れる可能性があります。

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

    • 増分移行を実行する場合：

      • バイナリロギングを有効にし、loose_polar_log_bin パラメーターを on に設定する必要があります。そうしないと、事前チェックでエラーが報告され、データ移行タスクを開始できません。バイナリロギングの有効化およびパラメーター変更方法の詳細については、「バイナリロギングの有効化」および「パラメーターの変更」をご参照ください。

        説明

        PolarDB for MySQL クラスターでバイナリロギングを有効にすると、ストレージ領域を消費し、ストレージ料金が発生します。

      • PolarDB for MySQL クラスターのバイナリログは、少なくとも 3 日間保持する必要があります。7 日間の保持を推奨します。そうでない場合、DTS がバイナリログを取得できず、タスクが失敗する可能性があります。最悪の場合、データの不整合やデータ損失につながります。DTS の要件よりも短いバイナリログ保持期間によって生じた問題は、DTS サービスレベルアグリーメント (SLA) の適用外となります。

        説明

        PolarDB for MySQL クラスターのバイナリログ保持期間の設定方法の詳細については、「保持期間の変更」をご参照ください。

    • ソースデータベースの運用上の制限：

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

        説明

        完全なデータ移行中、DTS はソースデータベースをクエリします。これによりメタデータロックが発生し、ソースデータベースでの DDL 操作がブロックされる可能性があります。

      • 移行中は、プライマリキーを変更したり、テーブルにコメントを追加したりする DDL 操作（例：ALTER TABLE table_name COMMENT='table_comment';）を実行しないでください。そうしないと、データ移行タスクが失敗します。

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

    注意事項

    • DTS はプレフィックスインデックスの移行をサポートしていません。ソースデータベースにプレフィックスインデックスが存在する場合、データ移行が失敗する可能性があります。

    • ソースデータベースで一時テーブルモードのオンライン DDL 操作（複数テーブルのマージシナリオを含む）を使用している場合、または一意キー列に関数ベースインデックスを追加している場合、宛先データベースでデータ損失またはタスク失敗が発生する可能性があります。

    • 移行中にプライマリキーまたは一意キーの競合が発生した場合：

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

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

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

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

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

    • DTS はソース PolarDB for MySQL インスタンスの読み取り専用ノードの移行をサポートしていません。

    • DTS はソース PolarDB for MySQL インスタンスの OSS 外部テーブルの移行をサポートしていません。

    • DTS は INDEX、PARTITION、VIEW、PROCEDURE、FUNCTION、TRIGGER、および FK の移行をサポートしていません。

    • DTS は完全なデータ移行中にデータベースインスタンスのプライマリ/スタンバイスイッチオーバーシナリオをサポートしていません。このようなシナリオが発生した場合は、移行タスクを速やかに再構成してください。

    • AnalyticDB for MySQL の制限により、AnalyticDB for MySQL クラスターのいずれかのノードのディスク領域使用率が 80% を超えると、DTS タスクが異常となり、遅延が発生します。必要な領域を事前に見積もり、宛先クラスターに十分なストレージがあることを確認してください。

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

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

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

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

    • DTS は失敗したタスクを 7 日以内に回復しようと試みます。ワークロードを宛先インスタンスに切り替える前に、タスクを終了またはリリースする必要があります。または、revoke コマンドを使用して、DTS が宛先インスタンスにアクセスするために使用するデータベースアカウントの書き込み権限を取り消してください。これにより、タスクが自動的に回復した場合にソースデータが宛先インスタンスのデータを上書きすることを防止できます。

    • DTS は定期的にソースデータベース上で CREATE DATABASE IF NOT EXISTS `test` コマンドを実行し、バイナリログオフセットを進めます。

    • DDL 文が宛先データベースへの書き込みに失敗した場合でも、DTS タスクは継続して実行されます。失敗した DDL 文についてはタスクログを確認する必要があります。タスクログの確認方法の詳細については、「タスクログの照会」をご参照ください。

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

      説明

      DTS タスクパラメーターのみが変更され、データベースパラメーターは変更されません。 調整対象となるパラメーターは、「インスタンスパラメーターの変更」に記載されています。

    課金

    移行タイプ

    インスタンス構成料金

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

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

    無料です。

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

    増分データ移行

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

    移行タイプ

    • スキーマ移行

      DTS は選択されたオブジェクトのスキーマをソースデータベースから宛先データベースへ移行します。

      説明

      これは異種データベース間の移行に適用されます。スキーマ移行中にデータ型が完全にマッピングされない可能性があるため、ビジネスへの影響を慎重に評価する必要があります。詳細については、「異種データベースのデータ型マッピング」をご参照ください。

    • 完全なデータ移行

      DTS は選択されたソースデータベースオブジェクトのすべてのデータを宛先データベースへ移行します。

    • 増分データ移行

      完全なデータ移行完了後、DTS はソースデータベースからの増分データ変更を宛先データベースへ移行します。このプロセスにより、セルフマネージドアプリケーションのサービス中断なしにスムーズな移行が可能になります。

    増分移行の SQL 操作

    操作タイプ

    SQL ステートメント

    DML

    INSERT、UPDATE、および DELETE

    説明

    AnalyticDB for MySQL にデータを書き込む際、UPDATE ステートメントは自動的に REPLACE INTO に変換されます。プライマリキーを更新する場合、UPDATE ステートメントは DELETE とそれに続く INSERT に変換されます。

    DDL

    CREATE TABLE、DROP TABLE、RENAME TABLE、TRUNCATE TABLE、ADD COLUMN、MODIFY COLUMN、および DROP COLUMN

    重要

    RENAME TABLE 操作によりデータの不整合が発生する可能性があります。たとえば、移行オブジェクトとして 1 つのテーブルのみを選択し、移行中にソースインスタンスでそのテーブル名を変更した場合、このテーブルのデータは宛先データベースに移行されません。この問題を回避するには、データ移行タスクを構成する際に、テーブルが属するデータベース全体を移行オブジェクトとして選択してください。RENAME TABLE 操作の前後でテーブルが属するデータベースの両方が移行オブジェクトに含まれていることを確認してください。
    警告

    データ移行中にソーステーブルのフィールドのデータ型が変更された場合、タスクは停止し、エラーを報告します。この問題を解決するには、次の手順を実行してください。

    1. ソーステーブル（例：customer）のフィールドのデータ型が変更されたため、宛先データベース AnalyticDB for MySQL への移行タスクが失敗します。

    2. AnalyticDB for MySQL V3.0 に、ソーステーブルから更新されたスキーマを持つ新しいテーブル（例： customer_new）を作成します。

    3. INSERT INTO SELECT コマンドを使用して、元の customer テーブルから customer_new へデータをコピーします。

    4. 元の customer テーブルの名前を変更または削除し、customer_new の名前を customer に変更します。

    5. DTS コンソールでデータ移行タスクを再開します。

    権限要件

    データベース

    権限

    PolarDB for MySQL

    移行対象オブジェクトに対する読み取り権限

    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. ソースおよび宛先データベースを構成します。

      警告

      ソースおよび宛先インスタンスを選択した後、ページ上部に表示される制限事項を慎重にご確認ください。そうしないと、タスクが失敗したり、データの不整合が発生したりする可能性があります。

      カテゴリ

      パラメーター

      説明

      該当なし

      タスク名

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

      ソースデータベース

      既存の接続情報の選択

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

        説明

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

      • データベースインスタンスをシステムに登録していない場合、または登録済みのインスタンスを使用しない場合は、以下でデータベース情報を手動で構成してください。

      データベースタイプ

      PolarDB for MySQL を選択します。

      アクセス方法

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

      インスタンスリージョン

      ソース PolarDB for MySQL インスタンスのリージョンを選択します。

      PolarDB クラスター ID

      ソース PolarDB for MySQL インスタンスの ID を選択します。

      データベースアカウント

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

      データベースパスワード

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

      暗号化

      必要に応じて接続タイプを選択します。SSL 暗号化機能の詳細については、「SSL 暗号化の有効化」をご参照ください。

      宛先データベース

      既存の接続情報の選択

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

        説明

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

      • データベースインスタンスをシステムに登録していない場合、または登録済みのインスタンスを使用しない場合は、以下でデータベース情報を手動で構成してください。

      データベースタイプ

      AnalyticDB for MySQL 3.0 を選択します。

      アクセス方法

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

      インスタンスリージョン

      ターゲット AnalyticDB for MySQL クラスターのリージョンを選択します。

      インスタンス ID

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

      データベースアカウント

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

      データベースパスワード

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

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

      説明

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

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

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

        パラメーター

        説明

        移行タイプ

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

        • ゼロダウンタイム移行の場合、スキーマ移行、完全データ移行、および 増分データ移行 を選択します。

        説明

        • 完全データ移行 を選択した場合、CREATE TABLE ステートメントで作成されたテーブルのスキーマおよびデータを宛先データベースに移行できます。

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

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

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

          説明

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

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

          警告

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

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

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

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

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

        DDL操作とDML操作の同期

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

        説明

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

        マージテーブル

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

        • × を選択した場合、これがデフォルトオプションです。

        説明

        テーブルマージ機能はタスクレベルで構成され、テーブルレベルでは構成されません。一部のテーブルのみをマージする場合は、2 つの個別のデータ移行タスクを作成する必要があります。

        警告

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

        ソースオブジェクト

        ソースオブジェクト セクションから 1 つ以上のオブジェクトを選択します。Rightwards arrow アイコンをクリックして、オブジェクトを 選択済みオブジェクト セクションに追加します。

        説明

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

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

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

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

        [選択済みオブジェクト]
        説明

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

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

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

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

        パラメーター

        説明

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

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

        移行元テーブルで生成された Online DDL ツールの一時テーブルを移行先データベースにコピーします。

        ソースデータベースでオンライン DDL 変更を実行するために Data Management (DMS) または gh-ost を使用している場合、オンライン DDL 変更で生成された一時テーブルからのデータ移行を実行するかどうかを選択できます。

        重要

        • DTS タスクは pt-online-schema-change などのツールを使用したオンライン DDL 変更をサポートしていません。そうしないと、DTS タスクが失敗します。

        • 各フェーズの処理方法は次のとおりです。スキーマ移行 および 完全データ移行 フェーズでは、データベースまたはテーブル構造を変更する DDL 操作が許可されていません。したがって、これらはオンライン DDL ポリシーの制御を受けません。

          • スキーマ移行：オンライン DDL ポリシーの制御を受けません。関連する一時テーブルが作成されます。

          • 完全データ移行：オンライン DDL ポリシーの制御を受けません。一時テーブルの移行は完全移行オブジェクトに含まれません。正規表現（^_(.+)_(?:gho|new)$ または ^_(.+)_(?:ghc|del|old)$）に一致する名前のすべてのテーブルがフィルターで除外されます。

          • 増分データ移行：オンライン DDL ポリシーの制御を受けます。

            • ○：オンライン DDL 操作で生成された一時テーブル（例：_table_name_gho）からのデータ変更を移行します。

            • いいえ、DMS オンライン DDL に適応 および いいえ、gh-ost に適応：gh-ost などのツールで生成された一時テーブル（例：_table_name_gho）からのデータ変更を正規表現ルールに基づいてフィルターで除外します。

        • ○：オンライン DDL 変更で生成された一時テーブルからのデータを移行します。

          説明

          オンライン DDL 変更で一時テーブルに大量のデータが生成された場合、タスクの遅延が発生する可能性があります。

        • いいえ、DMS オンライン DDL に適応：オンライン DDL 変更で生成された一時テーブルからのデータを移行しません。Data Management (DMS) を使用して実行された元の DDL ステートメントのみを移行します。

          説明

          このオプションにより、宛先データベースのテーブルがロックされます。

        • いいえ、gh-ost に適応：オンライン DDL 変更で生成された一時テーブルからのデータを移行しません。カスタムフィルタールールをサポートしています。DTS は、gh-ost などのツールで生成された一時テーブル（例：_table_name_gho）からのデータ変更を、正規表現ルールに基づいてフィルターで除外します。必要に応じて、シャドウテーブルおよび不要なテーブルに一致させるためのデフォルトの正規表現を変更できます：

          • シャドウテーブル：^_(.+)_(?:gho|new)$

          • 不要なテーブル：^_(.+)_(?:ghc|del|old)$

          説明

          このオプションにより、宛先データベースのテーブルがロックされます。

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

        移行タスク開始後、ソースまたは宛先データベースへの接続が失敗した場合、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 を設定して、宛先データベースの負荷を軽減できます。

        説明

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

        • 移行インスタンス実行後も、増分移行速度を調整 できます。

        順方向および逆方向タスクのハートビートテーブル SQL を削除

        DTS インスタンス実行中にソースデータベースにハートビート SQL 情報を書き込むかどうかを選択します。

        • ○：ハートビート SQL 情報はソースデータベースに書き込まれません。これにより、DTS インスタンスが遅延を報告する可能性があります。

        • ×：ハートビート SQL 情報をソースデータベースに書き込みます。これにより、ソースデータベースの物理バックアップやクローンなどの機能に干渉する可能性があります。

        環境タグ

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

        ETL 機能の設定

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

        監視アラート

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

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

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

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

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

      4. オプション： 上記の構成が完了したら、次：データベースおよびテーブルのフィールド設定 をクリックして、宛先データベースで移行対象のテーブルの タイプ、プライマリキー列の追加、配布キー、およびパーティションキー情報（パーティションキー、パーティションルール、および パーティションのライフサイクル）を設定します。

        説明

        • このステップは、タスクオブジェクトを構成する際に 移行タイプ で スキーマ移行 オプションを選択した場合にのみ利用可能です。定義ステータス で すべて を選択して、変更を行うことができます。

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

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

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

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

      説明

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

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

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

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

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

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

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

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

        カテゴリ

        パラメーター

        説明

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

        リソースグループの設定

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

        インスタンスクラス

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

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

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

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

        説明

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

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