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

Data Transmission Service:PolarDB for MySQLクラスターからAnalyticDB for MySQL V3.0クラスターへのデータの移行

最終更新日:Oct 31, 2024

このトピックでは、data Transmission Service (DTS) を使用して、PolarDB for MySQLクラスターからAnalyticDB for MySQL V3.0クラスターにデータを移行する方法について説明します。 データを移行した後、AnalyticDB for MySQLを使用して、内部ビジネスインテリジェンス (BI) システム、対話型クエリシステム、リアルタイムレポートシステムなどのシステムを構築できます。

前提条件

  • ソースPolarDB for MySQLクラスターが作成されました。 詳細については、「従量課金クラスターの購入」および「サブスクリプションクラスターの購入」をご参照ください。

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

  • 移行先AnalyticDB for MySQL V3.0クラスターの使用可能なストレージ容量が、移行元PolarDB for MySQLクラスターのデータの合計サイズよりも大きいこと。

制限事項

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

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

カテゴリ

説明

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

  • ソースデータベースが属するサーバーには、十分なアウトバウンド帯域幅が必要です。 そうしないと、データ移行速度が低下します。

  • 移行するテーブルには、PRIMARY KEYまたはUNIQUE制約が必要であり、すべてのフィールドが一意である必要があります。 そうでない場合、宛先データベースは重複するデータレコードを含み得る。

  • 移行するオブジェクトとしてテーブルを選択し、ターゲットデータベースのテーブルまたは列の名前を変更するなど、テーブルを編集する必要がある場合、1つのデータ移行タスクで最大1,000のテーブルを移行できます。 タスクを実行して1,000を超えるテーブルを移行すると、リクエストエラーが発生します。 この場合、複数のタスクを構成してテーブルを移行するか、タスクを構成してデータベース全体を移行することをお勧めします。

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

    説明
    • PolarDB for MySQLクラスターのバイナリログ機能を有効にすると、バイナリログによって占有されているストレージ容量に対して課金されます。

    • 増分データ移行タスクの場合、ソースデータベースのバイナリログを24時間以上保持する必要があります。 完全データおよび増分データ移行タスクの場合、ソースデータベースのバイナリログは少なくとも7日間保持する必要があります。 そうしないと、Data Transmission Service (DTS) がバイナリログの取得に失敗し、タスクが失敗する可能性があります。 例外的な状況では、データの不整合または損失が発生します。 完全なデータ移行が完了したら、保持期間を24時間以上に設定できます。 上記の要件に基づいて、バイナリログの保持期間を設定してください。 それ以外の場合、DTSのサービスレベル契約 (SLA) はサービスの信頼性またはパフォーマンスを保証しません。

  • ソースデータベースで実行する操作の制限:

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

    • データ移行中は、コメントを追加するDDL操作を実行しないでください。 たとえば、ALTER TABLE table_name COMMENT='Table comment'; ステートメントを実行しないでください。 それ以外の場合、データ移行タスクは失敗します。

    • フルデータ移行のみを実行する場合は、データ移行中にソースデータベースにデータを書き込まないでください。 そうしないと、ソースデータベースとターゲットデータベースの間でデータの不一致が発生する可能性があります。 データの一貫性を確保するために、移行タイプとしてスキーマ移行、完全データ移行、および増分データ移行を選択することを推奨します。

