すべてのプロダクト
Search

このプロダクト

    Data Transmission Service:Amazon RDS for OracleインスタンスからApsaraDB RDS for MySQLインスタンスへのデータの移行

    ドキュメントセンター

    Data Transmission Service:Amazon RDS for OracleインスタンスからApsaraDB RDS for MySQLインスタンスへのデータの移行

    最終更新日:Oct 22, 2024

    このトピックでは、data Transmission Service (DTS) を使用して、Amazon RDS for OracleインスタンスからApsaraDB RDS for MySQLインスタンスにデータを移行する方法について説明します。 DTS はフルデータ移行と増分データ移行に対応しています。 データ移行タスクを設定するときに、サポートされているすべての移行タイプを選択して、サービスの継続性を確保できます。

    前提条件

    • Amazon RDS for Oracleインスタンスの [パブリックアクセシビリティ] オプションが [はい] に設定されています。 この設定により、DTSがインターネット経由でAmazon RDS for Oracleインスタンスにアクセスできるようになります。

    • Amazon RDS for Oracleインスタンスのデータベースバージョンは、9i、10g、11g、12c以降 (非マルチテナントアーキテクチャ) です。

    • ApsaraDB RDS for MySQLインスタンスのデータベースバージョンが5.6または5.7です。

    • ApsaraDB RDS for MySQLインスタンスの使用可能なストレージ容量は、Amazon RDS for Oracleインスタンスのデータの合計サイズの2倍以上です。

      説明

      データ移行中に生成されるバイナリログファイルは、ある程度のスペースを占有します。 データ移行が完了すると、自動的にクリアされます。

    制限事項

    • DTSは、完全データ移行中にソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを使用します。 これは、データベースサーバの負荷を増加させる可能性がある。 データベースのパフォーマンスが悪い場合、仕様が低い場合、またはデータ量が多い場合、データベースサービスが利用できなくなる可能性があります。 たとえば、ソースデータベースで多数の低速SQLクエリが実行されている場合、テーブルにプライマリキーがない場合、またはターゲットデータベースでデッドロックが発生する場合、DTSは大量の読み取りおよび書き込みリソースを占有します。 データを移行する前に、移行元データベースと移行先データベースのパフォーマンスに対するデータ移行の影響を評価します。 オフピーク時にデータを移行することを推奨します。 たとえば、ソースデータベースとターゲットデータベースのCPU使用率が30% 未満の場合にデータを移行できます。

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

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

    • DTSは、ApsaraDB RDS for MySQLインスタンスにターゲットデータベースを自動的に作成します。 ただし、ソースデータベースの名前が無効な場合は、データ移行タスクを設定する前に、ApsaraDB RDS for MySQLインスタンスにデータベースを手動で作成する必要があります。

      説明

      ApsaraDB RDS For MySQLデータベースのデータベース命名規則とデータベースの作成方法の詳細については、 データベースの管理

    • データ移行タスクが失敗した場合、DTSは自動的にタスクを再開します。 ワークロードをターゲットインスタンスに切り替える前に、データ移行タスクを停止またはリリースします。 それ以外の場合、タスクの再開後、ソースデータベースのデータがターゲットインスタンスのデータを上書きします。

    課金ルール

    移行タイプ

    タスク設定料金

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

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

    無料です。

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

    増分データ移行

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

    移行タイプ

    • スキーマの移行

      DTSは、テーブル、インデックス、制約、シーケンスのオブジェクトのスキーマ移行をサポートしています。 DTSは、ビュー、シノニム、トリガー、ストアドプロシージャ、関数、パッケージ、およびユーザー定義型のオブジェクトのタイプのスキーマ移行をサポートしていません。

    • フルデータ移行

      DTSは、必要なオブジェクトの履歴データをAmazon RDS for OracleインスタンスのソースデータベースからApsaraDB RDS for MySQLインスタンスのターゲットデータベースに移行します。

    • 増分データ移行

      DTSは、Amazon RDS for Oracleインスタンスのソースデータベースからredoログファイルを取得します。 次に、DTSは、Amazon RDS for OracleインスタンスのソースデータベースからApsaraDB RDS for MySQLインスタンスのターゲットデータベースに増分データを同期します。 増分データ移行により、Oracleデータベースからデータを移行するときに、自己管理型アプリケーションのサービスを中断することなく、データをスムーズに移行できます。

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

    • INSERT、DELETE、UPDATE

    • CREATE TABLE

      説明

      CREATE TABLE操作でパーティションテーブルまたは関数を含むテーブルが作成された場合、DTSは操作を同期しません。

    • ALTER TABLE (ADD COLUMN、DROP COLUMN、RENAME COLUMN、ADD INDEXのみを含む)

    • DROP TABLE

    • RENAME TABLE、TRUNCATE TABLE、CREATE INDEX

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

    データベース

    スキーマ移行

    完全なデータ移行

    増分データ移行

    Amazon RDS for Oracleインスタンス

    スキーマ所有者の権限

    スキーマ所有者の権限

    マスターユーザーの権限

    ApsaraDB RDS for MySQL インスタンス

    ターゲットデータベースの読み取りおよび書き込み権限

    ターゲットデータベースの読み取りおよび書き込み権限

    ターゲットデータベースの読み取りおよび書き込み権限

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

    データ型マッピング

    詳細については、「異種データベース間のデータ型マッピング」をご参照ください。

    始める前に

    1. Amazon RDSマネジメントコンソールにログインします。

    2. Amazon RDS for Oracleインスタンスの基本情報ページに移動します。

    3. では、セキュリティグループルールセクションで、既存のインバウンドルールが属するセキュリティグループの名前をクリックします。

      安全组规则

    4. [セキュリティグループ] ページで、[セキュリティグループ] セクションの [インバウンド] タブをクリックします。 [インバウンド] タブで、[編集] をクリックします。 [受信ルールの編集] ダイアログボックスで、対応するリージョンにあるDTSサーバーのCIDRブロックを受信ルールに追加します。 詳細については、「DTSサーバーのCIDRブロックをオンプレミスデータベースのセキュリティ設定に追加する」をご参照ください。

      编辑入站规则

      説明

      • 追加する必要があるのは、ターゲットデータベースと同じリージョンにあるDTSサーバーのCIDRブロックだけです。 たとえば、ソースデータベースはシンガポールリージョンにあり、ターゲットデータベースは中国 (杭州) リージョンにあります。 追加する必要があるのは、中国 (杭州) リージョンにあるDTSサーバーのCIDRブロックのみです。

      • 必要なすべてのCIDRブロックを一度にインバウンドルールに追加できます。

      • 他に質問がある場合は、Amazonの公式ドキュメントを参照するか、テクニカルサポートにお問い合わせください。

    5. Amazon RDS for Oracleインスタンスのログ設定を変更します。 増分データ移行を実行する必要がない場合は、この手順をスキップします。

      • Amazon RDS for Oracleインスタンスのデータベースバージョンが12c以降 (非マルチテナントアーキテクチャ) の場合、次の手順を実行してログ設定を構成します。

        1. マスターユーザーアカウントとSQL * Plusツールを使用して、Amazon RDS for Oracleインスタンスに接続します。

        2. アーカイブロギングと補足ロギングを有効にします。

          タイプ

          手順

          アーカイブロギング

          1. 次の文を実行して、アーカイブロギングが有効かどうかを確認します。

            SELECT LOG_MODE FROM v$database;

          2. アーカイブログの保存期間を表示および設定します。

            説明

            アーカイブされたログの保存期間を72時間以上に設定することを推奨します。 この例では、保持期間は72時間に設定されています。 

            exec rdsadmin.rdsadmin_util.show_configuration;
