すべてのプロダクト
Search

このプロダクト

    ApsaraDB RDS:自己管理 MySQL データベースから ApsaraDB RDS for MySQL インスタンスへのデータ移行

    ドキュメントセンター

    ApsaraDB RDS:自己管理 MySQL データベースから ApsaraDB RDS for MySQL インスタンスへのデータ移行

    最終更新日:Sep 16, 2025

    Data Transmission Service (DTS) を使用すると、オンプレミスのデータセンター、Elastic Compute Service (ECS) インスタンス、または他のクラウドにある自己管理 MySQL データベースを、ダウンタイムを最小限に抑えるか、ゼロダウンタイムで ApsaraDB RDS for MySQL に移行できます。

    前提条件

    • ソースの自己管理 MySQL データベースは、MySQL 5.1、5.5、5.6、5.7、または 8.0 を実行している必要があります。

    • 宛先の RDS for MySQL インスタンスは、ソースの 自己管理 データベースよりも多くの利用可能なストレージ容量を持っている必要があります。

    移行ソリューションの概要

    DTS は、以下の 3 つの移行タイプを提供します。

    • スキーマ移行: データベース、テーブル、ビュー、トリガー、ストアドプロシージャ、および関数のスキーマを移行します。

    • 完全なデータ移行: ソースデータベースからすべての既存データを移行します。

    • 増分データ移行: 完全なデータ移行が開始された後に発生する変更をキャプチャし、ソースデータベースから宛先 RDS インスタンスに増分データを移行します。

    アプリケーションのスムーズでゼロダウンタイムの移行を実現するために、ソリューションにスキーマ移行、完全なデータ移行、および増分データ移行を組み合わせることをお勧めします。

    一般的な移行ソリューション

    移行ソリューション

    ダウンタイム

    データ整合性

    コスト

    ユースケース

    スキーマ + 完全 + 増分データ移行 (推奨)

    ゼロダウンタイム

    移行中にソースにデータが書き込まれるかどうかに関わらず、移行完了後に一貫性が保たれます。

    有料

    • 移行のダウンタイムがゼロまたは最小限であることが要求されるビジネス。

    • 本番環境。

    スキーマ + 完全データ移行

    完全なデータ移行に必要な時間によります

    • 移行中にソースにデータが書き込まれる場合、不整合になります。

    • 移行中にソースにデータが書き込まれない場合、一貫性が保たれます。

    無料

    • 移行のダウンタイムを許容できるビジネス。

    • テスト環境。

    課金

    DTS を使用してソースデータベースから RDS for MySQL インスタンスにデータを移行する場合、スキーマ移行、完全なデータ移行、およびパブリックネットワークトラフィックは無料です。課金対象となるのは以下の項目のみです。

    • 増分データ移行: 増分移行が実行されている間、課金されます。増分データ移行が一時停止または失敗した場合は課金されません。

    • データ検証: データ検証料金が課金されます。

    制限事項

    • プライマリキー: 移行するすべてのテーブルには、プライマリキーまたは一意の値を持つ一意制約が必要です。そうしないと、宛先 RDS インスタンスに重複データが含まれる可能性があります。

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

    • DML: 完全なデータ移行のみを実行する場合、移行中に DML を使用してソースデータベースに新しいデータを書き込まないでください。そうしないと、ソースと宛先のデータが不整合になります。

    • テーブル数: 列名のマッピングを編集する必要がある場合、1 つの移行タスクで最大 1,000 テーブルを移行できます。より多くのテーブルを移行するには、さらに移行タスクを作成してください。

    • 文字セット: 移行するデータに、珍しい文字や絵文字などの 4 バイト文字が含まれている場合、宛先 RDS インスタンスとそのテーブルは utf8mb4 文字セットを使用する必要があります。スキーマ移行の場合、宛先 RDS インスタンスの character_set_server パラメーターを utf8mb4 に設定します。

    • データベースアカウント: ソースデータベースからアカウントを移行するには、移行に使用するアカウントがデータベースアカウントの移行で説明されている要件を満たしているかどうかを確認する必要があります。

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

    • MySQL 8.0 の不可視列: ソースデータベースが MySQL 8.0.23 以降を実行しており、プライマリキーのないテーブルに対して自動的に生成されたものを含む不可視列が含まれている場合、まず ALTER TABLE ... ALTER COLUMN ... SET VISIBLE; を実行してそれらを可視にする必要があります。そうしないと、移行中にデータが失われます。

    • 移行できないコンテンツ:

      • コメント構文を使用して定義されたパーサ。

      • 物理バックアップとリカバリ、または外部キーのカスケード操作など、バイナリログに記録されない操作によって生成されたデータ。

    クリックして、より具体的な制限事項を展開します

    タイプ

    説明

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

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

    • 移行するテーブルにはプライマリキーまたは UNIQUE 制約が必要で、フィールドは一意でなければなりません。そうしないと、宛先データベースに重複データが表示される可能性があります。

    • テーブルを移行し、それらを編集する必要がある場合 (たとえば、列名をマッピングする場合)、単一のデータ移行タスクは最大 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 操作を実行しないでください。そうしないと、データ移行タスクは失敗します。

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

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

      説明

      これが発生した場合、ビジネスが許すときに完全なデータを再度移行できます。

    • ソースデータベースが MySQL 8.0.23 以降で、移行するデータに不可視列が含まれている場合、これらの列のデータが取得できないため、データ損失が発生する可能性があります。

      説明

      • ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; コマンドを実行して、不可視列を可視にすることができます。詳細については、「不可視列」をご参照ください。

      • プライマリキーのないテーブルは、自動的に不可視のプライマリキーを生成します。この不可視のプライマリキーも可視にする必要があります。詳細については、「生成された不可視のプライマリキー」をご参照ください。

    その他の制限

    • 互換性を確保するために、ソースデータベースと宛先データベースの MySQL バージョンを同じに保ちます。

    • 複数のテーブルをマージするなど、一時テーブルを使用するオンライン DDL 操作がソースデータベースで実行されると、宛先データベースでデータ損失が発生したり、移行インスタンスが失敗したりする可能性があります。

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

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

      • ソースデータベースと宛先データベースのスキーマが同じで、データレコードが宛先データベースの既存のデータレコードと同じプライマリキーを持つ場合、次のシナリオが発生する可能性があります。

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

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

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

    • 宛先データベースが MySQL 8.0.23 以降で、ターゲット列が不可視列である場合、データを書き込むためのターゲット列が見つからないため、DTS インスタンスが失敗したり、データ損失が発生したりする可能性があります。

      説明

      • ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; コマンドを実行して、不可視列を可視にすることができます。詳細については、「不可視列」をご参照ください。

      • プライマリキーのないテーブルは、自動的に不可視のプライマリキーを生成します。この不可視のプライマリキーも可視にする必要があります。詳細については、「生成された不可視のプライマリキー」をご参照ください。

    • DTS スキーマ移行機能を使用しない場合は、フィールドの互換性を自分で確認する必要があります。そうしないと、インスタンスが失敗したり、データが失われたりする可能性があります。たとえば、ソーステーブルのフィールドが text 型で、対応する宛先フィールドが varchar(255) の場合、ソーステーブルにラージオブジェクトが含まれていると、データの切り捨てが発生する可能性があります。

    • 移行するデータに、珍しい文字や絵文字など、4 バイトのストレージを必要とするコンテンツが含まれている場合、宛先データベースとテーブルは `utf8mb4` 文字セットを使用する必要があります。

      説明

      DTS を使用してスキーマ移行を行う場合は、宛先データベースのインスタンスレベルのパラメーター character_set_server を `utf8mb4` に設定します。

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

    • 完全なデータ移行には同時 INSERT 操作が含まれ、これにより宛先データベースでテーブルの断片化が発生する可能性があります。完全移行後、宛先データベースのテーブルストレージ領域はソースインスタンスよりも大きくなります。

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

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

    • DDL 文が宛先データベースに書き込めなかった場合、DTS タスクは実行を続けます。タスクログで失敗した DDL 文を確認する必要があります。タスクログの表示方法については、「タスクログのクエリ」をご参照ください。

    • 大文字と小文字のみが異なる名前のフィールドを宛先 MySQL データベースの同じテーブルに書き込むと、MySQL の列名は大文字と小文字を区別しないため、移行結果が期待どおりにならない場合があります。

    • データ移行が完了した後 (インスタンスの ステータス が 完了 になった後)、analyze table <table_name> コマンドを実行して、すべてのデータが宛先テーブルに書き込まれたことを確認します。たとえば、宛先 MySQL データベースでプライマリ/セカンダリのフェールオーバーがトリガーされた場合、データがメモリにのみ書き込まれ、データ損失が発生する可能性があります。

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

      説明

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

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

    • インスタンスが失敗した場合、DTS ヘルプデスクは 8 時間以内にインスタンスを回復しようとします。回復プロセス中、インスタンスが再起動されたり、そのパラメーターが調整されたりする場合があります。

      説明

      パラメーターが調整されると、DTS インスタンスのパラメーターのみが変更され、データベースのパラメーターは変更されません。変更可能なパラメーターには、インスタンスパラメーターの変更で説明されているものが含まれますが、これらに限定されません。

    特殊なケース

    • ソースが自己管理 MySQL データベースの場合:

      • 移行中のソースデータベースでのプライマリ/セカンダリフェールオーバーは、移行タスクの失敗を引き起こします。

      • DTS の待機時間は、最後に移行されたデータレコードの UNIX タイムスタンプと現在の UNIX タイムスタンプを比較して計算されます。ソースデータベースで長時間 DML 操作が実行されない場合、待機時間情報が不正確になることがあります。表示される待機時間が長すぎる場合は、ソースデータベースで DML 操作を実行して待機時間情報を更新できます。

        説明

        データベース全体を移行する場合は、毎秒更新または書き込みが行われるハートビートテーブルを作成することもできます。

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

      • ソースデータベースが Amazon Aurora MySQL インスタンスまたは他のクラスター化された MySQL インスタンスである場合、タスクに構成されたドメイン名または IP アドレスとその解決結果が常に読み取り/書き込み (RW) ノードを指すようにしてください。そうしないと、移行タスクが期待どおりに実行されない可能性があります。

    • ソースが RDS for MySQL インスタンスの場合:

      • 増分データを移行するために、RDS for MySQL 5.6 の読み取り専用インスタンスなど、トランザクションログを記録しない RDS for MySQL インスタンスはソースとして使用できません。

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

    • 宛先が RDS for MySQL インスタンスの場合:

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

    フェーズ 1: 移行の準備

    ステップ 1: DTS にクラウドリソースへのアクセスを承認する

    1. Alibaba Cloud アカウントでクイック承認ページに移動し、[承認] をクリックします。

    2.  EntityAlreadyExists.Role および EntityAlreadyExists.Role.Policy メッセージが表示された場合、承認は完了しています。次のステップに進んでください。

      screenshot_2025-03-21_13-37-47

    ステップ 2: データベースアカウントを作成して承認する

    ソースデータベースのアカウント

    ソースデータベースで次のステートメントを実行して、アカウントを作成します。

    -- ソースデータベースのアカウントを作成します。dts_user と Your_Password123 を実際の値に置き換えてください。
