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

ApsaraDB RDS:ApsaraDB RDS for MySQL インスタンス間でのデータ移行

最終更新日:Apr 11, 2025

このトピックでは、Data Transmission Service (DTS) を使用して ApsaraDB RDS インスタンス間でデータを移行する方法について説明します。DTS は、スキーマ移行、フルデータ移行、増分データ移行をサポートしています。データ移行タスクを構成する際に、サポートされているすべての移行方式を選択して、業務継続性を確保できます。

重要

前提条件

  • ソースとデスティネーションの ApsaraDB RDS for MySQL インスタンスが作成されていること。詳細については、「ApsaraDB RDS for MySQL インスタンスの作成」をご参照ください。

  • デスティネーション ApsaraDB RDS for MySQL インスタンスの使用可能なストレージが、ソース ApsaraDB RDS for MySQL インスタンスのストレージよりも大きいこと。

使用上の注意

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

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

カテゴリ

説明

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

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

  • 移行対象のテーブルには、PRIMARY KEY または UNIQUE 制約があり、すべてのフィールドが一意である必要があります。そうでない場合、ターゲットデータベースに重複データレコードが含まれる可能性があります。

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

  • 増分データを移行する場合、バイナリログに関する以下の要件を満たす必要があります。

    • バイナリロギング機能が有効になっていること。binlog_format パラメータが row に設定され、binlog_row_image パラメータが full に設定されていること。そうでない場合、事前チェック中にエラーメッセージが返され、データ移行タスクが開始できません。

      重要

      ソースデータベースがデュアルプライマリクラスタにデプロイされた自己管理 MySQL データベースの場合、log_slave_updates パラメータを ON に設定する必要があります。これにより、DTS がすべてのバイナリログを取得できるようになります。

    • ソースデータベースのバイナリログは、少なくとも 7 日間保存する必要があります。そうでない場合、DTS がバイナリログを取得できず、タスクが失敗する可能性があります。例外的な状況では、データの不整合または損失が発生する可能性があります。上記の要件に基づいてバイナリログの保存期間を構成してください。そうでない場合、DTS のサービスレベル契約 (SLA) に記載されているサービスの信頼性またはパフォーマンスが保証されない可能性があります。

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

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

    • フルデータ移行のみを実行する場合は、データ移行中にソースデータベースにデータを書き込まないでください。書き込むと、ソースデータベースとターゲットデータベース間でデータの不整合が発生します。データの整合性を確保するために、移行タイプとしてスキーマ移行、フルデータ移行、増分データ移行を選択することをお勧めします。

  • データ移行インスタンスの実行中は、物理バックアップから復元されたデータやカスケード操作からのデータなど、バイナリログの変更操作によって生成されたデータは記録されず、ターゲットデータベースに移行されません。

    説明

    変更データが記録されず、ターゲットデータベースに移行されない場合は、ビジネスに影響がないことを前提に、フルデータを再度移行できます。

  • ソースデータベースが MySQL データベース 8.0.23 以降であり、移行対象のデータに非表示の列が含まれている場合、その列のデータを取得できず、データ損失が発生します。

    説明
    • 列を表示するには、ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; コマンドを実行します。詳細については、「Invisible Columns」をご参照ください。

    • プライマリキーのないテーブルは、自動的に非表示のプライマリキーを生成します。非表示のプライマリキーを表示する必要があります。詳細については、「Generated Invisible Primary Keys」をご参照ください。

