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

Data Transmission Service:自己管理型PostgreSQLデータベースからAnalyticDB for PostgreSQLインスタンスへのデータの移行

最終更新日:Nov 01, 2024

このトピックでは、Data Transmission Service (DTS) を使用して、自己管理型PostgreSQLデータベースからAnalyticDB for PostgreSQLインスタンスにデータを移行する方法について説明します。

前提条件

  • 移行先のAnalyticDB for PostgreSQLインスタンスが作成されました。 詳細については、「インスタンスの作成」をご参照ください。

  • 移行先のAnalyticDB for PostgreSQLインスタンスの使用可能なストレージ容量は、移行元の自己管理型PostgreSQLデータベースのデータの合計サイズよりも大きくなっています。

使用上の注意

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

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

カテゴリ

説明

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

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

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

    ソースデータベースの名前にハイフン (-) を含めることはできません。 例: dts-testdata.

  • 移行するオブジェクトとしてテーブルを選択し、移行先データベースのテーブルや列の名前の変更など、テーブルを編集する必要がある場合は、1つのデータ移行タスクで最大1,000のテーブルを移行できます。 タスクを実行して1,000を超えるテーブルを移行すると、リクエストエラーが発生します。 この場合、複数のタスクを設定してテーブルを移行するか、タスクを設定してデータベース全体を移行することをお勧めします。

  • 増分データを移行する必要がある場合は、次の要件が満たされていることを確認する必要があります。

    • wal_levelパラメーターの値は、logicalに設定する必要があります。

    • 増分データ移行の場合、ソースデータベースの先書きログ (WAL) ログを24時間以上保存する必要があります。 完全データおよび増分データ移行の場合、ソースデータベースのWALログを少なくとも7日間保存する必要があります。 そうしないと、DTSはWALログの取得に失敗し、タスクが失敗する可能性があります。 例外的な状況では、データの不整合または損失が発生します。 完全なデータ移行が完了したら、保持期間を24時間以上に設定できます。 上記の要件に基づいて、WALログの保持期間を設定してください。 そうしないと、DTSのサービスレベル契約 (SLA) に記載されているサービスの信頼性とパフォーマンスが保証されない場合があります。

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

    • 自己管理型PostgreSQLデータベースでプライマリ /セカンダリの切り替えを実行すると、データ移行タスクは失敗します。

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

    • フルデータ移行のみを実行する場合は、データ移行中にソースデータベースにデータを書き込まないでください。 そうしないと、ソースデータベースとターゲットデータベースの間でデータの不一致が発生する可能性があります。 データの一貫性を確保するために、移行タイプとして完全データ移行と増分データ移行を選択することを推奨します。

  • 1つまたは複数の長期トランザクションがソースデータベースに存在し、増分データがデータ移行タスクで移行される場合、ソースデータベースの長期トランザクションがコミットされる前に生成されたWALログが蓄積される可能性があります。 その結果、ソースデータベースのディスク容量が不足する可能性があります。