CREATE USER 'dts_user'@'%' IDENTIFIED BY 'Your_Password123';

-- スキーマおよび完全なデータ移行のためのアカウント権限を付与します。
GRANT SELECT ON *.* TO 'dts_user'@'%';

-- 増分データ移行のためのアカウント権限を付与します。
GRANT REPLICATION CLIENT, REPLICATION SLAVE, SHOW VIEW ON *.* TO 'dts_user'@'%';

-- バイナリログファイルの位置を進めるためのハートビートテーブルを作成する権限をアカウントに付与します。
GRANT CREATE ON *.* TO 'dts_user'@'%'; 

FLUSH PRIVILEGES;

    宛先 RDS インスタンスの特権アカウント

    1. RDS コンソールのインスタンスページに移動し、上部でリージョンを選択してから、宛先 RDS インスタンスの ID をクリックします。

    2. 左側のナビゲーションウィンドウで、アカウント管理 をクリックし、次に Create Account をクリックします。

    3. アカウントタイプ: に 特権アカウント を選択し、プロンプトに従って他のパラメーターを構成します。

    また、次の表にリストされている権限を持つ既存のデータベースアカウントを移行に使用することもできます。

    データベースアカウント

    スキーマ移行

    完全なデータ移行

    増分データ移行

    ソースデータベースのアカウント

    SELECT 権限

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

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

    • ソースデータベースにデータベースとテーブルを作成する権限。これらの権限により、DTS はバイナリログの位置を進めるために test データベースを作成できます。

    宛先 RDS インスタンスのアカウント

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

    ステップ 3: ソースデータベースへのアクセスを構成する

    ソースデータベースのアクセス方法を選択し、対応する構成を完了します。

    ソースデータベース

    推奨されるアクセス方法

    構成

    パブリック IP アドレスを持つオンプレミスデータベース

    [パブリック IP]

    詳細については、「DTS サーバーの CIDR ブロックをソースデータベースの IP ホワイトリストに追加する」をご参照ください。

    パブリック IP アドレスのないオンプレミスデータベース

    • [Cloud Enterprise Network (CEN)]

    • [データベースゲートウェイ]

    • [VPN Gateway/Express Connect/Smart Access Gateway (SAG)]

    ECS インスタンスでホストされているデータベース

    [ECS インスタンス]

    手動での構成は不要です。

    ステップ 4: ソースデータベースのバイナリロギングを構成する (増分データ移行のみ)

    増分移行を実行するには、ソースデータベースのバイナリロギングを次のように構成し、MySQL を再起動して構成を有効にする必要があります。

    • ソースデータベースのバイナリロギングを有効にし、ログを少なくとも 7 日間保持します。

    • ソースデータベースの binlog_format パラメーターを row に、binlog_row_image パラメーターを full に設定します。

    • ソースデータベースがデュアルマスタークラスターである場合は、 log_slave_updates パラメーターを有効にして、DTS がすべてのバイナリログを取得できるようにします。

    ソースデータベースのバイナリロギングを構成するには、次の手順に従います。

    Linux

    1.  vim を使用して、 my.cnf ファイル内の次のパラメーターを変更します。

      log_bin=mysql_bin