その他の制限

  • 互換性を確保するために、ソースとデスティネーションの MySQL データベースのバージョンは同じである必要があります。

  • DTS は、コメントを使用して定義されたパーサーが使用されているデータは移行しません。

  • ターゲットデータベースが MySQL データベース 8.0.23 以降であり、データを受信する列に非表示の列が含まれている場合、データが書き込まれるターゲット列が見つかりません。この場合、DTS インスタンスは実行に失敗し、データ損失が発生します。

    説明
    • 列を表示するには、ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; コマンドを実行します。詳細については、「Invisible Columns」をご参照ください。

    • プライマリキーのないテーブルは、自動的に非表示のプライマリキーを生成します。非表示のプライマリキーを表示する必要があります。詳細については、「Generated Invisible Primary Keys」をご参照ください。

  • データ移行シナリオで DTS のスキーマ移行機能を使用しない場合は、フィールドの互換性を確保する必要があります。たとえば、ソーステーブルのフィールドが text 型で、ターゲットテーブルのフィールドが varchar(255) 型の場合、ソーステーブルに大きなフィールドが含まれていると、データが切り捨てられる可能性があります。

  • 移行対象のデータに、4 バイトを占める珍しい文字や絵文字などの情報が含まれている場合、データを受信するターゲットデータベースとテーブルは UTF8mb4 文字セットを使用する必要があります。

    説明

    DTS のスキーマ移行機能を使用する場合は、ターゲットデータベースのインスタンスパラメータ character_set_server を UTF8mb4 文字セットに設定します。

  • データ移行を行う前に、データ移行がソースデータベースとターゲットデータベースのパフォーマンスに与える影響を評価してください。オフピーク時にデータ移行を行うことをお勧めします。フルデータ移行中、DTS はソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。

  • フルデータ移行中、同時 INSERT 操作により、ターゲットデータベースのテーブルで断片化が発生します。フルデータ移行が完了すると、ターゲットデータベースの表領域はソースデータベースの表領域よりも大きくなります。

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

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

  • ターゲットデータベースで DDL 文の実行に失敗した場合でも、DTS タスクは引き続き実行されます。実行に失敗した DDL 文はタスクログで確認できます。タスクログの表示方法の詳細については、「タスクログの表示」をご参照ください。

  • 大文字と小文字のみが異なる列名をターゲット MySQL データベースの同じテーブルに書き込むと、MySQL データベースでは列名の大文字と小文字が区別されないため、データ移行結果が期待どおりにならない可能性があります。

  • データ移行が完了した後、つまり、インスタンスの [ステータス][完了] に変更された後、analyze table <table name> コマンドを実行して、データがターゲットテーブルに書き込まれているかどうかを確認することをお勧めします。たとえば、ターゲット MySQL データベースで高可用性 (HA) スイッチオーバーがトリガーされた場合、データはメモリにのみ書き込まれる可能性があります。その結果、データ損失が発生します。

  • ソースデータベースが EncDB 機能が有効になっている ApsaraDB RDS for MySQL インスタンスの場合、フルデータ移行を実行できません。

    説明

    透過的データ暗号化 (TDE) 機能が有効になっている ApsaraDB RDS for MySQL インスタンスは、スキーマ移行、フルデータ移行、増分データ移行をサポートしています。

  • ソースデータベースからターゲットデータベースにアカウントを移行する場合は、前提条件と注意事項を確認する必要があります。詳細については、「データベースアカウントの移行」をご参照ください。

  • DTS タスクの実行に失敗した場合、DTS テクニカルサポートは 8 時間以内にタスクの復元を試みます。復元中、タスクが再起動され、タスクのパラメータが変更される可能性があります。

    説明

    タスクのパラメータのみが変更される可能性があります。データベースのパラメータは変更されません。 変更される可能性のあるパラメータには、「DTS インスタンスのパラメータの変更」トピックの「インスタンスパラメータの変更」セクションのパラメータが含まれますが、これらに限定されません。