その他の制限

  • データを移行するテーブルを追加最適化 (AO) テーブルにすることはできません。

  • 列マッピングが完全でないテーブルの移行に使用されている場合、またはソースとターゲットのテーブルスキーマに一貫性がない場合、ソースデータベースと比較してターゲットデータベースにない列のデータは失われます。

  • データの増分移行中に、移行するオブジェクトとしてスキーマを選択し、スキーマにテーブルを作成するか、RENAMEステートメントを実行してスキーマ内のテーブルの名前を変更する場合は、テーブルにデータを書き込む前にALTER table schema.table REPLICA IDENTITY FULL; ステートメントを実行する必要があります。

    説明

    上記のサンプルステートメントのスキーマテーブルを、実際のスキーマ名とテーブル名に置き換えます。

  • DTSは、増分データのDDLステートメント、増分テーブルのスキーマ、およびハートビート情報を取得するために、ソースデータベースに次の一時テーブルを作成します。 データ移行中は、ソースデータベースの一時テーブルを削除しないでください。 そうしないと、データ移行タスクが失敗する可能性があります。 DTSインスタンスがリリースされると、一時テーブルは自動的に削除されます。

    public.dts_pg_classpublic.dts_pg_attributepublic.dts_pg_typepublic.dts_pg_enumpublic.dts_postgres_heartbeatpublic.dts_ddl_command、およびpublic.dts_args_session

  • 増分データ移行のレイテンシを正確にするために、DTSはソースデータベースにdts_postgres_heartbeatという名前のハートビートテーブルを作成します。

  • 増分データ移行中、DTSはソースデータベースのレプリケーションスロットを作成します。 レプリケーションスロットの先頭にdts_sync_ があります。 DTSは、ストレージ使用量を減らすために、90分ごとにレプリケーションスロットの履歴データを自動的に消去します。

    説明

    データ移行タスクがリリースされたか失敗した場合、DTSは自動的にレプリケーションスロットをクリアします。 ApsaraDB RDS for PostgreSQLインスタンスでプライマリ /セカンダリの切り替えが実行されている場合、セカンダリデータベースにログインして、レプリケーションスロットを手動でクリアする必要があります。

  • データ移行タスクは、1つのデータベースからのみデータを移行できます。 複数のデータベースからデータを移行するには、データベースごとにデータ移行タスクを作成する必要があります。

  • データを移行する前に、移行元インスタンスと移行先クラスターのパフォーマンスに対するデータ移行の影響を評価します。 オフピーク時にデータを移行することを推奨します。 完全データ移行中、DTSはソースデータベースとターゲットデータベースの読み取りおよび書き込みリソースを使用します。 これは、データベースサーバの負荷を増加させる可能性がある。

  • 完全データ移行中、同時INSERT操作により、ターゲットデータベースのテーブルが断片化されます。 完全なデータ移行が完了すると、移行先データベースのテーブルスペースは移行元データベースのテーブルスペースよりも大きくなります。

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

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

  • DTSは、シーケンスなどのメタデータの有効性をチェックしません。 メタデータの有効性を手動で確認する必要があります。

  • ワークロードがターゲットデータベースに切り替えられた後、新しく書き込まれたシーケンスは、ソースデータベースのシーケンスの最大値から増加しません。 したがって、ワークロードをターゲットデータベースに切り替える前に、ソースデータベース内のシーケンスの最大値を照会する必要があります。 次に、クエリされた最大値をターゲットデータベースのシーケンスの開始値として指定する必要があります。 次のステートメントを実行して、ソースデータベース内のシーケンスの最大値を照会できます。

    do language plpgsql $$
    declare
      nsp name;
      rel name;
      val int8;
    begin
      for nsp,rel in select nspname,relname from pg_class t2 , pg_namespace t3 where t2.relnamespace=t3.oid and t2.relkind='S'
      loop
        execute format($_$select last_value from %I.%I$_$, nsp, rel) into val;
        raise notice '%',
        format($_$select setval('%I.%I'::regclass, %s);$_$, nsp, rel, val+1);
      end loop;
    end;
    $$;

課金

移行タイプ

インスタンス設定料金

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

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

無料です。

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

増分データ移行

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

移行タイプ

  • スキーマ移行

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

  • 完全なデータ移行

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

  • 増分データ移行

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

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

操作タイプ

SQL文

DML

挿入、更新、および削除

DDL

  • DDL操作は、2020年10月1日以降に作成されたデータ移行タスクでのみ移行できます。

    重要
    • 5月12日2023日より前に作成されたデータ移行タスクを使用してDDL操作を移行するには、データ移行タスクを設定する前に、ソースデータベースにトリガーと関数を作成してDDL情報を取得する必要があります。 詳細については、「トリガーと関数を使用してPostgreSQLデータベースの増分DDL移行を実装する」をご参照ください。

    • 増分データ移行は、BITタイプのデータをサポートしていません。

  • ソースデータベースのデータベースアカウントは、特権アカウントである必要があります。 DTSは、データ移行タスクで次のDDLステートメントをサポートします。

    • テーブルとドロップテーブルの作成

    • ALTER TABLE (RENAME TABLE、ADD COLUMN、ADD COLUMN DEFAULT、ALTER COLUMN TYPE、DROP COLUMN、ADD CONSTRAINT、ADD CONSTRAINT CHECK、およびALTER COLUMN DROP DEFAULTを含む)

    • TRUNCATE TABLE (ソースPolarDB for PostgreSQLクラスターのデータベースエンジンバージョンは、PostgreSQL V11以降である必要があります) 。

    • テーブルにインデックスを作成する

    重要
    • CASCADEやRESTRICTなど、DDLステートメントの追加情報を移行することはできません。

    • SET session_replication_role = replicaステートメントが実行されているセッションからDDLステートメントを移行することはできません。

    • 関数を呼び出して実行されるDDLステートメントを移行することはできません。

    • ソースデータベースによって一度に送信されたSQL文にDML文とDDL文の両方が含まれている場合、DTSはDDL文を移行しません。

    • ソースデータベースによって一度に送信されたSQL文に、移行されないDDL文が含まれている場合、DTSはDDL文を移行しません。

    • CREATE SEQUENCEステートメントはサポートされていません。

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