binlog_format=row

# MySQL 8.0 より前のバージョンの場合、expire_logs_days を構成してバイナリログの保持期間を設定します。デフォルト値: 0 (期限切れなし)。
# MySQL 8.0 以降のバージョンの場合、binlog_expire_logs_seconds を構成してバイナリログの保持期間を設定します。デフォルトは 2592000 秒 (30 日) です。
# 現在のバイナリログ保持期間が 7 日未満の場合、次のパラメーターを構成して 7 日以上にリセットできます。
# expire_logs_days=7
# binlog_expire_logs_seconds=604800

# このパラメーターを 1 より大きい整数に設定します。
server_id=2

# ソースデータベースが 5.6 より後の MySQL バージョンを実行している場合、このパラメーターを設定する必要があります。
binlog_row_image=full

# ソースデータベースがデュアルマスタークラスターである場合、このパラメーターを ON に設定します。
# log_slave_updates=ON

    2. MySQL プロセスを再起動します。

      /etc/init.d/mysqld restart

    Windows

    1.  my.ini ファイル内の次のパラメーターを変更します。

      log_bin=mysql_bin
binlog_format=row

# MySQL 8.0 より前のバージョンの場合、expire_logs_days を構成してバイナリログの保持期間を設定します。デフォルト値: 0 (期限切れなし)。
# MySQL 8.0 以降のバージョンの場合、binlog_expire_logs_seconds を構成してバイナリログの保持期間を設定します。デフォルトは 2592000 秒 (30 日) です。
# 現在のバイナリログ保持期間が 7 日未満の場合、次のパラメーターを構成して 7 日以上にリセットできます。
# expire_logs_days=7
# binlog_expire_logs_seconds=604800