特殊なケース

  • ソースデータベースが自己管理 MySQL データベースの場合は、以下の制限に注意してください。

    • データ移行タスクの実行中にソースデータベースでプライマリ/セカンダリスイッチオーバーを実行すると、タスクは失敗します。

    • DTS は、ターゲットデータベースの最後に移行されたデータのタイムスタンプとソースデータベースの現在のタイムスタンプに基づいて移行レイテンシを計算します。ソースデータベースで DML 操作が長時間実行されない場合、移行レイテンシが不正確になる可能性があります。データ移行タスクのレイテンシが過度に高い場合は、ソースデータベースで DML 操作を実行してレイテンシを更新できます。

      説明

      移行対象のオブジェクトとしてデータベース全体を選択した場合は、ハートビートテーブルを作成できます。ハートビートテーブルは毎秒更新またはデータを受信します。

    • DTS は、バイナリログファイルの位置を進めるために、スケジュールどおりにソースデータベースで CREATE DATABASE IF NOT EXISTS `test` 文を実行します。

  • ソースデータベースが Apsara RDS for MySQL インスタンスの場合は、以下の制限に注意してください。

    • 増分データ移行では、読み取り専用 ApsaraDB RDS for MySQL V5.6 インスタンスなど、トランザクションログを記録しない ApsaraDB RDS for MySQL インスタンスをソースデータベースとして使用できません。

    • DTS は、バイナリログファイルの位置を進めるために、スケジュールどおりにソースデータベースで CREATE DATABASE IF NOT EXISTS `test` 文を実行します。

  • ターゲットデータベースが ApsaraDB RDS for MySQL インスタンスの場合は、以下の制限に注意してください。

    DTS は、ターゲット ApsaraDB RDS for MySQL インスタンスにデータベースを自動的に作成します。ただし、ソースデータベースの名前が ApsaraDB RDS for MySQL のデータベース命名規則に準拠していない場合は、データ移行タスクを構成する前に、ターゲット ApsaraDB RDS for MySQL インスタンスにデータベースを手動で作成する必要があります。詳細については、「データベースの管理」をご参照ください。

課金

移行タイプ

インスタンス構成料金

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

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

無料。

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

増分データ移行

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

移行タイプ

  • スキーマ移行

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

    説明
    • DTS は、テーブル、ビュー、トリガー、ストアドプロシージャ、ストアドファンクションなどのオブジェクトタイプのスキーマ移行をサポートしています。

      説明

      移行中に、ストアドプロシージャの routine_body、ストアドファンクションの routine_body、ビューの select_statement を変更することはできません。

    • スキーマ移行中、DTS はビュー、ストアドプロシージャ、およびファンクションの SECURITY 属性の値を DEFINER から INVOKER に変更します。さらに、DTS は DEFINER を移行で使用されるターゲットデータベースアカウントに設定します。

      説明

      移行中に SECURITY 属性と DEFINER を変更することはできません。

    • DTS はユーザー情報を移行しません。ターゲットデータベースのビュー、ストアドプロシージャ、またはストアドファンクションを呼び出すには、INVOKER に読み取りおよび書き込み権限を付与する必要があります。

  • フルデータ移行

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

  • 増分データ移行

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

増分移行をサポートする SQL 操作

操作タイプ

SQL 文

DML

INSERT、UPDATE、DELETE

DDL

  • ALTER TABLE と ALTER VIEW

  • CREATE FUNCTION、CREATE INDEX、CREATE PROCEDURE、CREATE TABLE、CREATE VIEW

  • DROP INDEX と DROP TABLE

  • RENAME TABLE

    重要

    RENAME TABLE 操作により、ソースデータベースとターゲットデータベース間でデータの不整合が発生する可能性があります。たとえば、移行対象のオブジェクトとしてテーブルを選択し、データ移行中にテーブルの名前を変更すると、そのテーブルのデータはターゲットデータベースに移行されません。このような状況を防ぐには、データ移行タスクを構成する際に、このテーブルが属するデータベースを移行対象のオブジェクトとして選択できます。RENAME TABLE 操作の前後でテーブルが属するデータベースが、移行対象のオブジェクトに追加されていることを確認してください。

  • TRUNCATE TABLE