データベース

スキーマ移行

完全なデータ移行

増分データ移行

自己管理型 PostgreSQL データベース

pg_catalogの使用権限

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

スーパーユーザーロールの権限

AnalyticDB PostgreSQL

スキーマ所有者の権限。

説明

インスタンスの初期アカウントを使用できます。

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

準備

説明
  • ソースデータベースがAmazon RDS For PostgreSQLインスタンスである場合の準備方法の詳細については、「Amazon RDS for PostgreSQLインスタンスからApsaraDB RDS for PostgreSQLインスタンスへの増分データの移行」トピックの開始前のセクションを参照してください。 ソースデータベースがAmazon Aurora PostgreSQLインスタンスである場合の準備方法の詳細については、「Amazon Aurora PostgreSQLインスタンスからApsaraDB RDS For PostgreSQLインスタンスへの完全データの移行」トピックの準備1: Amazon Aurora PostgreSQLインスタンスのインバウンドルールの編集セクションを参照してください。

  • この例では、Linuxサーバー上で実行される自己管理型PostgreSQLデータベースが使用されます。

自己管理型PostgreSQLデータベースのバージョンが10.1以降の場合は、データ移行タスクを設定する前に、次の操作を実行する必要があります。

  1. 自己管理型PostgreSQLデータベースが存在するサーバーにログオンします。

  2. postgresql.conf設定ファイルを変更します。 wal_levelパラメーターをlogicalに設定し、max_wal_sendersパラメーターとmax_replication_slotsパラメーターの値が、セルフマネージドPostgreSQLデータベースで使用されているレプリケーションスロットの数と、ソースデータベースがセルフマネージドPostgreSQLデータベースであるDTSインスタンスの数の合計よりも大きいことを確認します。

    # - Settings -
    
    wal_level = logical			# minimal, replica, or logical
    					# (change requires restart)
    
    ......
    
    # - Sending Server(s) -
    
    # Set these on the master and on any standby that will send replication data.
    
    max_wal_senders = 10		# max number of walsender processes
    				# (change requires restart)
    #wal_keep_segments = 0		# in logfile segments, 16MB each; 0 disables
    #wal_sender_timeout = 60s	# in milliseconds; 0 disables
    
    max_replication_slots = 10	# max number of replication slots
    				# (change requires restart)
    説明

    設定ファイルを変更した後、自己管理型PostgreSQLデータベースを再起動して、パラメーター設定を有効にします。

  3. DTSサーバーのCIDRブロックを、自己管理型PostgreSQLデータベースのpg_hba.conf構成ファイルに追加します。 ターゲットデータベースと同じリージョンにあるDTSサーバーのCIDRブロックのみを追加します。 詳細については、「DTSサーバーのCIDRブロックの追加」をご参照ください。

    説明
    • 設定ファイルを変更した後、SELECT pg_reload_conf(); ステートメントを実行するか、自己管理型PostgreSQLデータベースを再起動して、パラメーター設定を有効にします。

    • pg_hba.conf設定ファイルの詳細については、「pg_hba.confファイル」をご参照ください。 pg_hba.confファイルのIPアドレスを0.0.0.0/0に設定している場合は、この手順をスキップします。 次の図は、設定を示しています。

    IP

  4. 移行するオブジェクトのデータベースとスキーマの情報に基づいて、移行先クラスターに対応するデータベースとスキーマを作成します。

