すべてのプロダクト
Search

このプロダクト

    ApsaraDB RDS:Google Cloud SQL for MySQL データベースの Alibaba Cloud への移行

    ドキュメントセンター

    ApsaraDB RDS:Google Cloud SQL for MySQL データベースの Alibaba Cloud への移行

    最終更新日:Mar 29, 2026

    Data Transmission Service (DTS) を使用して、最小限のダウンタイムで Google Cloud SQL for MySQL インスタンスから ApsaraDB RDS for MySQL インスタンスにデータを移行します。DTS は、スキーマ移行、完全データ移行、および増分データ移行をサポートしています。

    このガイドでは、次の内容について説明します。

    • ソースデータベースとターゲットデータベースの両方の前提条件と制限事項の確認

    • Google Cloud SQL for MySQL でのバイナリロギングの設定 (増分移行に必要)

    • DTS 移行タスクの作成と実行

    • 移行後のクリーンアップの完了

    前提条件

    開始する前に、以下を確認してください。

    ソース：Google Cloud SQL for MySQL

    • インスタンスでパブリックアクセスが有効になっており、パブリックエンドポイントとポートが利用可能であること

    • インスタンスに特権アカウントが作成されていること

    詳細については、「Google Cloud SQL for MySQL ドキュメント」をご参照ください。

    ターゲット：ApsaraDB RDS for MySQL

    制限事項

    • スキーマ移行はイベントをサポートしていません。

    • DTS は round(column,precision) 関数を使用して FLOAT および DOUBLE 列の値を読み取ります。精度が指定されていない場合、FLOAT 値は 38 ビットの精度を使用し、DOUBLE 値は 308 ビットの精度を使用します。移行前に、これらの精度レベルが要件を満たしていることを確認してください。

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

    増分データ移行のみ：

    • Google Cloud SQL for MySQL インスタンスでバイナリロギングを有効にする必要があります。

    • binlog_format パラメーターを row に設定する必要があります。

    • MySQL 5.6 以降の場合：binlog_row_image パラメーターを full に設定する必要があります。

    • 増分移行中にソースインスタンスでクロスホスト移行または再構築が発生した場合、バイナリログファイルの ID が乱れ、増分データが失われる可能性があります。

    これらのパラメーターの変更方法については、「Google Cloud SQL for MySQL ドキュメント」をご参照ください。

    増分移行のためのバイナリロギングの設定

    完全データ移行のみを実行する場合は、このセクションをスキップしてください。

    増分データ移行 (CDC) の場合は、Google Cloud SQL for MySQL インスタンスでバイナリロギングを有効にし、次のパラメーターを設定します。

    パラメーター必須値この設定が重要な理由
    binlog_formatROW行レベルの変更をキャプチャし、正確なレプリケーションを保証します
    binlog_row_imageFULLMySQL 5.6 以降で必須。完全な行イメージをキャプチャし、DTS が変更を再構築できるようにします

    Google Cloud SQL は、バイナリロギングを有効にするための組み込みオプションを提供しています。Google Cloud コンソールで、Cloud SQL インスタンスの設定に移動し、[Backups] セクションで [Binary logging] を有効にします。

    データ移行

    警告

    DTS は、過去 7 日以内に実行された異常な移行タスクを自動的に再開します。その結果、ソースデータベースのデータが、すでにターゲットインスタンスに書き込まれているサービスデータを上書きする可能性があります。移行が完了したら、REVOKE 文を実行して、ApsaraDB RDS for MySQL インスタンスに対する DTS アカウントの書き込み権限を取り消してください。

    ステップ 1：データ移行ページへの移動

    次のいずれかの方法を使用します。

    DTS コンソール

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

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

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

    Data Management Service (DMS) コンソール

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

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

    2. トップナビゲーションバーで、[データ + AI] > [DTS (DTS)] > [データ移行] にポインターを合わせます。

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

    ステップ 2：ソースデータベースとターゲットデータベースの設定

    [タスクの作成] をクリックします。タスク設定ページで、以下を入力します。

    警告

    ソースデータベースとターゲットデータベースを設定した後、次に進む前にページの上部に表示される [制限事項] を確認してください。これらの制限事項を無視すると、タスクが失敗したり、データの不整合が発生したりする可能性があります。

    ソースデータベース

    パラメーター値
    既存のDMSデータベースインスタンスの選択既存のインスタンスを選択するか、手動で設定します
    データベースタイプMySQL
    アクセス方法パブリック IP アドレス
    インスタンスリージョンソースインスタンスに最も近いリージョン
    ドメイン名または IPGoogle Cloud SQL インスタンスのパブリック IP アドレス。確認するには、Cloud SQL インスタンスの左側のナビゲーションウィンドウで [接続] をクリックします。[概要] タブの [ネットワーク] で、[パブリック IP アドレス] の値をコピーします。
    ポート3306 (デフォルト)
    データベースアカウントソースインスタンスの特権アカウント
    データベースパスワードアカウントのパスワード

    宛先データベース

    パラメーター値
    既存のDMSデータベースインスタンスの選択既存のインスタンスを選択するか、手動で設定します
    データベースタイプMySQL
    アクセス方法Alibaba Cloud インスタンス
    インスタンスリージョンターゲット RDS インスタンスのリージョン
    Alibaba Cloud アカウント間でデータをレプリケートいいえ
    RDS インスタンス IDターゲット ApsaraDB RDS for MySQL インスタンスの ID
    データベースアカウント読み取りおよび書き込み権限を持つアカウント
    データベースパスワードアカウントのパスワード
    暗号化[暗号化なし] または [SSL 暗号化] を選択します。SSL 暗号化を使用する場合は、まず RDS インスタンスで SSL を有効化します。詳細については、「クラウド証明書を使用して SSL 暗号化を有効化する」をご参照ください。

    ステップ 3：接続性のテスト

    [接続テストと次へ] をクリックします。

    DTS は両方のデータベースにアクセスする必要があります。ソースデータベースに IP アドレスホワイトリストが設定されている場合は、DTS サーバーの CIDR ブロックをホワイトリストに追加してください。詳細については、「DTS サーバーの CIDR ブロックを追加する」をご参照ください。
    警告

    DTS サーバーの CIDR ブロックをデータベースのホワイトリストまたは ECS のセキュリティグループルールに追加すると、セキュリティリスクが生じる可能性があります。続行する前に、強力な認証情報の設定、公開ポートの制限、API 呼び出しの監査、ホワイトリストルールの定期的な見直しなどの予防措置を講じてください。または、Express Connect、VPN Gateway、または Smart Access Gateway を使用してソースデータベースを DTS に接続することもできます。

    ステップ 4：移行するオブジェクトの選択

    次のパラメーターを設定します。

    移行タイプ

    要件に基づいて選択します。

    • 完全移行のみ：[スキーマ移行] と [完全データ移行] を選択します。データ整合性を確保するため、移行中はソースデータベースにデータを書き込まないことを推奨します。

    • 最小限のダウンタイムでの移行：[スキーマ移行]、[完全データ移行]、および [増分データ移行] を選択します。

    [スキーマ移行] を選択しない場合は、開始前にターゲットデータベースとテーブルを手動で作成し、[選択したオブジェクト] でオブジェクト名マッピングを有効にする必要があります。
    [増分データ移行] を選択しない場合は、移行中にソースデータベースにデータを書き込まないでください。

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

    オプション動作
    事前チェックとエラー報告ソースと送信先で名前が同じテーブルをチェックします。競合が存在する場合、タスクは事前チェックに失敗します。競合するテーブルの名前を変更するには、オブジェクト名マッピングを使用します。詳細については、「オブジェクト名マッピング」をご参照ください。
    エラーを無視して続行名前の競合に関する事前チェックをスキップします。完全移行中、ターゲットの既存のレコードは保持されます。増分移行中、既存のレコードは上書きされます。スキーマが異なる場合、特定の列のみが移行されるか、タスクが失敗する可能性があります。

    その他のパラメーター

    パラメーター説明
    ソースデータベースのトリガーを移行する方法要件に基づいて方法を選択します。[スキーマ移行] が選択されている場合にのみ設定します。詳細については、「ソースデータベースからのトリガーの同期または移行」をご参照ください。
    移行評価を有効にする[はい]アラート通知設定に設定すると、DTS はソースとターゲットのスキーマが移行要件 (インデックス長、ストアドプロシージャ、依存テーブル) を満たしているかチェックします。[スキーマ移行] が選択されている場合にのみ設定可能です。結果は事前チェックの結果に影響しません。
    宛先インスタンスでのオブジェクト名の大文字化ターゲットのデータベース、テーブル、および列名の大文字/小文字を制御します。デフォルト：DTS デフォルトポリシー宛先インスタンスのオブジェクト名の大文字/小文字の指定。詳細については、「」をご参照ください。
    ソースオブジェクト移行するオブジェクトを選択し、Rightwards arrow をクリックして [選択したオブジェクト] に追加します。テーブルまたは列を選択すると、ビュー、トリガー、ストアドプロシージャなどの他のオブジェクトは除外されます。
    選択したオブジェクトオブジェクトを右クリックして、名前を変更するか、行フィルタリング用の WHERE 条件を設定します。[一括編集] をクリックして、複数のオブジェクトを一度に名前を変更します。「オブジェクト名のマッピング」および「フィルター条件の指定」をご参照ください。

    ステップ 5：詳細設定の構成

    [次へ：詳細設定] をクリックします。

    データ検証設定

    移行後のデータ整合性を検証するには、データ検証タスクを設定します。詳細については、「データ検証タスクの設定」をご参照ください。

    詳細設定

    パラメーター説明
    タスクスケジューリング用の専用クラスターデフォルトでは、DTS はタスクを共有クラスターにスケジュールします。専用クラスターを使用するには、まず購入する必要があります。詳細については、「DTS 専用クラスターとは
    Set Alertsタスクの失敗または遅延がしきい値を超えた場合にアラートを設定します。「モニタリングとアラートの設定」をご参照ください。
    ソーステーブルで生成されたオンライン DDL ツールの一次テーブルをターゲットデータベースにコピーします。オンライン DDL 操作 (DMS または gh-ost のみ) からの一時テーブルの処理を制御します。
    重要

    pt-online-schema-change はサポートされておらず、タスクが失敗する原因となります。

    接続失敗時の再試行時間DTS がタスクを失敗とマークする前に、失敗した接続を再試行する時間。範囲：10～1,440 分。デフォルト：720 分。30 以上に設定してください。複数のタスクが同じソースまたはターゲットを共有する場合、最も短い再試行時間が適用されます。
    その他の問題の再試行時間DTS が失敗した DDL または DML 操作を再試行する時間。範囲：1～1,440 分。デフォルト：10 分。10 より大きい値に設定してください。[接続失敗時の再試行時間] より短くする必要があります。
    完全データ移行の帯域幅調整を有効にする完全移行中にソースデータベースへの秒間クエリ数 (QPS)、秒間行数 (RPS)、および移行速度 (MB/s) を制限します。[完全データ移行] が選択されている場合にのみ利用可能です。
    増分データ移行の帯域幅調整を有効にする増分移行中に RPS と移行速度 (MB/s) を制限します。[増分データ移行] が選択されている場合にのみ利用可能です。
    環境タグオプション。移行タスクに環境ラベルをタグ付けします。
    ETLの設定データ移行中のデータ処理のために、抽出・変換・書き出し (ETL) 機能を有効化します。詳細については、「データ移行またはデータ同期タスクで ETL を設定する」をご参照ください。
    順方向および逆方向タスクのハートビートテーブルに対する SQL 操作を削除するかどうかDTS がハートビートテーブルに対する SQL 操作をソースデータベースに書き込むかどうかを制御します。[はい] を選択すると書き込みは防止されますが、移行遅延が表示される場合があります。[いいえ] を選択すると書き込みが有効になりますが、ソースの物理バックアップとクローニングに影響する可能性があります。

    ステップ 6：事前チェックの実行

    [次へ：タスク設定を保存して事前チェック] をクリックします。

    このタスクの API パラメーターを確認するには、[次へ：タスク設定を保存して事前チェック] にポインターを合わせ、[OpenAPI パラメーターのプレビュー] をクリックします。

    DTS は、移行タスクを開始する前に事前チェックを実行します。事前チェックが完了した後：

    • 合格項目：操作は不要です。

    • 失敗項目：失敗した項目の横にある [詳細の表示] をクリックします。問題を修正してから、[再事前チェック] をクリックします。

    • アラート項目：

      • アラートを無視できない場合：[詳細の表示] をクリックし、問題を修正してから事前チェックを再実行します。

      • アラートを無視できる場合：[アラート詳細の確認] > [無視] > [OK] > [再事前チェック] をクリックします。アラートを無視すると、データの不整合が発生する可能性があることに注意してください。

    ステップ 7：移行インスタンスの購入

    [成功率] が [100%] に達するまで待ってから、[次へ: インスタンスの購入] をクリックします。

    [インスタンスの購入] ページで、以下を設定します。

    パラメーター説明
    リソースグループ移行インスタンスのリソースグループ。デフォルト：デフォルトリソースグループResource Management とは
    インスタンスクラス移行速度はインスタンスクラスによって異なります。データ量と所要時間に基づいて選択してください。詳細については、「データ移行インスタンスのインスタンスクラス」をご参照ください。

    ステップ 8：移行の開始

    1. 「[Data Transmission Service（従量課金）サービス利用規約]」のチェックボックスを読み、選択してください。

    2. [購入して開始] をクリックし、確認ダイアログで [OK] をクリックします。

    [データ移行] ページで進捗状況を追跡します。

    次のステップ

    移行タスクが完了した後：

    • REVOKE 文を実行して、ApsaraDB RDS for MySQL インスタンスに対する DTS アカウントの書き込み権限を取り消します。これにより、DTS がタスクを再開した場合の偶発的な上書きを防ぎます。

    • データ検証機能を使用してデータ整合性を確認します。詳細については、「データ検証タスクの設定」をご参照ください。

    • アプリケーション接続文字列を更新して、ApsaraDB RDS for MySQL インスタンスを指すようにします。