使用上の注意

  • プレフィックスインデックスは移行できません。 ソースデータベースにプレフィックスインデックスが含まれている場合、データの移行に失敗する可能性があります。

  • ソースPolarDB for MySQLクラスターの読み取り専用ノードは移行できません。

  • AnalyticDB for MySQLの制限により AnalyticDB for MySQL内のノードのディスク領域使用率 クラスターが80% に達すると、データ移行タスクが遅延し、エラーメッセージが返されます。 移行するオブジェクトに基づいて、必要なディスク容量を見積もることを推奨します。 移行先クラスターに十分なストレージ容量があることを確認する必要があります。

  • データを移行する前に、移行元データベースと移行先データベースのパフォーマンスに対するデータ移行の影響を評価します。 オフピーク時にデータを移行することを推奨します。 完全データ移行中、DTSはソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを使用します。 これにより、データベースサーバーの負荷が増加する可能性があります。

  • 完全データ移行中、同時INSERT操作により、ターゲットデータベースのテーブルが断片化されます。 完全なデータ移行が完了すると、移行先データベースのテーブルスペースは移行元データベースのテーブルスペースよりも大きくなります。

  • FLOATまたはDOUBLEデータ型の列の精度設定がビジネス要件を満たしていることを確認する必要があります。 DTSはROUND(COLUMN,PRECISION) 関数を使用して、FLOATまたはDOUBLEデータ型の列から値を取得します。 精度を指定しない場合、DTSはFLOATデータ型の精度を38桁に設定し、DOUBLEデータ型の精度を308桁に設定します。

  • DTSは、過去7日以内に失敗したデータ移行タスクを再開しようとします。 ワークロードをターゲットデータベースに切り替える前に、データ移行タスクを停止またはリリースします。 REVOKEステートメントを実行して、DTSがターゲットデータベースにアクセスするために使用するアカウントの書き込み権限を取り消すこともできます。 それ以外の場合、失敗したタスクが再開された後、ソースデータベースのデータがターゲットデータベースのデータを上書きします。

  • DTSは、CREATE DATABASE IF NOT EXISTS 'test' ステートメントをソースデータベースで実行し、バイナリログファイルの位置を前に移動します。

課金

移行タイプ

インスタンス設定料金

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

スキーマ移行とフルデータ移行

無料です。

インターネット経由でAlibaba Cloudからデータが移行された場合にのみ課金されます。 詳細については、「課金の概要」をご参照ください。

増分データ移行

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

移行タイプ

  • スキーマ移行

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

    説明

    このトピックでは、ソースデータベースとターゲットデータベースは異種データベースです。 DTSは、スキーマ移行後にソースデータベースとターゲットデータベースのスキーマが一貫していることを保証しません。 データ型変換がビジネスに与える影響を評価することを推奨します。 詳細については、「異種データベース間のデータ型マッピング」をご参照ください。

  • 完全なデータ移行

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

  • 増分データ移行

    完全データ移行が完了すると、DTSは増分データをソースデータベースからターゲットデータベースに移行します。 増分データ移行により、データ移行中に自己管理型アプリケーションのサービスを中断することなく、データをスムーズに移行できます。

増分データ移行中に移行できるSQL操作

操作タイプ

SQL文

DML

挿入、更新、および削除

DDL

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

警告

データ移行中にソーステーブルのフィールドのデータ型が変更された場合、エラーが発生し、データ移行タスクが停止されます。 次の手順を実行して、問題をトラブルシューティングできます。

  1. DTSがターゲットAnalyticDB for MySQL V3.0クラスターにデータを移行するときに、顧客フィールドなどのソーステーブルのフィールドのデータ型が変更されたため、データ移行タスクが失敗したかどうかを確認します。

  2. 移行先のAnalyticDB for MySQL V3.0クラスターで、顧客テーブルと同じスキーマを持つcustomer_newという名前のテーブルを作成します。

  3. INSERT INTO SELECTステートメントを実行して、顧客テーブルのデータをコピーし、データをcustomer_newテーブルに挿入します。 これにより、2つのテーブルのデータが確実に一致します。

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

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

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

データベース

必要な権限

PolarDB for MySQL

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

AnalyticDB for MySQL V3.0クラスター

読み書き権限

データベースアカウントを作成し、データベースアカウントに権限を付与する方法の詳細については、以下のトピックを参照してください。