# このパラメーターを 1 より大きい整数に設定します。
server_id=2

# ソースデータベースが 5.6 より後の MySQL バージョンを実行している場合、このパラメーターを設定する必要があります。
binlog_row_image=full

# ソースデータベースがデュアルマスタークラスターである場合、このパラメーターを ON に設定します。
# log_slave_updates=ON

    2. Windows サービスマネージャーから MySQL サービスを再起動するか、次のコマンドを実行します。

      net stop mysql
net start mysql

    フェーズ 2: 移行タスクの構成

    1.  DTS コンソールにログオンし、左側のナビゲーションウィンドウで [データ移行] を選択し、次に [タスクの作成] をクリックします。

    2. ソースデータベースと宛先 RDS インスタンスを構成します。

      ソースデータベース

      パラメーター

      説明

      データベースタイプ

      MySQL を選択します。

      アクセス方法

      ソースデータベースのアクセス方法を選択します。例: [パブリック IP]。

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

      ソースデータベースが配置されているリージョンを選択します。

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

      ソースデータベースのパブリックエンドポイントまたは IP アドレスを入力します。

      [ポート]

      ソースデータベースのサービスポートを入力します。デフォルト値: 3306。

      データベースアカウント

      ソースデータベース用に作成されたアカウントを入力します。

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

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

      暗号化

      ソースデータベースへの接続を暗号化するかどうかを指定します。

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

      • ソースデータベースで SSL 暗号化が有効になっている場合は、SSL 暗号化 を選択します。この場合、CA 証明書 をアップロードし、CA キー パラメーターを構成する必要があります。

      宛先 RDS インスタンス

      パラメーター

      説明

      データベースタイプ

      MySQL を選択します。

      アクセス方法

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

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

      RDS インスタンスのリージョンを選択します。

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

      × を選択します。

      RDS インスタンス ID

      RDS インスタンスの ID を選択します。

      データベースアカウント

      RDS インスタンス用に作成された特権アカウントを入力します。

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

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

      暗号化

      ソースデータベースインスタンスへの接続を暗号化するかどうかを指定します。[非暗号化] または [SSL 暗号化] を選択します。[SSL 暗号化] を選択した場合は、宛先 RDS インスタンスの SSL 暗号化を有効にする必要があります。

    3. データベース接続をテストします。

      ページの下部にある 接続をテストして続行 をクリックします。表示されたダイアログボックスで、 接続テスト をクリックします。テストが失敗した場合は、エラーメッセージに基づいて問題を修正してください。

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

      オブジェクト設定、[詳細構成]、および [データ検証] タブで設定を構成します。

      オブジェクトの構成

      次の表のパラメーターを構成します。次に、次へ：詳細設定 をクリックします。

      パラメーター

      説明

      移行タイプ

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

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

      説明

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

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

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

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

      説明

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

      移行評価の有効化

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

      説明

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

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

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

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

        説明

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

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

        警告

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

        • ソースデータベースと宛先データベースのスキーマが同じで、データレコードが宛先データベースの既存のデータレコードと同じプライマリキーを持つ場合、次のシナリオが発生する可能性があります。

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

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

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

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

      ソースデータベースからイベントを移行するかどうかを指定します。○ を選択した場合は、後続の操作を完了する必要があります。詳細については、「イベントの同期または移行」をご参照ください。

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

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

      ソースオブジェクト

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

      説明

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

      選択中のオブジェクト

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

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

      説明

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

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

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

      (オプション) 詳細構成

      移行タスクを微調整するために詳細設定を構成します。これらの設定を構成する必要がない場合は、デフォルト値を保持し、[次へ: データ検証] をクリックします。

      パラメーター

      説明

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

      デフォルトでは、専用クラスターを指定しない場合、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 秒あたりのソースデータベースのクエリ率 QPS、1 秒あたりの完全移行の行数 RPS、および 1 秒あたりの完全移行データ量 (MB) BPS パラメーターを構成する必要があります。これにより、宛先データベースサーバーの負荷が軽減されます。

      説明

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

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

      増分データ移行の速度制限を有効にするかどうかを指定します。速度制限を構成するには、1 秒あたりの増分移行の行数 RPS および 1 秒あたりの増分移行データ量 (MB) BPS パラメーターを構成する必要があります。これにより、宛先データベースサーバーの負荷が軽減されます。

      説明

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

      環境タグ

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

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

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

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

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

      ETL の設定

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

      監視アラート

      データ移行タスクのアラートを構成するかどうかを指定します。タスクが失敗した場合、または移行遅延が指定されたしきい値を超えた場合、アラート連絡先は通知を受け取ります。有効な値:

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

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

      (オプション) データ検証

      データ検証は、ソースデータベースと宛先データベース間のデータを監視および比較して、不整合を特定します。データ検証が不要な場合は、次のステップに進んでください。

      データ検証方法

      コスト

      説明

      全データ検証

      有料

      完全なデータ移行のデータを検証します。

      増分データ検証

      増分データ移行のデータを検証します。

      構造の検証

      無料

      移行するオブジェクトに対してスキーマ検証を実行します。

      移行タスクを構成する際にデータ検証機能を構成できます。また、移行完了後に個別のデータ検証タスクを構成することもできます。必要に応じてこのステップをスキップできます。

      データ検証構成の詳細を展開するにはクリックしてください

      1. データ検証モード: ビジネスニーズに基づいて 1 つ以上のデータ検証方法を選択します。

        完全なデータ検証

        全データ検証 を選択した場合は、次のパラメーターを構成します。

        パラメーター

        説明

        全データ検証

        • 行サンプリングによるフルフィールド検証: サンプリング率 (10 から 100 の整数) を構成して、サンプリングされたデータに対して完全なフィールド検証を実行します。

        • テーブルの行数に基づく検証: データを検証せずに、完全なデータ移行の行数を検証します。

        説明

         テーブルの行数に基づく検証 モードは無料です。 行サンプリングによるフルフィールド検証 モードは、検証されたデータの実際の量に基づいて課金されます。

        全データ検証時間ルール

        直ちに開始 のみがサポートされています。

        全データ検証のタイムアウト設定

        • ×: 完全な検証タスクがタイムアウトした場合、強制的に終了されません。

        • ○: 完全な検証タスクのタイムアウト期間を設定します。タイマーは検証タスクが開始されると開始され、タスクが指定された時間内に完了しない場合、強制的に終了されます。値は 1 から 72 の整数です。

        完全な校正参照

        • デフォルト: ソースデータベースと宛先データベースの和集合をベースラインとして使用して、データの一貫性を検証します。

        • 移行元データベース: ソースデータベースをベースラインとして使用して、宛先データベースがソースと一致していることを検証します (宛先 RDS インスタンスの余分なデータはチェックしません)。

        • 移行先データベース: 宛先 RDS インスタンスをベースラインとして使用して、ソースデータベースが宛先 RDS インスタンスと一致していることを検証します (ソースデータベースの余分なデータはチェックしません)。

        完全検証による1秒あたりのデータ読み取りの最大行数

        完全なデータ検証は、データベースからいくつかの読み取りリソースを消費します。検証タスクのレート制限 (毎秒の行数と毎秒のバイト数) を設定して、データベースのワークロードを削減できます。

        説明

        値 0 は制限が設定されていないことを意味します。完全検証による1秒あたりのデータ読み取りの最大行数 と フル検証Byte/sで1秒あたりに読み取られる最大バイト数。 の両方が 0 の場合、速度は制限されません。

        フル検証Byte/sで1秒あたりに読み取られる最大バイト数。

        増分データ検証

        増分データ検証 を選択した場合は、次のパラメーターも構成する必要があります。

        パラメーター

        説明

        増分検証基準

        必要に応じて、検証する DML 操作をフィルタリングできます。

      2. 検証オブジェクト を指定します。

        選択中のオブジェクト セクションで、データ検証が不要なオブジェクトを選択し、移除 をクリックして削除します。

        説明

        デフォルトでは、同期または移行するオブジェクトは 選択中のオブジェクト セクションに追加されます。

      3. データ検証のアラートを構成します。

        ビジネス要件に基づいてデータ検証のアラートを構成します。次の表にパラメーターを説明します。

        パラメーター

        説明

        全データ検証アラート

        • ×: アラートを無効にします。

        • ○: アラートを有効にします。アラートルールも選択して構成する必要があります。アラートルールは次のとおりです。

          • 完全なデータ検証が失敗した場合にアラートがトリガーされます。

          • 完全なデータ検証で検出された不整合データの量が指定されたしきい値以上の場合にアラートがトリガーされます。

        増分データ検証アラート

        • ×: アラートを無効にします。

        • ○: アラートを有効にします。アラートルールも選択して構成する必要があります。アラートルールは次のとおりです。

          • 増分データ検証が失敗した場合にアラートがトリガーされます。

          • 指定された連続期間内に増分データ検証で検出された不整合データの量が指定されたしきい値以上の場合にアラートがトリガーされます。連続期間の数、統計期間、および不整合データ量のしきい値を指定できます。

          • 指定された連続期間内に増分データ検証で検出されたデータ移行または同期の遅延が指定されたしきい値以上の場合にアラートがトリガーされます。連続期間の数、統計期間、およびデータ移行または同期の遅延を指定できます。

        重要

        データ検証のアラートを有効にし、アラートがトリガーされたときに通知を受け取りたい場合は、CloudMonitor でアラートメッセージをサブスクライブする必要があります。詳細については、「CloudMonitor コンソールで DTS タスクのアラートルールを構成する」をご参照ください。

    フェーズ 3: 事前チェックと移行の開始

    1. 構成が完了したら、次：タスク設定の保存と事前チェック をクリックします。DTS は環境と構成を検証します。

    2. 事前チェックが完了するのを待ちます。

      • 成功率 が [100%] に達した場合、環境は移行の準備ができています。

      • 事前チェックが失敗した場合は、[詳細の表示] をクリックし、問題を修正して、再度事前チェックを実行します。

      • 無視できる警告を確認し、リスクがないことを確認してから、それらを無視して続行します。

    3. 事前チェックが合格したら、次：インスタンスの購入 をクリックします。

    4. [リソースグループ] (デフォルト: [デフォルトリソースグループ]) と適切な DTS インスタンス仕様を選択します。

    5. [Data Transmission Service (Pay-As-You-Go) 利用規約] を読んで選択し、[購入して開始] をクリックし、次に [確認] をクリックします。タスクは自動的に開始されます。

    フェーズ 4: データ検証とビジネスの切り替え

    1. 移行タスクが進行するのを待ちます。

      1. 増分データ移行のないタスクは、完了すると ステータス が 完了 になります。

      2. 増分データ移行のあるタスクは、ステータス が 実行中 であり、自動的に終了しません。

    2. データの一貫性を検証します。

      完全移行が完了し、増分データ移行の遅延がほぼゼロになった後、ソースデータベースと宛先データベース間のデータの一貫性を検証します。

      1. 自動検証: DTS で データ検証タスクを構成して、ソースデータベースと宛先データベースのデータを自動的に比較します。

      2. 手動検証: ソースデータベースと宛先 RDS インスタンス間で、テーブルの行数とコアビジネスデータを比較します。サンプルコード:

        -- 例 1: ソースデータベースと宛先 RDS インスタンスでそれぞれ次のステートメントを実行して、テーブルの行数を比較します。