自己管理型PostgreSQLデータベースのバージョンが9.4.8〜10.0の場合、データ移行タスクを設定する前に次の操作を実行する必要があります

  1. PostgreSQLソースコードを公式Webサイトからダウンロードし、ソースコードをコンパイルし、PostgreSQLをインストールします。

    1. からソースコードをダウンロードします。PostgreSQL公式ウェブサイトは、自己管理型PostgreSQLデータベースのバージョンに基づいています。

    2. を実行します。Run theスド /configure,sudo make、およびsudo make installコマンドを順番に実行して、ソースコードを設定およびコンパイルし、PostgreSQLをインストールします。

      重要
      • PostgreSQLをコンパイルしてインストールする場合、PostgreSQLのOSバージョンはGNUコンパイラコレクション (GCC) のバージョンと一致している必要があります。

      • を実行したときにエラーが発生した場合、スド /configureコマンドを変更すると、エラーメッセージに基づいてコマンドを変更できます。 たとえば、エラーメッセージがreadlineライブラリが見つかりません。 -- without-readlineを使用して、readlineサポートを無効にします。に変更することができます。スド /configure -- without-readline.

      • 別の方法を使用してPostgreSQLをインストールする場合は、同じオペレーティングシステムバージョンとGCCバージョンを持つテスト環境でali_decodingプラグインをコンパイルする必要があります。

  2. DTSが提供するali_decodingプラグインをダウンロードし、プラグインをコンパイルしてインストールします。

    1. ダウンロードali_decoding.

    2. コンパイルおよびインストールされているPostgreSQLのcontribディレクトリに、ali_decodingディレクトリをコピーします。

      contrib目录

    3. ali_decodingディレクトリに移動し、Makefileファイルの内容を次のスクリプトに置き換えます。

      # contrib/ali_decoding/Makefile
      MODULE_big = ali_decoding
      MODULES = ali_decoding
      OBJS    = ali_decoding.o
      
      DATA = ali_decoding--0.0.1.sql ali_decoding--unpackaged--0.0.1.sql
      
      EXTENSION = ali_decoding
      
      NAME = ali_decoding
      
      #subdir = contrib/ali_decoding
      #top_builddir = ../..
      #include $(top_builddir)/src/Makefile.global
      #include $(top_srcdir)/contrib/contrib-global.mk
      
      #PG_CONFIG = /usr/pgsql-9.6/bin/pg_config
      #pgsql_lib_dir := $(shell $(PG_CONFIG) --libdir)
      #PGXS := $(shell $(PG_CONFIG) --pgxs)
      #include $(PGXS)
      
      # Run the following commands to install the ali_decoding plug-in:
      ifdef USE_PGXS
      PG_CONFIG = pg_config
      PGXS := $(shell $(PG_CONFIG) --pgxs)
      include $(PGXS)
      else
      subdir = contrib/ali_decoding
      top_builddir = ../..
      include $(top_builddir)/src/Makefile.global
      include $(top_srcdir)/contrib/contrib-global.mk
      endif
    4. ali_decodingディレクトリに移動し、sudo makesudo make installコマンドを順番に実行して、ali_decodingプラグインをコンパイルし、ali_decodingプラグインのインストールに必要なファイルを取得します。

    5. 指定したディレクトリにファイルをコピーします。

      指定位置

  3. 移行するオブジェクトのデータベースとスキーマの情報に基づいて、移行先クラスターに対応するデータベースとスキーマを作成します。