手順

  1. [データ移行タスク] ページに移動します。

    1. データ管理 (DMS) コンソール にログインします。

    2. 上部のナビゲーションバーで、[DTS] をクリックします。

    3. 左側のナビゲーションウィンドウで、[DTS (DTS)] > [データ移行] を選択します。

    説明
  2. [データ移行タスク] の横にあるドロップダウンリストから、データ移行インスタンスが存在するリージョンを選択します。

    説明

    新しいDTSコンソールを使用する場合は、左上隅にデータ移行インスタンスが存在するリージョンを選択する必要があります。

  3. [タスクの作成] をクリックします。 タスクの作成ウィザードで、ソースデータベースとターゲットデータベースを設定します。 次の表にパラメーターを示します。

    警告

    ソースデータベースとターゲットデータベースを設定した後、ページの上部に表示される制限を読むことを推奨します。 そうしないと、タスクが失敗したり、データの不一致が発生します。

    セクション

    パラメーター

    説明

    N/A

    タスク名

    タスクの名前。 DTSはタスクに名前を自動的に割り当てます。 タスクを簡単に識別できるように、わかりやすい名前を指定することをお勧めします。 一意のタスク名を指定する必要はありません。

    ソースデータベース

    既存のDMSデータベースインスタンスの選択

    使用するデータベースインスタンス。 ビジネス要件に基づいて、既存のインスタンスを使用するかどうかを選択できます。

    • 既存のインスタンスを選択すると、DTSはデータベースのパラメーターを自動的に入力します。

    • 既存のインスタンスを選択しない場合は、ソースデータベースのパラメーターを設定する必要があります。

    データベースタイプ

    移行元ディスクのタイプを設定します。 [PolarDB for MySQL] を選択します。

    アクセス方法

    ソースデータベースのアクセス方法。 [Alibaba Cloudインスタンス] を選択します。

    インスタンスリージョン

    ソースPolarDB for MySQLクラスターが存在するリージョン。

    PolarDBクラスターID

    ソースPolarDB for MySQLクラスターのID。

    データベースアカウント

    ソースPolarDB for MySQLインスタンスのデータベースアカウント。 データベースアカウントに必要な権限の詳細については、このトピックの「データベースアカウントに必要な権限」をご参照ください。

    データベースパスワード

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

    宛先データベース

    既存のDMSデータベースインスタンスの選択

    使用するデータベースインスタンス。 ビジネス要件に基づいて、既存のインスタンスを使用するかどうかを選択できます。

    • 既存のインスタンスを選択した場合、DTSはインスタンスのパラメーターを自動的に入力します。

    • 既存のインスタンスを選択しない場合、ターゲットデータベースのパラメーターを設定する必要があります。

    データベースタイプ

    ターゲットデータベースのタイプ。 [AnalyticDB for MySQL V3.0] を選択します。

    アクセス方法

    ターゲットデータベースのアクセス方法。 [Alibaba Cloudインスタンス] を選択します。

    インスタンスリージョン

    ターゲットAnalyticDB for MySQL V3.0クラスターが存在するリージョン。

    インスタンスID

    ターゲットAnalyticDB for MySQL V3.0クラスターのID。

    データベースアカウント

    ターゲットAnalyticDB for MySQL V3.0クラスターのデータベースアカウント。 アカウントに必要な権限の詳細については、このトピックの「データベースアカウントに必要な権限」をご参照ください。

    データベースパスワード

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

  4. ページの下部で、[接続のテストと続行] をクリックします。

    、ソースまたはターゲットデータベースがAlibaba Cloudデータベースインスタンス (ApsaraDB RDS for MySQLApsaraDB for MongoDBインスタンスなど) の場合、DTSは自動的にDTSサーバーのCIDRブロックをインスタンスのIPアドレスホワイトリストに追加します。 ソースデータベースまたはターゲットデータベースがElastic Compute Service (ECS) インスタンスでホストされている自己管理データベースの場合、DTSサーバーのCIDRブロックがECSインスタンスのセキュリティグループルールに自動的に追加されます。ECSインスタンスがデータベースにアクセスできることを確認する必要があります。 自己管理データベースが複数のECSインスタンスでホストされている場合、DTSサーバーのCIDRブロックを各ECSインスタンスのセキュリティグループルールに手動で追加する必要があります。 ソースデータベースまたはターゲットデータベースが、データセンターにデプロイされているか、サードパーティのクラウドサービスプロバイダーによって提供される自己管理データベースである場合、DTSサーバーのCIDRブロックをデータベースのIPアドレスホワイトリストに手動で追加して、DTSがデータベースにアクセスできるようにする必要があります。 詳細については、「DTSサーバーのCIDRブロックの追加」トピックの「DTSサーバーのCIDRブロック」セクションをご参照ください。

    警告

    DTSサーバーのパブリックCIDRブロックがデータベースインスタンスのホワイトリストまたはECSインスタンスのセキュリティグループルールに自動的または手動で追加されると、セキュリティリスクが発生する可能性があります。 したがって、DTSを使用してデータを移行する前に、潜在的なリスクを理解して認識し、ユーザー名とパスワードのセキュリティの強化、公開されるポートの制限、API呼び出しの認証、ホワイトリストまたはセキュリティグループルールの定期的なチェック、CIDRブロックの禁止、またはExpress Connectを使用したデータベースインスタンスのDTSへの接続、VPNゲートウェイ、またはSmart Access Gateway。

  5. 移行するオブジェクトと詳細設定を設定します。

    パラメーター

    説明

    移行タイプ

    • フルデータ移行のみを実行する場合は、[スキーマ移行] および [フルデータ移行] を選択します。

    • データ移行中にサービスの継続性を確保するには、[スキーマ移行][フルデータ移行] 、および [増分データ移行] を選択します。

    説明
    • [フルデータ移行] が選択されている場合、CREATE tableステートメントを実行して作成されたテーブルのスキーマとデータを移行先データベースに移行できます。

    • 増分データ移行が選択されていない場合、データ移行中にソースインスタンスにデータを書き込まないことを推奨します。 これにより、ソースインスタンスとターゲットインスタンス間のデータの整合性が確保されます。

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

    • エラーの事前チェックと報告: ターゲットデータベースに、ソースデータベースのテーブルと同じ名前を使用するテーブルが含まれているかどうかを確認します。 ソースデータベースとターゲットデータベースに同じテーブル名のテーブルが含まれていない場合は、事前チェックに合格します。 それ以外の場合、事前チェック中にエラーが返され、データ移行タスクを開始できません。

      説明

      ソースデータベースとターゲットデータベースに同じ名前のテーブルが含まれていて、ターゲットデータベース内のテーブルを削除または名前変更できない場合は、オブジェクト名マッピング機能を使用して、ターゲットデータベースに移行されるテーブルの名前を変更できます。 詳細については、「マップオブジェクト名」をご参照ください。

    • エラーを無視して続行: ソースデータベースとターゲットデータベースの同じテーブル名の事前チェックをスキップします。

      警告

      エラーを無視して続行 を選択すると、データの不整合が発生し、ビジネスが次の潜在的なリスクにさらされる可能性があります。

      • ソースデータベースとターゲットデータベースのスキーマが同じである場合、DTSは、ターゲットデータベースのデータレコードと同じ主キーを持つデータレコードを移行しません。

      • ソースデータベースとターゲットデータベースのスキーマが異なる場合、特定の列のみが移行されるか、データ移行タスクが失敗します。 作業は慎重に行ってください。

    DDL操作とDML操作の同期

    インスタンスレベルでの増分データ移行中に移行されるSQL操作。 詳細については、このトピックの「増分データ移行中に移行できるSQL操作」をご参照ください。

    説明

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

    マージテーブル

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

    • No: これはデフォルト値です。

    説明

    このパラメーターを [はい] に設定すると、タスクで選択したすべてのソーステーブルがターゲットテーブルにマージされます。 特定のソーステーブルをマージする必要がない場合は、これらのテーブルに対して個別のデータ移行タスクを作成できます。

    警告

    ソースデータベースまたはテーブルのスキーマを変更するためのDDL操作を実行しないことをお勧めします。 そうしないと、データの不整合が発生したり、データ移行タスクが失敗したりします。

    ソースオブジェクト

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

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

    • 移行するオブジェクトとしてデータベースを選択した場合、DTSは次のデフォルトルールに基づいてデータを移行します。

      • 移行元データベースで移行するテーブルに、単一列の主キーや複合主キーなどの主キーがある場合、主キー列が配布キーとして指定されます。

      • 移行元データベース内の移行するテーブルにプライマリキーがない場合、移行先テーブルに自動インクリメントのプライマリキー列が自動的に生成されます。 これにより、ソースデータベースとターゲットデータベース間でデータの不一致が発生する可能性があります。

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

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

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

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

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

    • 特定のデータベースまたはテーブルで実行されたSQL操作を選択するには、[選択済みオブジェクト] セクションでオブジェクトを右クリックします。 表示されるダイアログボックスで、移行するSQL操作を選択します。 移行できるSQL操作の詳細については、「増分データ移行中に移行できるSQL操作」をご参照ください。

  6. 次へ:詳細設定をクリックして詳細設定を設定します。

    パラメーター

    説明

    Set Alerts

    データ移行タスクのアラートを設定するかどうかを指定します。 タスクが失敗するか、移行の待ち時間が指定されたしきい値を超えると、アラート送信先は通知を受け取ります。 有効な値:

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

    ターゲットインスタンスのデータベース名、テーブル名、および列名の大文字化。 デフォルトでは、DTSデフォルトポリシーが選択されています。 他のオプションを選択して、オブジェクト名の大文字化がソースまたはターゲットデータベースの大文字化と一致していることを確認できます。 詳細については、「ターゲットインスタンスのオブジェクト名の大文字化の指定」をご参照ください。

    ソーステーブルで生成されたOnline DDLツールの一時テーブルをターゲットデータベースにコピーします

    DMSまたはgh-ostツールを使用してソースデータベースでオンラインDDL操作を実行する場合、オンラインDDL操作によって生成された一時テーブルのデータを移行するかどうかを指定できます。 有効な値:

    重要

    pt-online-schema-changeなどのツールを使用して、ソースデータベースでオンラインDDL操作を実行することはできません。 それ以外の場合、DTSタスクは失敗します。

    • はい: DTSは、オンラインDDL操作によって生成された一時テーブルのデータを移行します。

      説明

      オンラインDDL操作で大量のデータが生成される場合、データ移行タスクにレイテンシが発生する可能性があります。

    • いいえ、DMSオンラインDDLに適応: DTSは、オンラインDDL操作によって生成された一時テーブルのデータを移行しません。 DMSを使用して実行された元のDDL操作のみが移行されます。

      説明

      [いいえ] [DMSオンラインDDLに適応] を選択した場合、ターゲットデータベースのテーブルがロックされる可能性があります。

    • No, Adapt to gh-ost: DTSは、オンラインDDL操作によって生成された一時テーブルのデータを移行しません。 gh-ostツールを使用して実行された元のDDL操作のみが移行されます。 デフォルトまたはカスタムの正規表現を使用して、gh-ostツールのシャドウテーブルと不要なテーブルを除外できます。

      説明

      [いいえ] 、[gh-ostに適応] を選択すると、ターゲットデータベースのテーブルがロックされる可能性があります。

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

    失敗した接続のリトライ時間範囲。 データ移行タスクの開始後にソースデータベースまたはターゲットデータベースの接続に失敗した場合、DTSはその時間範囲内ですぐに接続を再試行します。 有効な値: 10 ~ 1440 単位は分です。 デフォルト値: 720 パラメーターを30より大きい値に設定することを推奨します。 DTSが指定された時間範囲内にソースデータベースとターゲットデータベースに再接続すると、DTSはデータ移行タスクを再開します。 それ以外の場合、データ移行タスクは失敗します。

    説明
    • ソースまたはターゲットデータベースが同じである複数のデータ移行タスクに対して異なるリトライ時間範囲を設定した場合、設定された最短のリトライ時間範囲が優先されます。

    • DTSが接続を再試行すると、DTSインスタンスに対して課金されます。 業務要件に基づいて再試行時間範囲を指定することを推奨します。 ソースインスタンスとターゲットインスタンスがリリースされた後、できるだけ早くDTSインスタンスをリリースすることもできます。

    ETLの設定

    抽出、変換、および読み込み (ETL) 機能を有効にするかどうかを指定します。 詳細については、「ETLとは何ですか?」をご参照ください。 有効な値:

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

    DTSインスタンスの実行中に、ハートビートテーブルのSQL操作をソースデータベースに書き込むかどうかを指定します。 有効な値:

    • Yes: ハートビートテーブルにSQL操作を書き込みません。 この場合、DTSインスタンスのレイテンシが表示され得る。

    • No: ハートビートテーブルにSQL操作を書き込みます。 この場合、ソースデータベースの物理バックアップやクローニングなどの機能が影響を受ける可能性があります。

  7. 移行先に移行するテーブルの主キー列と配布キー列を指定します。AnalyticDB for MySQLクラスター

    説明
    • 移行タイプ パラメーターに スキーマ移行 を選択した場合、AnalyticDB for MySQL V3.0クラスターに移行するテーブルの [タイプ][プライマリキー列] 、および [配布キー] パラメーターを設定する必要があります。 詳細については、「CREATE TABLE」をご参照ください。

    • [プライマリキー列] フィールドでは、複数の列を指定して複合プライマリキーを形成できます。 この場合、1つ以上のプライマリキー列配布キーとして指定する必要があります。

  8. ページの下部で、次:タスク設定の保存と事前チェック をクリックします。

    ポインタを 次:タスク設定の保存と事前チェック に移動し、[OpenAPIパラメーターのプレビュー] をクリックして、関連するAPI操作を呼び出してDTSタスクを設定するときに指定するパラメーターを表示できます。

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

    • タスクが事前チェックに合格しなかった場合は、失敗した各項目の横にある [詳細の表示] をクリックします。 チェック結果に基づいて原因を分析した後、問題のトラブルシューティングを行います。 次に、もう一度プレチェックを実行します。

    • 事前チェック中にアイテムに対してアラートが生成された場合は、シナリオに基づいて次の操作を実行します。

      • アラートアイテムを無視できない場合は、失敗したアイテムの横にある [詳細の表示] をクリックして問題のトラブルシューティングを行います。 次に、もう一度プレチェックを実行します。

      • アラート項目を無視できる場合は、[アラート詳細の確認] をクリックします。 [詳細の表示] ダイアログボックスで、[無視] をクリックします。 表示されたメッセージボックスで、[OK] をクリックします。 次に、[再度事前チェック] をクリックして、事前チェックを再度実行します。 アラート項目を無視すると、データの不整合が発生し、ビジネスが潜在的なリスクにさらされる可能性があります。

  9. 成功率100% になるまで待ちます。 次に、[次へ: インスタンスの購入] をクリックします。

  10. [インスタンスの購入] ページで、データ移行インスタンスのインスタンスクラスパラメーターを設定します。 下表にパラメーターを示します。

    セクション

    パラメーター

    説明

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

    リソースグループ設定

    データ移行インスタンスが属するリソースグループ。 デフォルト値: Default resource group 詳細については、「リソース管理とは」をご参照ください。

    インスタンスクラス

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

  11. 読んで同意するデータ伝送サービス (従量課金) サービス規約チェックボックスを選択します。

  12. [購入と開始] をクリックして、データ移行タスクを開始します。 タスクリストでタスクの進行状況を確認できます。