exec rdsadmin.rdsadmin_util.set_configuration('archivelog retention hours', 72);

          補足ロギング

          データベースまたはテーブルレベルで補足ログを有効にします。

          • データベースレベルの補足ロギングの有効化

            1. 次のステートメントを実行して、データベースレベルの補足ロギングが有効かどうかを確認します。

              SELECT supplemental_log_data_min, supplemental_log_data_pk, supplemental_log_data_ui FROM v$database;

            2. データベースレベルで主キーと一意キーの補足ログを有効にします。

              exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD', 'PRIMARY KEY');
exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD', 'UNIQUE');

          • 次のいずれかの方法を使用して、テーブルレベルの補足ログを有効にします。

            • すべての列に対してテーブルレベルの補足ログを有効にする:

              exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD', 'ALL');

            • テーブルレベルでプライマリキーの補足ログを有効にします。

              exec rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD', 'PRIMARY KEY');

        3. Amazon RDS for Oracleインスタンスのデータベースアカウントにきめ細かい権限を付与します。

          詳細な権限の付与

          Webpack

          # Create a database account and grant permissions to the account. In this example, a database account named RDSDT_DTSACCT is created.
create user RDSDT_DTSACCT IDENTIFIED BY RDSDT_DTSACCT;
grant create session to RDSDT_DTSACCT;
grant connect to RDSDT_DTSACCT;
grant resource to RDSDT_DTSACCT;
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGMNR_LOGS','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_OBJECTS','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ALL_TAB_COLS','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('DBA_REGISTRY','RDSDT_DTSACCT','SELECT');
grant select any table to RDSDT_DTSACCT;
grant select any transaction to RDSDT_DTSACCT;
-- v$log privileges
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOG','RDSDT_DTSACCT','SELECT');
-- v$logfile privileges
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGFILE','RDSDT_DTSACCT','SELECT');
-- v$archived_log privileges
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$ARCHIVED_LOG','RDSDT_DTSACCT','SELECT');
-- v$parameter privileges
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$PARAMETER','RDSDT_DTSACCT','SELECT');
-- v$database privileges
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$DATABASE','RDSDT_DTSACCT','SELECT');
-- v$active_instances privileges
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$ACTIVE_INSTANCES','RDSDT_DTSACCT','SELECT');
-- v$instance privileges
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$INSTANCE','RDSDT_DTSACCT','SELECT');
-- v$logmnr_contents privileges
exec rdsadmin.rdsadmin_util.grant_sys_object('V_$LOGMNR_CONTENTS','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('USER$','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('OBJ$','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('COL$','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('IND$','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('ICOL$','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('CDEF$','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('CCOL$','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('TABPART$','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('TABSUBPART$','RDSDT_DTSACCT','SELECT');
exec rdsadmin.rdsadmin_util.grant_sys_object('TABCOMPART$','RDSDT_DTSACCT','SELECT');
grant LOGMINING TO RDSDT_DTSACCT;
grant EXECUTE_CATALOG_ROLE to RDSDT_DTSACCT;
exec rdsadmin.rdsadmin_util.grant_sys_object('DBMS_LOGMNR','RDSDT_DTSACCT','EXECUTE');
grant select on v$database to rdsdt_dtsacct;
grant select on dba_objects to rdsdt_dtsacct;
grant select on DBA_TAB_COMMENTS to rdsdt_dtsacct;
grant select on dba_tab_cols to rdsdt_dtsacct;
grant select_catalog_role TO rdsdt_dtsacct;

      • Amazon RDS for Oracleインスタンスのデータベースバージョンが9i、10g、または11gの場合、次の手順を実行してログ設定を構成します。

        1. マスターユーザーアカウントとSQL * Plusツールを使用して、Amazon RDS for Oracleインスタンスに接続します。

        2. archive log list; コマンドを実行して、Amazon RDS for OracleインスタンスがARCHIVELOGモードで実行されているかどうかを確認します。

          説明

          インスタンスがNOARCHIVELOGモードで実行されている場合は、モードをARCHIVELOGに切り替えます。 詳細については、「アーカイブRedoログの管理」をご参照ください。

        3. 強制ロギングを有効にします。 

          exec rdsadmin.rdsadmin_util.force_logging(p_enable => true);

        4. プライマリキーの補足ログを有効にします。 

          begin rdsadmin.rdsadmin_util.alter_supplemental_logging(p_action => 'ADD',p_type => 'PRIMARY KEY');end;/

        5. 一意のキーの補足ログを有効にします。 

          begin rdsadmin.rdsadmin_util.alter_supplemental_logging(p_action => 'ADD',p_type => 'UNIQUE');end;/

        6. アーカイブログの保存期間を設定します。 

          begin rdsadmin.rdsadmin_util.set_configuration(name => 'archivelog retention hours', value => '24');end;/

        7. アーカイブログの保存期間を設定します。

          説明

          アーカイブされたログの保存期間を24時間以上に設定することを推奨します。

        8. 変更をコミットします。 

          commit;

    手順 (新しいDTSコンソールで)

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

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

      2. 上部のナビゲーションバーで、ポインタを上に移動します。DTS.

      3. 選択DTS (DTS) > データ移行.

      説明

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

      説明

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

    3. [タスクの作成] をクリックします。 [タスクの作成] ウィザードページで、ソースデータベースとターゲットデータベースを設定します。

      警告

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

      セクション

      パラメーター

      説明

      非該当

      タスク名

      タスクの名前。 タスク名は自動生成されます。 タスクを識別するために、有益な名前を指定することを推奨します。 一意のタスク名を指定する必要はありません。

      ソースデータベース

      データベースタイプ

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

      アクセス方法

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

      インスタンスリージョン

      Amazon RDS for Oracleインスタンスが存在するリージョン。

      説明

      Amazon RDS for Oracleインスタンスが存在するリージョンがドロップダウンリストに表示されない場合は、Amazon RDS for Oracleインスタンスに地理的に最も近いリージョンを選択します。

      ホスト名またはIPアドレス

      Amazon RDS for Oracleインスタンスへのアクセスに使用されるエンドポイント。

      説明

      Amazon RDS for Oracleインスタンスの基本情報ページでエンドポイントを取得できます。

      ポート番号

      Amazon RDS for Oracleインスタンスのサービスポート番号。 デフォルト値: 1521

      Oracleタイプ

      • ソースデータベースのアーキテクチャ。 [非RACインスタンス] を選択した場合、SIDパラメーターを設定する必要があります。

      • RACまたはPDBインスタンスを選択した場合、サービス名パラメーターを設定する必要があります。

      この例では、[非RACインスタンス] が選択されています。

      データベースアカウント

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

      データベースパスワード

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

      宛先データベース

      データベースタイプ

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

      アクセス方法

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

      インスタンスリージョン

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

      RDSインスタンスID

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

      データベースアカウント

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

      データベースパスワード

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

      暗号化

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

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

    5. 自己管理データベースにIPアドレスホワイトリストが設定されている場合は、DTSサーバーのCIDRブロックをIPアドレスホワイトリストに追加します。 次に、接続テスト をクリックします。

      警告

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

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

      パラメーター

      説明

      移行タイプ

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

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

      説明

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

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

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

        説明

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

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

        警告

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

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

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

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

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

      ソースオブジェクト

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

      説明

      移行するオブジェクトとして、列、テーブル、またはデータベースを選択できます。

      選択中のオブジェクト

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

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

      説明

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

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

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

    7. クリック次条: 詳細設定詳細設定を設定します。

      • データ検証設定

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

      • 詳細設定

        パラメーター

        説明

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

        デフォルトでは、DTSはタスクを共有クラスターにスケジュールします。 このパラメーターを設定する必要はありません。 指定された仕様の専用クラスターを購入して、データ移行タスクを実行できます。 詳細については、「」をご参照ください。DTS専用クラスターとは

        Set Alerts

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

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

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

        説明

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

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

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

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

        重要

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

        完全なデータ移行のためのスロットリングを有効化

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

        説明

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

        完全なデータ移行のスロットリングを有効化

        増分データ移行タスクのスロットリングを有効にするかどうかを指定できます。 [はい] を選択した場合、ビジネス要件に基づいて 増分データ移行の RPS および 増分データ移行の BPS パラメーターを設定し、ターゲットインスタンスの負荷を軽減できます。

        説明

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

        ETLの設定

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

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

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

      説明

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

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

      • 事前チェック中にアイテムに対してアラートがトリガーされた場合:

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

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

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

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

      セクション

      パラメーター

      説明

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

      リソースグループ

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

      インスタンスクラス

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

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

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

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

    手順 (古いDTSコンソール)

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

      説明

      データ管理 (DMS) コンソールにリダイレクトされている場合は、にあるoldアイコンをクリックして、以前のバージョンのDTSコンソールに移動しimage。

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

    3. [移行タスク] ページの上部で、移行先クラスターが存在するリージョンを選択します。

    4. ページの右上隅にある [移行タスクの作成] をクリックします。

    5. ソースデータベースとターゲットデータベースを設定します。

      源库和目标库连接配置

      セクション

      パラメーター

      説明

      非該当

      タスク名

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

      移行元データベース

      インスタンスタイプ

      ソースデータベースのインスタンスタイプ。 [オンプレミスデータベース] を選択します。

      Instance Region

      ソースインスタンスが存在するリージョン。 ソースデータベースのインスタンスタイプとして [パブリックIPアドレスを持つユーザー作成データベース] を選択した場合、[インスタンスリージョン] パラメーターを設定する必要はありません。

      データベースエンジン

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

      Hostname or IP Address

      Amazon RDS for Oracleインスタンスへのアクセスに使用されるエンドポイント。

      説明

      Amazon RDS for Oracleインスタンスの基本情報ページでエンドポイントを取得できます。

      连接地址

      ポート番号

      Amazon RDS for Oracleインスタンスのサービスポート番号。 デフォルト値: 1521

      インスタンスタイプ

      • 非RACインスタンスを選択した場合、SIDパラメーターを設定する必要があります。

      • RACインスタンスを選択した場合、サービス名パラメーターを設定する必要があります。

      この例では、非RACインスタンスが選択される。 次に、SIDパラメーターを設定します。

      データベースアカウント

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

      データベースパスワード

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

      説明

      ソースデータベースのパラメーターを設定した後、[データベースパスワード] の横にある [接続のテスト] をクリックして、設定されたパラメーターが有効かどうかを確認します。 設定されたパラメーターが有効な場合、[合格] メッセージが表示されます。 [失敗] メッセージが表示された場合、[失敗] の横にある [チェック] をクリックして、チェック結果に基づいてソースデータベースパラメーターを変更します。

      ターゲットデータベース

      インスタンスタイプ

      ターゲットデータベースのインスタンスタイプ。 RDS インスタンスを選択します。

      インスタンスリージョン

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

      RDS インスタンス ID

      ApsaraDB RDS for MySQL インスタンスの ID です。

      データベースアカウント

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

      データベースパスワード

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

      説明

      ターゲットデータベースパラメーターを設定した後、[データベースパスワード] の横にある [接続のテスト] をクリックし、設定されたパラメーターが有効かどうかを確認します。 設定されたパラメーターが有効な場合、[合格] メッセージが表示されます。 [失敗] メッセージが表示された場合、[失敗] の横にある [チェック] をクリックし、チェック結果に基づいてターゲットデータベースパラメーターを変更します。

    6. ページの右下隅にあるをクリックします。ホワイトリストと次への設定.

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

      警告

      DTSサーバーのCIDRブロックがデータベースまたはインスタンスのホワイトリスト、またはECSセキュリティグループルールに自動的または手動で追加されると、セキュリティリスクが発生する可能性があります。 したがって、DTSを使用してデータを移行する前に、潜在的なリスクを理解して認識し、次の対策を含む予防策を講じる必要があります。VPNゲートウェイ、またはSmart Access Gateway。

    7. 移行するオブジェクトと移行タイプを選択します。

      选择迁移类型和对象

      設定

      説明

      移行タイプの選択

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

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

      説明

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

      移行するオブジェクトの選択

      [使用可能] セクションから1つ以上のオブジェクトを選択し、向右小箭头アイコンをクリックして、オブジェクトを [選択済み] セクションに移動します。

      説明

      • 移行するオブジェクトとして、列、テーブル、またはデータベースを選択できます。

      • 既定では、オブジェクトがターゲットデータベースに移行された後、オブジェクトの名前はターゲットデータベースで変更されません。 オブジェクト名マッピング機能を使用して、ApsaraDB RDS for MySQLインスタンスに移行されるオブジェクトの名前を変更できます。 詳細は、オブジェクト名のマッピングをご参照ください。

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

      オブジェクトの名前を変更するかどうかを指定する

      オブジェクト名マッピング機能を使用して、移行先インスタンスに移行されるオブジェクトの名前を変更できます。 詳細は、オブジェクト名のマッピングをご参照ください。

      ソースデータベースまたはターゲットデータベースへの接続が失敗した場合のリトライ時間範囲の指定

      デフォルトでは、DTSがソースデータベースまたはターゲットデータベースへの接続に失敗した場合、DTSは次の12時間以内に再試行します。 業務要件に基づいて再試行時間範囲を指定できます。 指定された再試行時間内にDTSがソースデータベースとターゲットデータベースに再接続すると、DTSはデータ移行タスクを再開します。 それ以外の場合、データ移行タスクは失敗します。

      説明

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

    8. ページの右下隅にある [事前チェック] をクリックします。

      説明

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

      • タスクが事前チェックに合格しなかった場合は、失敗した各項目の横にあるInfo iconアイコンをクリックして詳細を表示できます。

        • 原因に基づいて問題をトラブルシューティングし、事前チェックを再度実行できます。

        • 問題をトラブルシューティングする必要がない場合は、失敗した項目を無視して、再度事前チェックを実行できます。

    9. タスクが事前チェックに合格したら、[次へ] をクリックします。

    10. [設定の確認] ダイアログボックスで、[チャネル仕様] パラメーターを指定し、[データ送信サービス (従量課金) サービス規約] を選択します。

    11. [購入と開始] をクリックして、データ移行タスクを開始します。

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

        フルデータ移行中は、手動でタスクを停止しないことをお勧めします。 そうしないと、ターゲットデータベースに移行されたデータが不完全になる可能性があります。 データ移行タスクが自動的に停止するまで待つことができます。

      • スキーマ移行、完全データ移行、および増分データ移行

        増分データ移行タスクは自動的に停止しません。 タスクを手動で停止する必要があります。

        重要

        データ移行タスクを手動で停止する適切な時期を選択することを推奨します。 たとえば、オフピーク時やワークロードを移行先クラスターに切り替える前にタスクを停止できます。

        1. 増分データ移行と移行タスクが遅延しませんが移行タスクのプログレスバーに表示されるまで待ちます。 その後、ソースデータベースへのデータの書き込みを数分間停止します。 増分データ移行のレイテンシは、プログレスバーに表示され得る。

        2. 増分データ移行のステータスが [移行タスクは遅延なし] に変わるまで待ちます。 次に、移行タスクを手動で停止します。 Stop an incremental data migration task

    12. ワークロードをApsaraDB RDS for MySQLインスタンスに切り替えます。