手順

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

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

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

    3. DTS (DTS) > データ移行を選択します。

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

    説明

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

  3. [タスクの作成] をクリックします。 表示されるページで、ソースデータベースとターゲットデータベースを設定します。

    警告

    ソースインスタンスとターゲットインスタンスを選択した後、ページの上部に表示される [制限] セクションの手順を読むことを推奨します。 これは、データ移行タスクの作成と実行に役立ちます。

    カテゴリ

    パラメーター

    説明

    非該当

    タスク名

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

    移行元データベース

    既存の DMS データベースインスタンスを選択します。(任意です。DMS データベースインスタンスが未登録の場合は、このオプションを無視して、以下のセクションでデータベース設定を行ってください。)

    使用するデータベースインスタンス。 ビジネス要件に基づいて、既存のインスタンスを使用するかどうかを選択できます。

    • 既存のインスタンスを選択すると、DTSはデータベースのパラメーターを自動的に入力します。

    • 既存のインスタンスを選択しない場合は、次のデータベース情報を設定する必要があります。

    データベースタイプ

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

    アクセス方法

    自己管理型PostgreSQLデータベースがデプロイされている場所。 この例では、ECS 上の自己管理データベースが選択されています。

    説明

    ソースの自己管理型PostgreSQLデータベースにアクセスするために他の方法を選択した場合は、データベースのネットワーク環境をデプロイする必要があります。 詳細については、「準備の概要」をご参照ください。

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

    自己管理型PostgreSQLデータベースが存在するリージョン。

    ECS インスタンス ID

    自己管理型PostgreSQLデータベースがデプロイされているECSインスタンスのID。

    ポート番号

    自己管理型PostgreSQLデータベースのサービスポート番号。 デフォルト値: 5432

    データベース名

    自己管理型PostgreSQLデータベースの名前。

    データベースアカウント

    自己管理型PostgreSQLデータベースへのログインに使用されるアカウント。 アカウントに必要な権限の詳細については、このトピックの「データベースアカウントに必要な権限」をご参照ください。

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

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

    移行先データベース

    既存の DMS データベースインスタンスを選択します。(任意です。DMS データベースインスタンスが未登録の場合は、このオプションを無視して、以下のセクションでデータベース設定を行ってください。)

    使用するデータベースインスタンス。 ビジネス要件に基づいて、既存のインスタンスを使用するかどうかを選択できます。

    • 既存のインスタンスを選択すると、DTSはデータベースのパラメーターを自動的に入力します。

    • 既存のインスタンスを選択しない場合は、次のデータベース情報を設定する必要があります。

    データベースタイプ

    ターゲットデータベースのタイプ。 AnalyticDB for PostgreSQL を選択します。

    アクセス方法

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

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

    移行先のAnalyticDB for PostgreSQLインスタンスが存在するリージョン。

    インスタンス ID

    移行先のAnalyticDB for PostgreSQLインスタンスのIDを選択します。

    データベース名

    移行先AnalyticDB for PostgreSQLインスタンスでオブジェクトを移行するデータベースの名前。

    データベースアカウント

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

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

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

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

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

    警告

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

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

    パラメーター

    説明

    移行タイプ

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

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

    説明

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

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

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

      説明

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

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

      警告

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

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

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

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

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

    同期する DDL および DML 操作

    インスタンスレベルで増分移行するSQL操作を選択します。 詳細については、このトピックの「増分データ移行中に移行できるSQL操作」をご参照ください。

    説明

    特定のデータベースまたはテーブルで実行されるSQL操作を選択するには、次の手順を実行します。選択中のオブジェクト セクションで、オブジェクトを右クリックします。 表示されるダイアログボックスで、移行するSQL操作を選択します。

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

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

    ソースオブジェクト

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

    説明

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

    選択中のオブジェクト

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

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

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

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

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

  6. [次へ: 詳細設定] をクリックして詳細設定を構成します。

    • データ検証設定

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

    • 詳細設定

      パラメーター

      説明

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

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

      アラートの設定

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

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

      失敗した接続のリトライ時間範囲。 データ移行タスクの開始後にソースデータベースまたはターゲットデータベースの接続に失敗した場合、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とは何ですか?」をご参照ください。 有効な値:

  7. ページの下部で、次:データベースおよびテーブルのフィールド設定 をクリックします。 表示されるページで、移行先AnalyticDB for PostgreSQLインスタンスに移行するテーブルのプライマリキー列と配布キー列を設定します。

    説明

    このページは、移行タイプ パラメーターで スキーマ移行 が選択されている場合にのみ表示されます。 主キー列と配布列の詳細については、「テーブルの管理」および「テーブルの配布の定義」をご参照ください。

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

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

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

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

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

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

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

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

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

    セクション

    パラメーター

    説明

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

    リソースグループ

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

    インスタンスクラス

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

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

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

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