SELECT COUNT(*) FROM your_table;

-- 例 2: ソースデータベースと宛先 RDS インスタンスでそれぞれ次のステートメントを実行して、特定の期間内の総注文額などの主要なビジネス指標を比較します。
SELECT SUM(amount) FROM orders WHERE create_time >= '2024-01-01';

    3. ビジネスを切り替えます。

      オフピーク時にアプリケーションを停止し、増分データ移行の遅延がゼロであることを確認してから、アプリケーションのデータベース接続文字列を宛先 RDS インスタンスのエンドポイントに変更します。切り替えが完了したら、移行タスクをリリースします。

    付録 1: 移行タイプ

    移行タイプ

    説明

    スキーマ移行

    テーブル、ビュー、ストアドプロシージャなどのオブジェクトの構造定義を移行します。DTS は、ビューとストアドプロシージャの DEFINER を宛先データベースの INVOKER に変換します。

    完全なデータ移行

    ソースデータベースから宛先 RDS インスタンスにすべての既存データを移行します。

    増分データ移行

    完全移行後、このタイプはソースから宛先への新しいデータ変更を継続的に移行し、ゼロダウンタイムでの移行を可能にします。

    付録 2: 増分データ移行中にサポートされる 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

    よくある質問

    • Q1: 「JDBC: [conn_error, cause: null, message from server: "Host 'XXX' is not allowed to connect to this MySQL server"]; PING: []; TELNET: []; requestId=[XXX]」エラーが発生した場合はどうすればよいですか？

      このエラーは、Java Database Connectivity (JDBC) の例外を示しています。JDBC のアカウント、パスワード、および権限を確認するか、特権アカウントを使用して接続をテストしてください。

    • Q2: 移行タスクを作成する際に、中国 (福州) リージョンの RDS インスタンスを選択できないのはなぜですか？

      DTS は中国 (福州) リージョンのインスタンスをサポートしていません。代替策として、自己管理 MySQL 5.7 または 8.0 データベースをクラウドにバックアップできます。