手順

  1. 以下のいずれかの方法を使用して、データ移行ページに移動し、データ移行インスタンスが存在するリージョンを選択します。

    DTS コンソール

    1. DTS コンソール にログインします。

    2. 左側のナビゲーションウィンドウで、データの移行 をクリックします。

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

    DMS コンソール

    説明

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

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

    2. 上部のナビゲーションバーで、ポインタを [データ + AI] > [DTS (DTS)] > [データ移行] に重ねます。

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

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

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

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

    • 新しいバージョンと以前のバージョンの構成ページでは、特定のパラメータが異なる場合があります。新しいバージョンの構成ページを使用することをお勧めします。

  4. ソースデータベースとターゲットデータベースを構成します。次の表にパラメータを示します。

    警告

    ソースデータベースとターゲットデータベースを構成した後、ページの上部に表示される [制限] を読むことをお勧めします。そうでない場合、タスクが失敗したり、データの不整合が発生したりする可能性があります。

    セクション

    パラメータ

    説明

    なし

    タスク名

    DTS タスクの名前。DTS はタスク名を自動的に生成します。タスクを識別しやすいわかりやすい名前を指定することをお勧めします。一意のタスク名を指定する必要はありません。

    ソースデータベース

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

    この例では、データベースインスタンスは選択されていません。以下のデータベース情報を構成します。

    データベースタイプ

    ソースデータベースのタイプ。[MySQL] を選択します。

    アクセス方法

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

    インスタンスリージョン

    ソース ApsaraDB RDS for MySQL インスタンスが存在するリージョン。

    Alibaba Cloudアカウント全体でのデータの複製

    Alibaba Cloud アカウント間でデータを移行するかどうかを指定します。この例では、[いいえ] が選択されています。

    説明

    Alibaba Cloud アカウント間でデータを移行する場合は、[はい] を選択します。詳細については、「Alibaba Cloud アカウントを跨いでの DTS タスクの構成」をご参照ください。

    [RDS インスタンス ID]

    ソース ApsaraDB RDS for MySQL インスタンスの ID。

    説明

    ソースとデスティネーションの ApsaraDB RDS for MySQL インスタンスは、同じでも異なっていても構いません。DTS を使用して、ApsaraDB RDS for MySQL インスタンス内または 2 つの ApsaraDB RDS for MySQL インスタンス間でデータを移行できます。

    データベースアカウント

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

    データベースパスワード

    データベースインスタンスへのアクセスに使用するパスワード。

    暗号化

    ソースデータベースインスタンスへの接続を暗号化するかどうかを指定します。ビジネス要件に基づいて、[非暗号化] または [SSL 暗号化] を選択します。このパラメータを [SSL 暗号化] に設定する場合は、DTS タスクを構成する前に、ApsaraDB RDS for MySQL インスタンスで SSL 暗号化を有効にする必要があります。詳細については、「クラウド証明書を使用して SSL 暗号化を有効にする」をご参照ください。

    宛先データベース

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

    この例では、データベースインスタンスは選択されていません。以下のデータベース情報を構成します。

    データベースタイプ

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

    アクセス方法

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

    インスタンスリージョン

    ターゲット ApsaraDB RDS for MySQL インスタンスが存在するリージョン。

    Alibaba Cloud アカウント間でデータを複製

    Alibaba Cloud アカウント間でデータを移行するかどうかを指定します。この例では、[いいえ] が選択されています。

    [RDS インスタンス ID]

    ターゲット ApsaraDB RDS for MySQL インスタンスの ID。

    説明

    ソースとデスティネーションの ApsaraDB RDS for MySQL インスタンスは、同じでも異なっていても構いません。DTS を使用して、ApsaraDB RDS for MySQL インスタンス内または 2 つの ApsaraDB RDS for MySQL インスタンス間でデータを移行できます。

    データベースアカウント

    ターゲット ApsaraDB RDS for MariaDB インスタンスのデータベースアカウント。必要なアカウント権限の詳細については、この Topic の「データベースアカウントに必要な権限」セクションをご参照ください。

    データベースパスワード

    データベースインスタンスへのアクセスに使用するパスワード。

    暗号化

    ソースデータベースインスタンスへの接続を暗号化するかどうかを指定します。ビジネス要件に基づいて、[非暗号化] または [SSL 暗号化] を選択します。このパラメータを [SSL 暗号化] に設定する場合は、DTS タスクを構成する前に、ApsaraDB RDS for MySQL インスタンスで SSL 暗号化を有効にする必要があります。詳細については、「クラウド証明書を使用して SSL 暗号化を有効にする」をご参照ください。

  5. ページの下部にある [接続テストと続行] をクリックします。

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

    警告

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

  6. 移行するオブジェクトを構成します。

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

      パラメータ

      説明

      移行タイプ

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

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

      説明
      • [スキーマ移行] を選択しない場合は、データを受信するためのデータベースとテーブルがターゲットデータベースに作成され、[選択したオブジェクト] でオブジェクト名マッピング機能が有効になっていることを確認してください。

      • [増分データ移行] を選択しない場合は、データ移行中にソースデータベースにデータを書き込まないことをお勧めします。これにより、ソースデータベースとターゲットデータベース間でデータの整合性が確保されます。

      移行元データベースのトリガーを移行する方法

      ソースデータベースからトリガーを移行するために使用される方法。ビジネス要件に基づいて移行方法を選択できます。移行するトリガーがない場合は、このパラメータを構成する必要はありません。詳細については、「ソースデータベースからトリガーを同期または移行する」をご参照ください。

      説明

      このパラメータは、移行タイプスキーマ移行増分データ移行 の両方を選択した場合にのみ使用できます。

      移行評価の有効化

      移行評価を有効にするかどうかを指定します。移行評価は、インデックスの長さ、ストアドプロシージャ、依存テーブルなど、ソースデータベースとターゲットデータベースのスキーマが要件を満たしているかどうかを確認することを目的としています。ビジネス要件に基づいて、 または × を選択できます。

      説明
      • このパラメータは、移行タイプスキーマ移行 を選択した場合にのみ構成できます。

      • を選択すると、事前チェックに時間がかかる場合があります。事前チェック中に 評価結果 を表示できます。評価結果は事前チェックの結果には影響しません。

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

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

        説明

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

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

        警告

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

        • ソースデータベースとターゲットデータベースのスキーマが同じで、データレコードのプライマリキーがターゲットデータベースの既存のデータレコードと同じである場合、以下のシナリオが発生する可能性があります。

          • フルデータ移行中、DTS はデータレコードをターゲットデータベースに移行しません。ターゲットデータベースの既存のデータレコードは保持されます。

          • 増分データ移行中、DTS はデータレコードをターゲットデータベースに移行します。ターゲットデータベースの既存のデータレコードは上書きされます。

        • ソースデータベースとターゲットデータベースのスキーマが異なる場合、特定の列のみが移行されるか、データ移行タスクが失敗します。注意して進めてください。

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

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

      ソースオブジェクト

      ソースオブジェクト セクションから 1 つ以上のオブジェクトを選択します。向右小箭头 アイコンをクリックして、選択中のオブジェクト セクションにオブジェクトを追加します。

      説明

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

      選択中のオブジェクト

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

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

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

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

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

    2. 次へ:詳細設定 をクリックして、詳細設定を構成します。

      パラメータ

      説明

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

      デフォルトでは、専用クラスターを指定しない場合、DTS はデータ移行タスクを共有クラスターにスケジュールします。データ移行タスクの安定性を向上させるには、専用クラスターを購入します。詳細については、「DTS 専用クラスターとは」をご参照ください。

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

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

      重要

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

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

        説明

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

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

        説明

        このオプションを選択すると、ターゲットデータベースのテーブルがロックされる可能性があります。

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

        説明

        このオプションを選択すると、ターゲットデータベースのテーブルがロックされる可能性があります。

      アカウントを移行

      ソースデータベースのアカウント情報を移行するかどうかを指定します。ビジネス要件に基づいてこのパラメータを構成できます。 を選択した場合は、移行するアカウントを選択し、データ移行タスクで使用されるソースデータベースとターゲットデータベースのアカウントの権限を確認する必要があります。

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

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

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

      • DTS が接続を再試行すると、DTS インスタンスの料金が発生します。ビジネス要件に基づいてリトライ時間範囲を指定することをお勧めします。また、ソースデータベースとターゲットインスタンスが解放された後、できるだけ早く DTS インスタンスを解放することもできます。

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

      その他の問題のリトライ時間の範囲。たとえば、データ移行タスクの開始後に DDL または DML 操作の実行に失敗した場合、DTS はリトライ時間範囲内で直ちに操作を再試行します。有効な値: 1 ~ 1440。単位: 分。デフォルト値: 10。パラメータを 10 より大きい値に設定することをお勧めします。指定されたリトライ時間範囲内に失敗した操作が正常に実行された場合、DTS はデータ移行タスクを再開します。そうでない場合、データ移行タスクは失敗します。

      重要

      移行元データベースと移行先データベースで他の問題が発生した場合の、再試行までの待機時間です。 パラメータの値は、失敗した接続の再試行時間 パラメータの値よりも小さくなければなりません。

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

      フルデータ移行のスロットリングを有効にするかどうかを指定します。フルデータ移行中、DTS はソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを使用します。これにより、データベースサーバーの負荷が増加する可能性があります。ビジネス要件に基づいて、フルデータ移行のスロットリングを有効にできます。スロットリングを構成するには、1 秒あたりのソースデータベースのクエリ率 QPS1 秒あたりの完全移行の行数 RPS1 秒あたりの完全移行データ量 (MB) BPS パラメータを構成する必要があります。これにより、ターゲットデータベースサーバーの負荷が軽減されます。

      説明

      このパラメータは、移行タイプ パラメータで 完全データ移行 を選択した場合にのみ構成できます。

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

      増分データ移行のスロットリングを有効にするかどうかを指定します。スロットリングを構成するには、1 秒あたりの増分移行の行数 RPS1 秒あたりの増分移行データ量 (MB) BPS パラメータを構成する必要があります。これにより、ターゲットデータベースサーバーの負荷が軽減されます。

      説明

      このパラメータは、移行タイプ パラメータで 増分データ移行 を選択した場合にのみ構成できます。

      環境タグ

      DTS インスタンスを識別するために使用される環境タグ。ビジネス要件に基づいて環境タグを選択できます。この例では、環境タグは選択されていません。

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

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

      • [はい]: ハートビートテーブルの SQL 操作を書き込みません。この場合、DTS インスタンスのレイテンシが表示される場合があります。

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

      ETL の設定

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

      監視アラート

      データ移行タスクのアラートを構成するかどうかを指定します。タスクが失敗した場合、または移行レイテンシが指定されたしきい値を超えた場合、アラート連絡先に通知が送信されます。有効な値:

      • [いいえ]: アラートを構成しません。

      • [はい]: アラートを構成します。この場合、アラートしきい値と アラート通知設定 も構成する必要があります。詳細については、「監視とアラートの構成」トピックの「DTS タスクの作成時に監視とアラートを構成する」セクションをご参照ください。

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

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

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

    • DTS タスクを構成するために関連する API 操作を呼び出すときに指定するパラメータを表示するには、次:タスク設定の保存と事前チェック にポインタを重ね、OpenAPI パラメーターのプレビュー をクリックします。

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

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

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

    • 事前チェック中に項目のアラートがトリガーされた場合:

      • アラート項目を無視できない場合は、失敗した項目の横にある [詳細の表示] をクリックして、問題をトラブルシューティングします。その後、事前チェックを再度実行します。

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

  8. データ移行インスタンスを購入します。

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

    2. [インスタンスの購入] ページで、データ移行インスタンスの [インスタンスクラス] パラメータを構成します。次の表にパラメータを示します。

      セクション

      パラメータ

      説明

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

      [リソースグループ]

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

      インスタンスクラス

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

    3. チェックボックスをオンにして、[Data Transmission Service (従量課金制) サービス規約] を読んで同意します。

    4. [購入して開始] をクリックします。表示されるメッセージで、[OK] をクリックします。

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

      説明
      • データ移行タスクを増分データの移行に使用できない場合、タスクは自動的に停止します。[ステータス] セクションに [完了] と表示されます。

      • データ移行タスクを増分データの移行に使用できる場合、タスクは自動的に停止しません。増分データ移行タスクは停止または完了しません。[ステータス] セクションに [実行中] と表示されます。