すべてのプロダクト
Search

このプロダクト

    Data Transmission Service:セルフマネージド MySQL を RDS for MySQL に移行する

    ドキュメントセンター

    Data Transmission Service:セルフマネージド MySQL を RDS for MySQL に移行する

    最終更新日:Jul 18, 2026

    Data Transmission Service (DTS) は、ダウンタイムなしで、オンプレミス、ECS インスタンス上、またはサードパーティのクラウドプラットフォーム上の MySQL データベースから ApsaraDB RDS for MySQL インスタンスへデータを移行します。DTS はスキーマ移行、完全なデータ移行、および増分データ移行をサポートしています。これらのタイプを組み合わせることで、アプリケーションのダウンタイムなしに移行を完了できます。

    前提条件

    • ご利用の自己管理 MySQL データベースが Alibaba Cloud に接続されており、DTS サーバーの CIDR ブロックがデータベースのセキュリティ設定（セキュリティグループ、ファイアウォール、ホワイトリスト）に追加されています。事前準備。

      説明

      サポートされているバージョンについては、「移行ソリューション」をご参照ください。

    • 増分データ移行が必要な場合、ご利用の自己管理 MySQL データベースでバイナリロギングが有効になっている必要があります。自己管理 MySQL データベース用アカウントの作成とバイナリログの設定。

    • ターゲットの ApsaraDB RDS for MySQL インスタンスが作成済みで、ソースデータベースが使用しているストレージ容量よりも多くのストレージを確保している必要があります。ApsaraDB RDS for MySQL インスタンスの作成。

    注意事項

    説明

    • DTS はスキーマ移行中に外部キーを移行します。

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

    タイプ

    説明

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

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

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

    • 移行オブジェクトとしてテーブルを選択し、列名のマッピングなど編集を行う場合、1 つの移行タスクで最大 1,000 のテーブルをサポートします。この上限を超えると、タスク送信時にエラーが発生して失敗します。これを修正するには、複数のタスクに分割するか、データベース全体の移行タスクを構成してください。

    • 増分移行が必要な場合、バイナリロギングを有効にしてください：

      • binlog_format を ROW に、binlog_row_image を FULL に設定します。そうでない場合、事前チェックに失敗し、タスクを開始できません。

        重要

        ソースの自己管理 MySQL がデュアルマスタクラスター（各インスタンスがマスタかつスレーブの役割を果たす）である場合、log_slave_updates パラメーターを有効にしてください。これにより、DTS がすべてのバイナリログを読み取れるようになります。

      • RDS for MySQL インスタンスの場合、ローカルバイナリログを少なくとも 3 日間（推奨は 7 日間）保持する必要があります。自己管理 MySQL データベースの場合、ローカルバイナリログを少なくとも 7 日間保持する必要があります。DTS がバイナリログにアクセスできない場合、タスクは失敗します。最悪の場合、データの不整合やデータ損失が発生する可能性があります。DTS が要求するよりも短いバイナリログ保持期間に起因する問題は、DTS SLA の対象外です。

        説明

        RDS for MySQL インスタンス上でローカルバイナリログの保持期間を設定する方法については、「ローカルログの自動削除」をご参照ください。

    • ソースデータベースで許可されない操作：

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

        説明

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

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

    • DTS は、バイナリログに書き込まれない変更によって生成されたデータを移行しません。例として、物理バックアップからの復元データやカスケード操作で作成されたデータが該当します。

      説明

      このような状況が発生した場合は、ビジネス上の許容範囲内で再度完全移行を実行してください。

    • ソースの MySQL データベースがバージョン 8.0.23 以降で、非表示の隠しカラムが含まれている場合、DTS はそれらのカラムを読み取ることができません。これによりデータ損失が発生する可能性があります。

      説明

      隠しカラムを表示可能にするには、ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; を実行してください。詳細については、「Invisible Columns」をご参照ください。

    • MySQL 互換性：DTS が MySQL ファミリーのソースデータベースからデータを移行する際は、標準 MySQL プロトコルおよび Binlog フォーマットに依存しており、標準 MySQL と互換性のない動作はサポートされていません。ソースデータベースが MySQL 互換を謳っていても MySQL とは異なる動作をする場合（例：OceanBase を MySQL モードでソースとして接続した際に、Binlog の末尾 rotate イベントのタイムスタンプが 0 になるなど）、DTS 移行タスクが失敗する可能性があります。

    その他の制限事項

    • 互換性を確保するため、ソースおよびターゲットデータベースで同じ MySQL バージョンを使用することを推奨します。

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

    • DTS はコメント構文を使用して定義されたパーサの移行をサポートしていません。

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

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

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

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

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

    • ターゲットの MySQL データベースがバージョン 8.0.23 以降で、ターゲット列が非表示の隠しカラムである場合、DTS はそのカラムにデータを書き込むことができません。これによりタスク失敗またはデータ損失が発生する可能性があります。

      説明

      隠しカラムを表示可能にするには、ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; を実行してください。詳細については、「Invisible Columns」をご参照ください。

    • DTS を使用してスキーマを移行しない場合、フィールドの互換性を自分で確認してください。そうでない場合、タスクが失敗したりデータが失われたりする可能性があります。例えば、ソース列の型が text で、ターゲット列の型が varchar(255) の場合、ソースの大きなフィールドが切り捨てられる可能性があります。

    • データに 4 バイト文字（例：まれな漢字や絵文字）が含まれる場合、ターゲットデータベースおよびテーブルは utf8mb4 文字セットを使用する必要があります。

      説明

      DTS を使用してスキーマを移行する場合、ターゲットデータベースでインスタンスレベルのパラメーター character_set_server を utf8mb4 に設定してください。

    • 移行前に、ソースおよびターゲットデータベースのパフォーマンスを評価してください。移行はビジネストラフィックの少ない時間帯に実行してください。そうでない場合、完全移行により両方のデータベースの読み取りおよび書き込みリソースが消費され、データベース負荷が増加します。

    • 完全移行では INSERT 操作が同時に行われます。これによりターゲットテーブルがフラグメント化します。完全移行後、ターゲットテーブルにはソーステーブルよりも多くのストレージスペースが必要になります。

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

    • DTS は失敗したタスクを 7 日以内に回復しようと試みます。トラフィックをターゲットインスタンスに切り替える前に、タスクを終了または解放するか、revoke コマンドを実行して、ターゲットインスタンスアカウントに対する DTS の書き込み権限を取り消してください。これにより、自動回復によってターゲットデータがソースデータで上書きされるのを防げます。

    • ターゲットデータベースで DDL 書き込みが失敗した場合でも、DTS タスクは継続して実行されます。失敗した DDL ステートメントはタスクログで確認してください。手順については、「タスクログの表示」をご参照ください。

    • ターゲットの MySQL データベースの同じテーブルに、大文字小文字が異なるが名前が同一のカラムを書き込む場合、予期しない結果が発生する可能性があります。MySQL のカラム名は大文字小文字を区別しません。

    • 移行が完了し（タスクステータスが ステータス から 完了 に変化した後）、analyze table <table_name> を実行して、すべてのデータがターゲットテーブルに書き込まれていることを確認してください。例えば、ターゲットの MySQL データベースで高可用性 (HA) スイッチオーバーが発生した後、データがメモリ内に残ったままディスクに書き込まれず、データ損失が発生する可能性があります。

    • RDS for MySQL インスタンスで Always-Encrypted が有効になっている場合、完全移行はサポートされません。

      説明

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

    • ソースからデータベースアカウントを移行するには、必要な前提条件を満たし、関連する考慮事項を確認する必要があります。詳細については、「データベースアカウントの移行」をご参照ください。

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

      説明

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

    特殊なケース

    • 自己管理 MySQL ソースの場合：

      • ソースデータベースでマスタ–スタンバイスイッチオーバーが発生すると、移行タスクは失敗します。

      • DTS は、宛先データベースに最後に移行されたレコードのタイムスタンプと現在時刻を比較することで遅延を計算します。ソースで長時間 DML 操作が実行されない場合、遅延レポートが不正確になります。遅延が高すぎると思われる場合は、ソースで DML 操作を実行して遅延値を更新してください。

        説明

        データベース全体の移行を選択する場合、ハートビートテーブルを作成し、毎秒更新または書き込みを行ってください。

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

      • Amazon Aurora MySQL または他のクラスター化された MySQL インスタンスをソースとして使用する場合、タスクに設定されたドメイン名または IP アドレスおよびその DNS 解決が常に読み取り–書き込み (RW) ノードを指していることを確認してください。そうでない場合、移行タスクが失敗する可能性があります。

    • RDS for MySQL ソースの場合：

      • 増分移行が必要な場合、トランザクションログを記録しない RDS for MySQL インスタンス（例：RDS for MySQL 5.6 読み取り専用インスタンス）はソースとしてサポートされていません。

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

    • RDS for MySQL 宛先の場合：

      DTS は RDS for MySQL に自動的にデータベースを作成します。データベース名が RDS for MySQL の命名規則に準拠していない場合、移行タスクを構成する前に手動でデータベースを作成してください。手順については、「データベースの管理」をご参照ください。

    課金

    移行タイプ

    インスタンス構成料金

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

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

    無料です。

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

    増分データ移行

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

    移行タイプ

    • スキーマ移行

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

      • DTS は、テーブル、ビュー、トリガー、ストアドプロシージャ、および関数のスキーマ移行をサポートしています。

        説明

        ストアドプロシージャの routine_body、関数の routine_body、およびビューの select_statement は変更されません。

      • スキーマ移行中、DTS は移行対象のビュー、ストアドプロシージャ、および関数の `DEFINER` を `INVOKER` に変更します。これにより、`SQL SECURITY` の値が `INVOKER` に変更されます。また、DTS は `DEFINER` を移行タスクに使用するターゲットデータベースアカウントに設定します。

        説明

        ソースデータベースのセキュリティ認証方法および definer は変更されません。

      • DTS はユーザー情報を移行しないため、ターゲットデータベースでビュー、ストアドプロシージャ、および関数を呼び出すには、呼び出し側に読み取りおよび書き込み権限を付与する必要があります。

    • 完全移行

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

    • TRUNCATE TABLE

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

    データベース

    スキーマ移行

    完全移行

    増分移行

    自己管理 MySQL データベース

    SELECT 権限

    SELECT 権限

    • 移行対象オブジェクトに対する SELECT 権限。

    • REPLICATION CLIENT、REPLICATION SLAVE、および SHOW VIEW 権限。

    • CREATE 権限（DTS がバイナリログ位置を進めるために test という名前のデータベースを作成できるようにするため）。

    ApsaraDB RDS for MySQL インスタンス

    読み取りおよび書き込み権限

    データベースアカウントを作成および承認するには：

    説明

    アカウント情報を移行するには、移行タスクアカウントに追加の権限が必要です。「データベースアカウントの移行」をご参照ください。

    操作手順

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

      ソースデータベース

      既存の接続情報の選択

      既存の接続は不要です。以下にデータベース情報を設定してください。

      データベースタイプ

      MySQL を選択します。

      アクセス方法

      ソースデータベースのアクセス方法を選択します。この例では パブリック IP アドレス を使用します。

      説明

      ソースデータベースが自己管理の場合、必要な事前準備も完了する必要があります。

      インスタンスのリージョン

      ソース MySQL データベースのリージョンを選択します。

      ドメイン名または IP アドレス

      ソース MySQL データベースのエンドポイントを入力します。この例ではパブリックエンドポイントを使用します。

      ポート番号

      ソース MySQL データベースのサービスポートを入力します。ポートはインターネット経由でアクセス可能である必要があります。デフォルト：3306。

      データベースアカウント

      ソース MySQL データベースのアカウントを入力します。必要な権限：「データベースアカウントに必要な権限」。

      データベースのパスワード

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

      暗号化

      必要に応じて 非暗号化 または SSL 暗号化 を選択します。

      • 自己管理 MySQL データベースで SSL 暗号化が有効になっていない場合、非暗号化 を選択します。

      • 自己管理 MySQL データベースで SSL 暗号化が有効になっている場合、SSL 暗号化 を選択します。また、CA 証明書 をアップロードし、CA 証明書パスワード を入力する必要があります。

      宛先データベース

      既存の接続情報の選択

      既存の接続は不要です。以下にデータベース情報を設定してください。

      データベースタイプ

      MySQL を選択します。

      アクセス方法

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

      インスタンスのリージョン

      ターゲットの ApsaraDB RDS for MySQL インスタンスのリージョンを選択します。

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

      この例では同じ Alibaba Cloud アカウントを使用します。× を選択します。

      RDS インスタンス ID

      ターゲットの ApsaraDB RDS for MySQL インスタンス ID を選択します。

      データベースアカウント

      ターゲットの ApsaraDB RDS for MySQL インスタンスのデータベースアカウントを入力します。必要な権限：「データベースアカウントに必要な権限」。

      データベースのパスワード

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

      暗号化

      データベース要件に基づいて 非暗号化 または SSL 暗号化 を選択します。SSL 暗号化 に設定する場合、事前に RDS for MySQL インスタンスで SSL 暗号化を有効にしておく必要があります。詳細については、「クラウド証明書を使用した SSL 暗号化の迅速な有効化」をご参照ください。

    4. 設定を完了したら、ページ下部の 接続をテストして続行 をクリックします。表示される DTS サーバーの CIDR ブロック ダイアログボックスで、接続テスト をクリックします。

      説明

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

    5. タスクオブジェクトを設定します。

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

        パラメーター

        説明

        移行タイプ

        • 完全移行のみを実行する必要がある場合、スキーマ移行 および 完全データ移行 の両方を選択します。

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

        説明

        • スキーマ移行 を選択しない場合、ターゲットデータベースにデータを受信するためのデータベースおよびテーブルが存在することを確認する必要があります。選択中のオブジェクト ボックスでオブジェクト名マッピング機能を使用することもできます。

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

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

        トリガー移行方法を選択します。トリガーが関与しない場合はスキップしてください。「トリガーの同期または移行方法の設定」。

        説明

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

        移行評価の有効化

        ソースおよびターゲットのスキーマ（インデックス長、ストアドプロシージャ、依存テーブル）が要件を満たしているかどうかを評価します。ニーズに応じて ○ または × を選択します。

        説明

        • 移行タイプ で スキーマ移行 を選択している場合にのみ、このパラメーターを設定できます。

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

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

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

          説明

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

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

          警告

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

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

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

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

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

        イベントを移行するかどうか

        ソースデータベースのイベントを移行するかどうかを選択します。○ を選択する場合、追加の手順が必要です。「イベントの同期または移行」。

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

        ターゲットインスタンスでの移行オブジェクト（データベース、テーブル、カラムなど）の名前の大文字小文字の扱いポリシーを設定できます。デフォルトでは DTS のデフォルトポリシー が選択されています。ソースまたはターゲットデータベースのデフォルトポリシーに合わせることもできます。詳細については、「ターゲットデータベースでのオブジェクト名の大文字小文字の扱い」をご参照ください。

        ソースオブジェクト

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

        説明

        移行オブジェクトの選択粒度は、データベース、テーブル、カラムです。テーブルまたはカラムのみを移行オブジェクトとして選択した場合、ビュー、トリガー、ストアドプロシージャなどの他のオブジェクトはターゲットデータベースに移行されません。

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

        • オブジェクト名マッピングにより、依存オブジェクトの移行が失敗する可能性があります。

        • WHERE 条件で移行データをフィルターするには、選択中のオブジェクト セクション内のテーブルを右クリックして条件を設定します。「移行するデータのフィルター」。

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

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

        パラメーター

        説明

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

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

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

        ソースデータベースで Data Management (DMS) または gh-ost を使用してオンライン DDL 変更を実行する場合、オンライン 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 機能を設定します。また、テキストボックスにデータ処理ステートメントを入力する必要があります。

        • ×：ETL 機能を設定しません。

        監視アラート

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

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

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

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

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

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

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

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

      説明

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

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

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

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

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

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

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

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

        カテゴリ

        パラメーター

        説明

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

        リソースグループの設定

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

        インスタンスクラス

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

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

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

        移行タスクページでタスクの進行状況を確認します。

        説明

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

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

        • ワークロードを切り替える場合は、移行遅延が低いかゼロのビジネストラフィックの少ない時間帯に行ってください。「ワークロードの切り替え」。

    よくある質問

    Q：インスタンスの実行開始後、順方向および逆方向タスクのハートビートテーブル SQL を削除 を変更できますか？

    A：いいえ。