ソースとしての AWS DMS PostgreSQL データベースの使用 - AWS データベース移行サービス
セルフマネージド PostgreSQL データベースの使用 AWSマネージド PostgreSQL データベースの使用論理レプリケーションを使用して移行CDC中に を有効にするネイティブCDC開始ポイントを使用したCDC負荷の設定PostgreSQL から PostgreSQL への移行Babelfish から移行するPostgreSQL ソースからのアーティファクトの削除ソースとしての PostgreSQL の詳細設定 MapBooleanAsBoolean PostgreSQL エンドポイント設定の使用エンドポイントとECA設定ソースとしての PostgreSQL の制限Postgre のソースデータ型SQL

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ソースとしての AWS DMS PostgreSQL データベースの使用

を使用して、1 つ以上の PostgreSQL データベースからデータを移行できます AWS DMS。PostgreSQL データベースをソースとして使用すると、別の PostgreSQL データベースまたは他のサポートされているデータベースのいずれかにデータを移行できます。

がソースとして AWS DMS サポートする PostgreSQL のバージョンについては、「」を参照してくださいのソース AWS DMS。

AWS DMS は、次のタイプのデータベースに対して PostgreSQL をサポートしています。

  •  オンプレミスのデータベース

  • Amazon EC2インスタンス上のデータベース

  • Amazon RDS DB インスタンスのデータベース

  • Amazon Aurora Postgre SQL互換エディションに基づく DB インスタンス上のデータベース

  • Amazon Aurora Postgre SQL互換サーバーレスエディションに基づく DB インスタンス上のデータベース

注記

DMS は、全ロードのソースとしてのみ Amazon Aurora Postgre SQL- サーバーレス V1 をサポートします。ただし、Amazon Aurora Postgre SQL- サーバーレス V2 は、全ロード、全ロード + CDC、および タスクCDCのみのソースとして使用できます。

PostgreSQL ソースバージョン

AWS DMS 使用する バージョン

9.x、10.x、11.x、12.x

使用可能な任意の AWS DMS バージョンを使用します。

13.x

AWS DMS バージョン 3.4.3 以降を使用します。

14.x

AWS DMS バージョン 3.4.7 以降を使用します。

15.x

AWS DMS バージョン 3.5.1 以降を使用します。

16.x

AWS DMS バージョン 3.5.3 以降を使用します。

Secure Socket Layers (SSL) を使用して、PostgreSQL エンドポイントとレプリケーションインスタンス間の接続を暗号化できます。PostgreSQL エンドポイントSSLで を使用する方法の詳細については、「」を参照してくださいSSL で を使用する AWS Database Migration Service。

PostgreSQL をソースとして使用する場合の追加のセキュリティ要件として、指定するユーザーアカウントは PostgreSQL データベースに登録されたユーザーである必要があります。

PostgreSQL データベースを AWS DMS ソースエンドポイントとして設定するには、次の手順を実行します。

のソースとしてのセルフマネージド PostgreSQL データベースの使用 AWS DMS

ソースとしてセルフマネージド PostgreSQL データベースを使用すると、別の PostgreSQL データベース、または でサポートされている他のターゲットデータベースのいずれかにデータを移行できます AWS DMS。データベースソースは、オンプレミスデータベースでも、Amazon EC2インスタンスで実行されているセルフマネージドエンジンでもかまいません。DB インスタンスは、全ロードタスクと変更データキャプチャ (CDC) タスクの両方に使用できます。

セルフマネージド PostgreSQL データベースを AWS DMS ソースとして使用するための前提条件

セルフマネージド PostgreSQL ソースデータベースからデータを移行する前に、次の操作を行います。

  • バージョン 9.4.x 以降の PostgreSQL データベースを使用していることを確認してください。

  • 全ロードプラスCDCタスクまたは CDCのみのタスクの場合は、PostgreSQL ソースデータベースに指定されたユーザーアカウントのスーパーユーザーアクセス許可を付与します。ユーザー アカウントはソース内のレプリケーション固有機能にアクセスするには、スーパーユーザー許可が必要です。全ロードのみのタスクの場合、ユーザーアカウントには、それらを移行するためのテーブルに対するSELECTアクセス許可が必要です。

  • AWS DMS レプリケーションサーバーの IP アドレスpg_hba.confを設定ファイルに追加し、レプリケーションとソケット接続を有効にします。以下に例を示します。

    
            # Replication Instance
            host all all 12.3.4.56/00 md5
            # Allow replication connections from localhost, by a user with the
            # replication privilege.
            host replication dms 12.3.4.56/00 md5

    Postgre SQLpg_hba.confの設定ファイルは、クライアント認証を制御します (HBA はホストベースの認証を表します）。ファイルは従来、データベースクラスターのデータディレクトリに保存されています。

  • を使用して論理レプリケーションのソースとしてデータベースを設定する場合は、 AWS DMS 「」を参照してください。 セルフマネージド PostgreSQL データベースCDCを AWS DMS ソースとして使用するための有効化

注記

一部の AWS DMS トランザクションは、DMSエンジンが再度使用する前にしばらくアイドル状態になっています。PostgreSQL バージョン 9.6 以降idle_in_transaction_session_timeoutで パラメータを使用すると、アイドル状態のトランザクションがタイムアウトして失敗する可能性があります。 AWS DMSを使用する際、アイドル状態のトランザクションを終了しないでください。

セルフマネージド PostgreSQL データベースCDCを AWS DMS ソースとして使用するための有効化

AWS DMS は、論理レプリケーションを使用した変更データキャプチャ (CDC) をサポートします。セルフマネージド PostgreSQL ソースデータベースの論理レプリケーションを有効にするには、postgresql.conf設定ファイルに次のパラメータと値を設定します。

  • wal_level = logical を設定します。

  • max_replication_slots を 1 より大きい値に設定します。

    max_replication_slots 値は、実行するタスクの数に従って設定してください。たとえば、5 つのタスクを実行するには、少なくとも 5 つのスロットを設定する必要があります。スロットは、タスクが開始するとすぐに自動的に開き、タスクが実行されなくなった場合でも開いたままです。開いているスロットは手動で削除してください。がスロットDMSを作成した場合、タスクが削除されると、 はレプリケーションスロットDMSを自動的に削除します。

  • max_wal_senders を 1 より大きい値に設定します。

    max_wal_senders パラメータは、実行可能な同時タスクの数を設定します。

  • wal_sender_timeout パラメータは、指定されたミリ秒数が過ぎても非アクティブなレプリケーション接続を終了します。オンプレミス PostgreSQL データベースのデフォルトは 60000 ミリ秒 (60 秒) です。値を 0 (ゼロ) に設定すると、タイムアウトメカニズムが無効になり、 の有効な設定になりますDMS。

    wal_sender_timeout をゼロ以外の値に設定する場合、 のDMSタスクには最低 10000 ミリ秒 (10 秒) CDCが必要であり、値が 10000 未満の場合に失敗します。レDMSプリケーションインスタンスのマルチ AZ フェイルオーバー中に遅延が発生しないように、値は 5 分未満に保ちます。

一部のパラメータは静的であり、サーバースタート時にのみ設定できます。設定ファイル (セルフマネージドデータベースの場合) または DB パラメータグループ ( RDS for PostgreSQL データベースの場合) のエントリへの変更は、サーバーが再起動されるまで無視されます。詳細については、PostgreSQL のドキュメントを参照してください。

CDC の有効化の詳細については「論理レプリケーションを使用した変更データキャプチャ (CDC) の有効化」をご覧ください。

AWSマネージド PostgreSQL データベースをDMSソースとして使用する

AWSマネージド PostgreSQL DB インスタンスをソースとして使用できます AWS DMS。 AWSマネージド PostgreSQL ソースを使用して、全ロードタスクと変更データキャプチャ (CDC) タスクの両方を実行できます。

が AWS管理する PostgreSQL データベースをDMSソースとして使用するための前提条件

マネージド Postgre AWS SQL ソースデータベースからデータを移行する前に、次の操作を行います。

  • PostgreSQL DB インスタンスに必要な最小限のアクセス許可を持つ AWS ユーザーアカウントを、PostgreSQL ソースエンドポイントのユーザーアカウントとして使用することをお勧めします AWS DMS。管理アカウントの使用はお勧めしません。このアカウントには rds_superuser ロールと rds_replication ロールが必要です。rds_replication ロールは、論理スロットを管理し、論理スロットを使用してデータをストリーミングするアクセス権許可付与します。

    使用するアカウントの管理ユーザーアカウントで複数のオブジェクトを作成します。その作成についての詳細は、「マスターユーザーアカウントを使用せずに Amazon RDS for PostgreSQL データベースを移行する」をご参照ください。

  • ソースデータベースが仮想プライベートクラウド (VPC) にある場合は、データベースが存在する DB インスタンスへのアクセスを提供するVPCセキュリティグループを選択します。これは、DMSレプリケーションインスタンスがソース DB インスタンスに正常に接続するために必要です。データベースとDMSレプリケーションインスタンスが同じ にある場合はVPC、適切なセキュリティグループを独自のインバウンドルールに追加します。

注記

一部の AWS DMS トランザクションは、DMSエンジンが再度使用する前にしばらくアイドル状態になっています。PostgreSQL バージョン 9.6 以降idle_in_transaction_session_timeoutで パラメータを使用すると、アイドル状態のトランザクションがタイムアウトして失敗する可能性があります。 AWS DMSを使用する際、アイドル状態のトランザクションを終了しないでください。

CDC で AWSマネージド PostgreSQL DB インスタンスで を有効にする AWS DMS

AWS DMS は、DB インスタンスが論理レプリケーションを使用するように設定されている場合、Amazon RDS PostgreSQL データベースCDCで をサポートします。次の表は、各 AWSマネージド PostgreSQL バージョンの論理レプリケーション互換性をまとめたものです。

RDS PostgreSQL リードレプリカを CDC (継続的なレプリケーション) に使用することはできません。

PostgreSQL バージョン

AWS DMS フルロードのサポート

AWS DMS CDC サポート

PostgreSQL 10.5 互換の Aurora PostgreSQL バージョン 2.1 (またはそれ以前）

あり

いいえ

PostgreSQL 10.6 互換の Aurora PostgreSQL バージョン 2.2 (またはそれ以降）

はい

あり

RDS for PostgreSQL と PostgreSQL 10.21 との互換性 (またはそれ以降）

はい

あり
RDS PostgreSQL DB インスタンスの論理レプリケーションを有効にするには

  1. PostgreSQL DB インスタンスの AWS マスターユーザーアカウントを PostgreSQL ソースエンドポイントのユーザーアカウントとして使用します。マスターユーザーアカウントには、 の設定に必要なロールがありますCDC。

    マスター ユーザーアカウント以外のアカウントを使用する場合は、使用するアカウントのマスター ユーザーアカウントから複数のオブジェクトを作成する必要があります。詳細については、「マスターユーザーアカウントを使用せずに Amazon RDS for PostgreSQL データベースを移行する」を参照してください。

  2. DB rds.logical_replicationパラメータグループの CLUSTERパラメータを 1 に設定します。この静的パラメータを有効にするには、DB インスタンスを再起動する必要があります。このパラメータを適用する一環として、 AWS DMS は wal_level、max_wal_senders、max_replication_slots、max_connections の各パラメータを設定します。これらのパラメータの変更により、先書きログ (WAL) の生成が増加する可能性があるため、論理レプリケーションスロットを使用するrds.logical_replication場合にのみ設定されます。

  3. wal_sender_timeout パラメータは、指定されたミリ秒数が過ぎても非アクティブなレプリケーション接続を終了します。 AWSマネージド PostgreSQL データベースのデフォルトは 30000 ミリ秒 (30 秒) です。値を 0 (ゼロ) に設定すると、タイムアウトメカニズムが無効になり、 の有効な設定になりますDMS。

    wal_sender_timeout をゼロ以外の値に設定する場合、 のDMSタスクには最低 10000 ミリ秒 (10 秒) CDCが必要で、値が 0 から 10000 の間であれば失敗します。レDMSプリケーションインスタンスのマルチ AZ フェイルオーバー中に遅延が発生しないように、値は 5 分未満に保ちます。

  4. DB クラスター パラメータグループで max_worker_processes パラメータの値が、max_logical_replication_workers、autovacuum_max_workers、max_parallel_workersの合計値以上となるようにしてください。多数のバックグラウンド ワーカー プロセスが、スモールインスタンスではアプリケーション ワークロードに影響を与える可能性があります。したがって、max_worker_processes をデフォルト値より大きく設定した場合は、データベースのパフォーマンスをモニタリングしてください。

  5. Aurora PostgreSQL を でソースとして使用する場合はCDC、 synchronous_commitを に設定しますON。

マスターユーザーアカウントを使用せずに Amazon RDS for PostgreSQL データベースを移行する

場合によっては、ソースとして使用している Amazon RDS PostgreSQL DB インスタンスのマスターユーザーアカウントを使用しないことがあります。このような場合は、複数のオブジェクトを作成して、データ定義言語 (DDL) イベントをキャプチャします。マスターアカウント以外のアカウントでこれらのオブジェクトを作成し、マスターユーザーアカウントでトリガーを作成します。

注記

ソースエンドポイントで CaptureDdls エンドポイント設定を false に設定すると、ソースデータベース上で次のテーブルおよびトリガーを作成する必要はありません。

これらのオブジェクトを作成するには、以下の手順を実行します。

オブジェクトを作成するには

  1. オブジェクトが作成されるスキーマを選択します。デフォルトのスキーマは public です。スキーマが存在し、OtherThanMaster アカウントからアクセス可能であることを確認します。

  2. マスターアカウント以外のユーザーアカウント、ここでアカウントを使用して PostgreSQL DB インスタンスにログインしますOtherThanMaster。

  3. 以下のコマンドを実行し、以下のコード内の objects_schema を使用するスキーマの名前に置き換えて awsdms_ddl_audit テーブルを作成します。

    
CREATE TABLE objects_schema.awsdms_ddl_audit
(
  c_key    bigserial primary key,
  c_time   timestamp,    -- Informational
  c_user   varchar(64),  -- Informational: current_user
  c_txn    varchar(16),  -- Informational: current transaction
  c_tag    varchar(24),  -- Either 'CREATE TABLE' or 'ALTER TABLE' or 'DROP TABLE'
  c_oid    integer,      -- For future use - TG_OBJECTID
  c_name   varchar(64),  -- For future use - TG_OBJECTNAME
  c_schema varchar(64),  -- For future use - TG_SCHEMANAME. For now - holds current_schema
  c_ddlqry  text         -- The DDL query associated with the current DDL event
);

  4. 以下のコマンドを実行して awsdms_intercept_ddl 関数を作成します。コード内の objects_schema は、使用するスキーマの名前に置き換えてください。

    
CREATE OR REPLACE FUNCTION objects_schema.awsdms_intercept_ddl()
  RETURNS event_trigger
LANGUAGE plpgsql
SECURITY DEFINER
  AS $$
  declare _qry text;
BEGIN
  if (tg_tag='CREATE TABLE' or tg_tag='ALTER TABLE' or tg_tag='DROP TABLE' or tg_tag = 'CREATE TABLE AS') then
         SELECT current_query() into _qry;
         insert into objects_schema.awsdms_ddl_audit
         values
         (
         default,current_timestamp,current_user,cast(TXID_CURRENT()as varchar(16)),tg_tag,0,'',current_schema,_qry
         );
         delete from objects_schema.awsdms_ddl_audit;
end if;
END;
$$;

  5. OtherThanMaster アカウントからログアウトし、rds_superuser ロールが割り当てられたアカウントを使用してログインします。

  6. 以下のコマンドを実行してイベントトリガー awsdms_intercept_ddl を作成します。

    
CREATE EVENT TRIGGER awsdms_intercept_ddl ON ddl_command_end 
EXECUTE PROCEDURE objects_schema.awsdms_intercept_ddl();

  7. これらのイベントにアクセスするすべてのユーザーとロールに必要なDDLアクセス許可があることを確認します。以下に例を示します。

    grant all on public.awsdms_ddl_audit to public;
grant all on public.awsdms_ddl_audit_c_key_seq to public;

前の手順を完了したら、OtherThanMaster アカウントを使用して AWS DMS ソースエンドポイントを作成できます。

注記

これらのイベントは、CREATE TABLE、ALTER TABLE、および DROP TABLE ステートメントによってトリガーされます。

論理レプリケーションを使用した変更データキャプチャ (CDC) の有効化

Postgre SQLのネイティブ論理レプリケーション機能を使用して、PostgreSQL ソースのデータベース移行中に変更データキャプチャ (CDC) を有効にできます。この機能は、セルフマネージド PostgreSQL と Amazon RDS for PostgreSQL SQL DB インスタンスで使用できます。このアプローチにより、ダウンタイムが短縮され、ターゲットデータベースがソース PostgreSQL データベースと確実に同期されます。

AWS DMS は、プライマリキーを持つ PostgreSQL テーブルCDCの をサポートします。テーブルにプライマリキーがない場合、先行書き込みログ (WAL) にはデータベース行の前イメージは含まれません。この場合は、DMS はテーブルを更新できません。ここでは、追加の構成設定を使用し、回避策としてテーブルレプリカ アイデンティティを使用できます。ただし、この方法では追加のログが生成される可能性があります。注意深いテストの後にのみ、回避策としてテーブルレプリカ アイデンティティ を使用することをお勧めします。詳細については、「PostgreSQL データベースをDMSソースとして使用する場合の追加設定」を参照してください。

注記

REPLICA IDENTITY FULL は論理デコードプラグインでサポートされていますが、pglogical プラグインではサポートされていません。詳細については、「pglogical ドキュメント」を参照してください。

全ロードCDCおよび タスクCDCのみの場合、 は論理レプリケーションスロット AWS DMS を使用して、WALログがデコードされるまでレプリケーション用のログを保持します。全ロードおよびCDCタスクまたはタスクの再起動 (再開ではない) 時にCDC、レプリケーションスロットが再作成されます。

注記

論理デコードの場合、 DMSは test_decoding または pglogical プラグインを使用します。pglogical プラグインがソース PostgreSQL データベースで利用可能な場合、 は pglogical を使用してレプリケーションスロットDMSを作成します。それ以外の場合は test_decoding プラグインが使用されます。test_decoding プラグインの詳細については、「PostgreSQL ドキュメント」を参照してください。

データベースパラメータmax_slot_wal_keep_sizeがデフォルト値以外の値に設定されていて、レプリケーションスロットrestart_lsnの がこのサイズLSNを超えて現在の より遅れている場合、必要なWALファイルの削除によりDMSタスクは失敗します。

pgglogical プラグインの設定

PostgreSQL 拡張機能として実装された pglogical プラグインは、選択的データレプリケーション用の論理レプリケーションシステムとモデルです。次の表は、pglogical プラグインをサポートするソース PostgreSQL データベースのバージョンを示しています。

PostgreSQL ソース

plogical のサポート

セルフマネージド PostgreSQL 9.4 以降

あり

Amazon RDS PostgreSQL 9.5 以前

いいえ

Amazon RDS PostgreSQL 9.6 以降

あり

Aurora PostgreSQL 1.x から 2.5.x まで

いいえ

Aurora PostgreSQL 2.6.x 以降

あり

Aurora PostgreSQL 3.3.x 以降

あり

で使用する pglogical を設定する前に AWS DMS、まず PostgreSQL ソースデータベースで変更データキャプチャ (CDC) の論理レプリケーションを有効にします。

PostgreSQL ソースデータベースで論理レプリケーションを有効にしたら、次のステップを使用して、 で使用する pglogical を設定しますDMS。

で PostgreSQL ソースデータベースの論理レプリケーションに pglogical プラグインを使用するには AWS DMS

  1. ソース PostgreSQL データベースに pglogical 拡張機能を作成します。

    1. 正しいパラメータを設定します：

      • セルフマネージド PostgreSQL データベースの場合は、データベースパラメータ を設定しますshared_preload_libraries= 'pglogical'。

      • Amazon RDSおよび Amazon Aurora PostgreSQLSQL-Compatible Edition データベースの Postgre の場合、同じパラメータグループpglogicalで RDS パラメータshared_preload_librariesを に設定します。

    2. PostgreSQL ソースデータベースを再起動します。

    3. PostgreSQL データベースで、 コマンドを実行します。 create extension pglogical;

  2. pglogical が正常にインストールされたことを確認するには、次のコマンドを実行します：

    select * FROM pg_catalog.pg_extension

PostgreSQL ソースデータベースエンドポイントの変更データキャプチャを実行する AWS DMS タスクを作成できるようになりました。

注記

PostgreSQL ソースデータベースで pglogical を有効にしない場合、 はデフォルトで test_decodingプラグイン AWS DMS を使用します。pglogical が論理デコードに対して有効になっている場合、 はデフォルトで pglogical AWS DMS を使用します。ただし、代わりに test_decoding のプラグインを使用する追加の接続属性 PluginName を設定することもできます。

ネイティブCDC開始ポイントを使用した PostgreSQL ソースのCDCロードの設定

PostgreSQL をソースとするネイティブCDC開始ポイントを有効にするには、エンドポイントの作成時にslotName追加の接続属性を既存の論理レプリケーションスロットの名前に設定します。この論理レプリケーションスロットは、エンドポイントの作成時点からの継続的な変更を保持するため、以前の時点からのレプリケーションをサポートします。

PostgreSQL は、 が論理レプリケーションスロットから変更を AWS DMS 正常に読み取った後にのみ破棄されるWALファイルにデータベースの変更を書き込みます。論理レプリケーションスロットを使用すると、ログに記録された変更がレプリケーションエンジンによって消費される前に削除されないように保護できます。

ただし、変更率と消費率によっては、論理レプリケーションスロットに保持されている変更により、ディスク使用率が高くなることがあります。論理レプリケーションスロットを使用する場合は、ソース PostgreSQL インスタンスでスペース使用量アラームを設定することをお勧めします。追加の slotName 接続属性の設定についての詳細は、「PostgreSQL をDMSソースとして使用する場合のエンドポイント設定と追加の接続属性 (ECAs）」をご参照ください。

次の手順では、このアプローチについて詳しく説明します。

ネイティブCDC開始ポイントを使用して PostgreSQL ソースエンドポイントのCDCロードを設定するには

  1. 開始点として使用する以前のレプリケーションタスク (親タスク) によって使用されていた論理レプリケーションスロットを特定します。次に、ソースデータベースの pg_replication_slots ビューにクエリを実行して、このスロットにアクティブな接続がないことを確認します。その場合は、先に進む前に解決して終了します。

    次のステップでは、論理レプリケーションスロットが abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef であると仮定します。

  2. 次の追加接続属性設定を含む新しいソースエンドポイントを作成します。

    slotName=abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef;

  3. コンソール AWS CLI または を使用して、新しい CDCのみのタスクを作成します AWS DMS API。たとえば、 を使用して、次のcreate-replication-taskコマンドCLIを実行できます。

    aws dms create-replication-task --replication-task-identifier postgresql-slot-name-test 
--source-endpoint-arn arn:aws:dms:us-west-2:012345678901:endpoint:ABCD1EFGHIJK2LMNOPQRST3UV4 
--target-endpoint-arn arn:aws:dms:us-west-2:012345678901:endpoint:ZYX9WVUTSRQONM8LKJIHGF7ED6 
--replication-instance-arn arn:aws:dms:us-west-2:012345678901:rep:AAAAAAAAAAA5BB4CCC3DDDD2EE 
--migration-type cdc --table-mappings "file://mappings.json" --cdc-start-position "4AF/B00000D0" 
--replication-task-settings "file://task-pg.json"

    前述のコマンドでは、次のオプションが設定されています。

    • source-endpoint-arn は、ステップ 2 で作成した新しい値に設定されます。

    • replication-instance-arn オプションは、ステップ 1 の親タスクと同じ値に設定されます。

    • table-mappings および replication-task-settings オプションは、ステップ 1 の親タスクと同じ値に設定されます。

    • cdc-start-position はオプションはスタート位置の値に設定されます。この開始位置を調べるには、ソースデータベースの pg_replication_slots ビューにクエリを実行するか、ステップ 1 で親タスクのコンソール詳細を表示します。詳細については、「CDC ネイティブのスタートポイントの決定」を参照してください。

    AWS DMS コンソールを使用して新しい CDCのみのタスクを作成するときにカスタムCDC開始モードを有効にするには、次の手順を実行します。

    • 「タスク設定」セクションのCDC「ソーストランザクションの開始モード」で、「カスタムCDC開始モードを有効にする」を選択します。

    • ソーストランザクションのカスタムCDC開始ポイントで、ログシーケンス番号を指定するを選択します。システム変更番号を指定するか、[復旧チェックポイントを指定する] を選択して、復旧チェックポイントを指定する。

    このCDCタスクを実行すると、指定された論理レプリケーションスロットが存在しない場合に、 はエラー AWS DMS を発生させます。また、cdc-start-position の有効な設定を使用してタスクが作成されていない場合、エラーを返します。

pglogical プラグインでネイティブCDC開始ポイントを使用し、新しいレプリケーションスロットを使用する場合は、CDCタスクを作成する前に以下のセットアップステップを完了します。

以前に別のDMSタスクの一部として作成されていない新しいレプリケーションスロットを使用するには

  1. 次に示すように、レプリケーション スロットを作成します：

    SELECT * FROM pg_create_logical_replication_slot('replication_slot_name', 'pglogical');

  2. データベースがレプリケーションスロットを作成した後、次のとおりスロットの restart_lsn と confirmed_flush_lsn の値を取得してメモしておきます。

    select * from pg_replication_slots where slot_name like 'replication_slot_name';

    レプリケーションスロットの後に作成されたCDCタスクのネイティブCDC開始位置は、Confirmed_flush_lsn 値より古くすることはできません。

    restart_lsn と confirmed_flush_lsn の値の詳細については、「pg_replication_slots」を参照してください。

  3. pglogical ノードを作成します。

    SELECT pglogical.create_node(node_name := 'node_name', dsn := 'your_dsn_name');

  4. pglogical.create_replication_set 関数を使用して 2 つのレプリケーションセットを作成します。最初のレプリケーションセットは、プライマリキーを持つテーブルの更新と削除を追跡します。2 番目のレプリケーションセットは挿入のみを追跡し、最初のレプリケーションセットと同じ名前にプレフィックス「i」が追加されています。

    SELECT pglogical.create_replication_set('replication_slot_name', false, true, true, false);
SELECT pglogical.create_replication_set('ireplication_slot_name', true, false, false, true);

  5. レプリケーション集合にテーブルを追加します。

    SELECT pglogical.replication_set_add_table('replication_slot_name', 'schemaname.tablename', true);
SELECT pglogical.replication_set_add_table('ireplication_slot_name', 'schemaname.tablename', true);

  6. ソースエンドポイントを作成するときに、追加の接続属性 (ECA) を設定します。

    PluginName=PGLOGICAL;slotName=slot_name;

新しいレプリケーションスロットを使用して、PostgreSQL ネイティブ開始ポイントでCDC唯一のタスクを作成できるようになりました。pglogical プラグインの詳細については、「pglogical 3.7 ドキュメント」を参照してください。

を使用した PostgreSQL から PostgreSQL への移行 AWS DMS

PostgreSQL 以外のデータベースエンジンから PostgreSQL データベースに移行する場合、 AWS DMS はほとんどの場合、最適な移行ツールです。ただし、PostgreSQL データベースから PostgreSQL データベースに移行する場合、PostgreSQL ツールはより効果的です。

PostgreSQL ネイティブツールを使用してデータを移行する

pg_dump 以下の条件下で、 などの PostgreSQL データベース移行ツールを使用することをお勧めします。

  • ソース PostgreSQL データベースからターゲット PostgreSQL データベースに移行する同種移行があります。

  • データベース全体を移行する。

  • ネイティブツールで最小のダウンタイムでデータを移行できる。

pg_dump ユーティリティは、 COPY コマンドを使用して PostgreSQL データベースのスキーマとデータダンプを作成します。pg_dump によって生成されるダンプ スクリプトは、同じ名前のデータベースにデータをロードし、テーブル、インデックス、外部キーを再作成します。pg_restore コマンドと -d パラメータを使用して、データを別の名前でデータベースに復元できます。

で実行されている PostgreSQL ソースデータベースから Amazon RDS for PostgreSQL ターゲットEC2にデータを移行する場合は、pglogical プラグインを使用できます。

PostgreSQL データベースを Amazon RDS for Postgre または Amazon Aurora Postgre SQL互換エディションにインポートする方法の詳細については、SQL「」を参照してくださいhttps://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Procedural.Importing.html。

DMS を使用して PostgreSQL から Postgre にデータを移行するSQL

AWS DMS は、例えば、オンプレミスのソース PostgreSQL データベースからターゲット Amazon RDS for PostgreSQL または Aurora PostgreSQL インスタンスにデータを移行できます。コアまたは基本的な PostgreSQL データ型は、ほとんどの場合、正常に移行されます。

注記

パーティション分割されたテーブルを PostgreSQL ソースから PostgreSQL ターゲットにレプリケートする場合、親テーブルをDMSタスクの選択条件の一部として言及する必要はありません。親テーブルに言及すると、ターゲット上の子テーブルでデータが複製され、PK 違反が発生する可能性があります。テーブルマッピングの選択基準で子テーブルのみを選択すると、親テーブルに自動代入されます。

ソースデータベースでサポートされているが、ターゲットでサポートされていないデータ型は、正常に移行されない場合があります。データ型が不明な場合、 は一部のデータ型を文字列として AWS DMS ストリーミングします。XML や などの一部のデータ型はJSON、小さなファイルとして正常に移行できますが、大きなドキュメントの場合は失敗する可能性があります。

データ型の移行を実行するときは、以下について注意してください：

  • 場合によっては、PostgreSQL NUMERIC(p,s) データ型は精度とスケールを指定しません。DMS バージョン 3.4.2 以前では、 は精度 28、スケールはデフォルトで 6 NUMERIC(28,6) DMSを使用します。例えば、ソースの値 0.611111104488373 は、PostgreSQL ターゲットで 0.61111 に変換されます。

  • ARRAY データ型のテーブルにはプライマリキーが必要です。データARRAY型にプライマリキーがないテーブルは、全ロード中に中断されます。

次の表は、ソース PostgreSQL データ型と、それらを正常に移行できるかどうかを示しています。

データ型 正常に移行 部分的に移行 移行しない コメント
INTEGER X
SMALLINT X
BIGINT X
NUMERIC/ DECIMAL(p,s) X この場合、0<p<39 と 0<s
NUMERIC/DECIMAL X この場合、p>38 または p=s=0
REAL X
DOUBLE X
SMALLSERIAL X
SERIAL X
BIGSERIAL X
MONEY X
CHAR X 精度の指定なし
CHAR(n) X
VARCHAR X 精度の指定なし
VARCHAR(n) X
TEXT X
BYTEA X
TIMESTAMP X 正と負の無限大値はそれぞれ '9999-12-31 23:59:59 'と '4713-01-01 00:00:00 BC' に切り捨てられます。
TIMESTAMP WITH TIME ZONE X
DATE X
TIME X
TIME WITH TIME ZONE X
INTERVAL X
BOOLEAN X
ENUM X
CIDR X
INET X
MACADDR X
TSVECTOR X
TSQUERY X
XML X
POINT X 空間後GISデータ型
LINE X
LSEG X
BOX X
PATH X
POLYGON X 空間後GISデータ型
CIRCLE X
JSON X
ARRAY X プライマリ キーが必要です
COMPOSITE X
RANGE X
LINESTRING X 空間後GISデータ型
MULTIPOINT X 空間後GISデータ型
MULTILINESTRING X 空間後GISデータ型
MULTIPOLYGON X 空間後GISデータ型
GEOMETRYCOLLECTION X 空間後GISデータ型

ポストGIS空間データ型の移行

空間データは、空間内のオブジェクトまたは位置のジオメトリ情報を識別します。PostgreSQL オブジェクトリレーショナルデータベースは、PostGIS 空間データ型をサポートしています。

PostgreSQL 空間データオブジェクトを移行する前に、PostGIS プラグインがグローバルレベルで有効になっていることを確認してください。これにより、 は PostgreSQL ターゲット DB インスタンスの正確なソース空間データ列 AWS DMS を作成します。

PostgreSQL から PostgreSQL への同種移行の場合、 は Post GISのジオメトリおよび地理的 (ジオメトリ座標) データオブジェクトタイプとサブタイプの移行 AWS DMS をサポートします。次に例を示します。

  • POINT

  • LINESTRING

  • POLYGON

  • MULTIPOINT

  • MULTILINESTRING

  • MULTIPOLYGON

  • GEOMETRYCOLLECTION

を使用した Babelfish for Amazon Aurora PostgreSQL からの移行 AWS DMS

を使用して、Babelfish for Aurora PostgreSQL ソーステーブルをサポートされている任意のターゲットエンドポイントに移行できます AWS DMS。

DMS コンソール、、APIまたは CLI コマンドを使用して AWS DMS ソースエンドポイントを作成する場合、ソースを Amazon Aurora PostgreSQL に設定し、データベース名を に設定しますbabelfish_db。エンドポイント設定セクションで、 DatabaseModeが Babelfish に設定され、 BabelfishDatabaseNameがソース Babelfish T-SQL データベースの名前に設定されていることを確認します。Babelfish TCP ポート を使用する代わりに1433、Aurora PostgreSQL TCP ポート を使用します5432。

DMS で適切なデータ型とテーブルメタデータを使用するには、データを移行する前にテーブルを作成する必要があります。移行を実行する前にターゲットにテーブルを作成しないと、DMS は誤ったデータ型とアクセス権限を使用してテーブルを作成する可能性があります。

移行タスクへの変換ルールの追加

Babelfish ソースの移行タスクを作成するときは、 が事前に作成されたターゲットテーブルDMSを使用するようにするための変換ルールを含める必要があります。

Babelfish for PostgreSQL クラスターを定義したときにマルチデータベース移行モードを設定した場合は、スキーマ名を T-SQL スキーマに変更する変換ルールを追加します。例えば、T-SQL スキーマ名が でdbo、Babelfish for PostgreSQL スキーマ名が の場合mydb_dbo、変換ルールdboを使用してスキーマの名前を に変更します。PostgreSQL スキーマ名を確認するには、「Amazon Aurora ユーザーガイド」の「Babelfish アーキテクチャ」を参照してください。

単一のデータベースモードを使用する場合、データベーススキーマの名前を変更するための変換ルールを使用する必要はありません。PostgreSQL スキーマ名には、 one-to-oneT-SQL データベースのスキーマ名へのマッピングがあります。

次の変換ルールの例は、スキーマ名を mydb_dbo から dbo に戻す方法を示しています。

{
    "rules": [
        {
            "rule-type": "transformation",
            "rule-id": "566251737",
            "rule-name": "566251737",
            "rule-target": "schema",
            "object-locator": {
                "schema-name": "mydb_dbo"
            },
            "rule-action": "rename",
            "value": "dbo",
            "old-value": null
        },
        {
            "rule-type": "selection",
            "rule-id": "566111704",
            "rule-name": "566111704",
            "object-locator": {
                "schema-name": "mydb_dbo",
                "table-name": "%"
            },
            "rule-action": "include",
            "filters": []
        }
    ]
}

Babelfish テーブルで PostgreSQL ソースエンドポイントを使用する場合の制限

Babelfish テーブルで PostgreSQL ソースエンドポイントを使用する場合、次の制限が適用されます。

  • DMS は、Babelfish バージョン 16.2/15.6 以降、およびDMSバージョン 3.5.3 以降の移行のみをサポートします。

  • DMS は、Babelfish テーブル定義の変更をターゲットエンドポイントにレプリケートしません。この制限を回避するには、まずターゲットにテーブル定義の変更を適用し、次に Babelfish ソースでテーブル定義を変更することです。

  • BYTEA データ型を使用して Babelfish テーブルを作成すると、 はターゲットとして SQL Server に移行するときにそれらを varbinary(max) データ型DMSに変換します。

  • DMS では、バイナリデータ型のフルLOBモードはサポートされていません。バイナリデータ型には、代わりに制限付きLOBモードを使用します。

  • DMS は、ソースとしての Babelfish のデータ検証をサポートしていません。

  • [ターゲットテーブル作成モード] タスク設定では、[何もしない] モードまたは [切り捨て] モードのみを使用します。[ターゲット上のテーブルを削除] モードは使用しないでください。ターゲットでテーブルの削除を使用する場合、 は誤ったデータ型を持つテーブルを作成するDMS可能性があります。

  • 継続的なレプリケーション (CDC または全ロードおよび CDC) を使用する場合は、PluginName追加の接続属性 (ECA) を に設定しますTEST_DECODING。

  • DMS は、ソースとしての Babelfish のパーティションテーブルのレプリケーション (CDC または全ロードと CDC) をサポートしていません。

PostgreSQL ソースデータベースからの AWS DMS アーティファクトの削除

DDL イベントをキャプチャするために、 は移行タスクの開始時に PostgreSQL データベースにさまざまなアーティファクト AWS DMS を作成します。タスクが完了したら、これらのアーティファクトを削除できます。

アーティファクトを削除するには、以下のステートメントを発行します (示されている順序で)。ここに、{AmazonRDSMigration} は、アーティファクトが作成されたスキーマです。スキーマを削除する場合でも、細心の注意を払ってください。運用中のスキーマ (特に公開スキーマ) は絶対に削除しないでください。

drop event trigger awsdms_intercept_ddl;

イベントトリガーは特定のスキーマに属していません。

drop function {AmazonRDSMigration}.awsdms_intercept_ddl()
drop table {AmazonRDSMigration}.awsdms_ddl_audit
drop schema {AmazonRDSMigration}

PostgreSQL データベースをDMSソースとして使用する場合の追加設定

PostgreSQL データベースからデータを移行するときは、次の 2 つの方法で設定を追加できます。

  • 追加の接続属性に値を追加して、DDLイベントをキャプチャし、運用DDLデータベースアーティファクトが作成されるスキーマを指定できます。詳細については、「PostgreSQL をDMSソースとして使用する場合のエンドポイント設定と追加の接続属性 (ECAs）」を参照してください。

  • 接続文字列パラメータを上書きできます。これを行うには、次のいずれかのオプションを選択します：

    • 内部 AWS DMS パラメータを指定します。このようなパラメータが必要になることはめったにないため、ユーザー インターフェイスには表示されません。

    • 特定のデータベースクライアントのパススルー (パススルー) 値を指定します。 は、データベースクライアントに渡される接続スティングにパススルーパラメータ AWS DMS を含めます。

  • PostgreSQL バージョン 9.4 以降REPLICA IDENTITYでテーブルレベルのパラメータを使用すると、先行書き込みログ () に書き込まれる情報を制御できますWALs。特に、 WALsが更新または削除された行を識別するようにします。 は、行内のすべての列の古い値REPLICA IDENTITY FULLを記録します。では、必要ではないWALs追加の がFULL生成されるため、テーブルごとに をREPLICA IDENTITY FULL慎重に使用してください。詳細については、ALTERTABLE「-」を参照してください。REPLICA IDENTITY

MapBooleanAsBoolean PostgreSQL エンドポイント設定の使用

PostgreSQL エンドポイント設定を使用して、ブール値を PostgreSQL ソースから Amazon Redshift ターゲットにブール値としてマッピングできます。デフォルトでは、BOOLEANタイプは varchar(5) として移行されます。次の例に示すように、 を指定MapBooleanAsBooleanして、PostgreSQL がブール型をブール型として移行するようにできます。

--postgre-sql-settings '{"MapBooleanAsBoolean": true}'

この設定を有効にするには、ソースエンドポイントとターゲットエンドポイントの両方でこの設定を設定する必要があることに注意します。

MySQL には BOOLEANタイプがないため、BOOLEANデータを My に移行するときは、この設定ではなく変換ルールを使用しますSQL。

PostgreSQL をDMSソースとして使用する場合のエンドポイント設定と追加の接続属性 (ECAs）

エンドポイント設定と追加の接続属性 (ECAs) を使用して、PostgreSQL ソースデータベースを設定できます。エンドポイント設定は、 AWS DMS コンソールを使用するか、 の create-endpoint コマンドを使用してAWS CLI、 --postgre-sql-settings '{"EndpointSetting": "value", ...}'JSON構文でソースエンドポイントを作成するときに指定します。

次の表は、PostgreSQL ECAsをソースとして使用できるエンドポイント設定と を示しています。

属性名 説明

CaptureDdls

DDL イベントをキャプチャするために、 はタスクの開始時に PostgreSQL データベースにさまざまなアーティファクト AWS DMS を作成します。PostgreSQL ソースデータベースからの AWS DMS アーティファクトの削除に記載されているように、これらのアーティファクトは後で削除できます。

この値が false に設定されている場合、ソースデータベースにテーブルやトリガーを作成する必要はない。

ストリーミングDDLイベントがキャプチャされます。

デフォルト値: true

有効な値: true/false

例: --postgre-sql-settings '{"CaptureDdls": true}'

ConsumeMonotonicEvents

重複するログシーケンス番号 (LSNs) を持つモノリシックトランザクションのレプリケート方法を制御するために使用されます。このパラメータが の場合false、重複するイベントLSNsはターゲットで消費され、レプリケートされます。このパラメータが の場合true、最初のイベントのみがレプリケートされますが、重複するイベントLSNsはターゲットで消費もレプリケートもされません。

デフォルト値: false

有効な値: false/true

例: --postgre-sql-settings '{"ConsumeMonotonicEvents": true}'

DdlArtifactsSchema

運用DDLデータベースアーティファクトが作成されるスキーマを設定します。

デフォルト値: public

有効な値: 文字列

例: --postgre-sql-settings '{"DdlArtifactsSchema": "xyzddlschema"}'

DisableUnicodeSourceFilter

ソースエンドポイントの列値の選択ルールフィルターに渡された値についてSQL、Postgre で Unicode ソースフィルターを無効にします。デフォルトでは、Unicode 文字列を使用してソースフィルタ比較DMSが実行されるため、ルックアップでテキスト列のインデックスが無視され、移行が遅くなる可能性があります。

Unicode サポートは、インデックスが作成されたソースデータベースのテキスト列に選択ルールフィルターを使用している場合にのみ無効にする必要があります。

デフォルト値: false

有効な値: true/false

例: --postgre-sql-settings '{"DisableUnicodeSourceFilter": "true"}'

ExecuteTimeout

PostgreSQL インスタンスのクライアントステートメントのタイムアウトを秒単位で設定します。デフォルト値は 60 秒です。

例: --postgre-sql-settings '{"ExecuteTimeout": 100}'

FailTasksOnLobTruncation

に設定するとtrue、LOB列の実際のサイズが指定された より大きい場合、この値によりタスクは失敗しますLobMaxSize。

タスクが制限LOBモードに設定され、このオプションが true に設定されている場合、タスクはLOBデータを切り捨てる代わりに失敗します。

デフォルト値: false

有効な値: ブール値

例: --postgre-sql-settings '{"FailTasksOnLobTruncation": true}'

fetchCacheSize

この追加の接続属性 (ECA) は、全ロードオペレーション中にカーソルが取得する行数を設定します。レプリケーションインスタンスで利用可能なリソースに応じて、この値を増減して調整できる。

デフォルト値: 10000

有効な値: 数値

ECA例: fetchCacheSize=10000;

HeartbeatEnable

WAL ハートビート機能はダミートランザクションを模倣するため、アイドル状態の論理レプリケーションスロットが古いWALログを保持せず、ソース上のストレージがいっぱいになります。このハートビートは restart_lsn を移動し続けるため、ストレージがいっぱいになるシナリオを回避できます。

デフォルト値: false

有効な値: true/false

例: --postgre-sql-settings '{"HeartbeatEnable": true}'

HeartbeatFrequency

WAL ハートビートの頻度 (分単位) を設定します。

デフォルト値: 5

有効な値: 数値

例: --postgre-sql-settings '{"HeartbeatFrequency": 1}'

HeartbeatSchema

ハートビート アーティファクトが作成されるスキーマを設定します。

デフォルト値: public

有効な値: 文字列

例: --postgre-sql-settings '{"HeartbeatSchema": "xyzheartbeatschema"}'

MapJsonbAsClob

デフォルトでは、 は JSONBに AWS DMS マッピングされますNCLOB。PostgreSQL MapJsonbAsClobにJSONBタイプを として移行させるには、 を指定できますCLOB。

例: --postgre-sql-settings='{"MapJsonbAsClob": "true"}'

MapLongVarcharAs

デフォルトでは、 は VARCHARに AWS DMS マッピングされますWSTRING。を指定MapLongVarcharAsして、PostgreSQL が VARCHAR(N) タイプ (N が 16387 より大きい) を次のタイプに移行できるようにします。

  • WSTRING

  • CLOB

  • NCLOB

例: --postgre-sql-settings='{"MapLongVarcharAs": "CLOB"}'

MapUnboundedNumericAsString

このパラメータは、数値の精度を失うことなく正常に移行STRINGするために、無制限NUMERICのデータ型の列を として扱います。このパラメータは、PostgreSQL ソースから PostgreSQL ターゲットへのレプリケーション、または PostgreSQL との互換性があるデータベースにのみ使用します。

デフォルト値: false

有効な値: false/true

例: --postgre-sql-settings '{"MapUnboundedNumericAsString": true}'

このパラメータを使用すると、数値から文字列への変換、および数値への変換により、レプリケーションのパフォーマンスが低下する可能性があります。このパラメータは、DMSバージョン 3.4.4 以降で使用できます。

注記

MapUnboundedNumericAsString PostgreSQL ソースエンドポイントとターゲットエンドポイントでのみ を使用します。

ソース PostgreSQL エンドポイントMapUnboundedNumericAsStringで を使用すると、 中の精度が 28 に制限されますCDC。ターゲット エンドポイントで MapUnboundedNumericAsString を使用すると、精度 28 スケール 6 でデータを移行します。

PostgreSQL 以外のターゲットMapUnboundedNumericAsStringで を使用しないでください。

PluginName

レプリケーション スロットの作成に使用するプラグインを指定します。

有効な値: pglogical、test_decoding

例: --postgre-sql-settings '{"PluginName": "test_decoding"}'

SlotName

PostgreSQL ソースインスタンスのCDCロード用に以前に作成した論理レプリケーションスロットの名前を設定します。

CdcStartPosition リクエストパラメータとともに使用すると AWS DMS API、この属性はネイティブCDCの開始ポイントの使用も有効にします。 DMS は、CDCロードタスクを開始する前に、指定された論理レプリケーションスロットが存在することを確認します。また、タスクが有効な CdcStartPosition 設定を使用して作成されたことも確認します。指定されたスロットが存在しないか、タスクに有効なCdcStartPosition設定がない場合、 はエラーDMSを発生させます。

CdcStartPosition リクエストパラメータの設定の詳細については、「CDC ネイティブのスタートポイントの決定」をご参照ください。の使用の詳細についてはCdcStartPosition、「 AWS Database Migration Service APIリファレンス」のCreateReplicationTask「、StartReplicationTask、および ModifyReplicationTaskAPIオペレーションのドキュメント」を参照してください。

有効な値: 文字列

例: --postgre-sql-settings '{"SlotName": "abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef"}'

unboundedVarcharMaxSize

この追加接続属性 (ECA) は、最大長指定子 VarChar のないタイプとして定義されたデータ列の最大サイズを定義します。デフォルト値は 8,000 バイトです。最大値は 10,485,760 バイトです。

PostgreSQL データベースをDMSソースとして使用する場合の制限

PostgreSQL を のソースとして使用する場合、次の制限が適用されます AWS DMS。

  • AWS DMS は、Amazon RDS for PostgreSQL 10.4 または Amazon Aurora PostgreSQL 10.4 をソースまたはターゲットとして使用することはできません。

  • キャプチャされたテーブルにはプライマリキーが必要です。テーブルにプライマリキーがない場合、 はそのテーブルのオペレーション AWS DMS を無視DELETEしてUPDATE記録します。回避策として、「論理レプリケーションを使用した変更データキャプチャ (CDC) の有効化」を参照してください。

    注： プライマリキー/一意インデックスなしで移行することはお勧めしません。そうしないと、「NO」バッチ適用機能、フルLOB機能、データ検証、Redshift ターゲットに効率的にレプリケートできないなどの追加の制限が適用されます。

  • AWS DMS は、プライマリキーセグメントを更新しようとする試みを無視します。この場合、ターゲットは、その更新によってどの行も更新されないと識別します。ただし、PostgreSQL でプライマリキーを更新した結果は予測できないため、例外テーブルにはレコードが書き込まれません。

  • AWS DMS は、タイムスタンプからプロセスの変更を開始する実行オプションをサポートしていません。

  • AWS DMS は、パーティションまたはサブパーティションオペレーション (ADD、DROP、または ) によって生じる変更をレプリケートしませんTRUNCATE。

  • 同じ名前の複数のテーブルをレプリケートすると、各名前の大文字と小文字 (table1、、Table1 など) が異なるとTABLE1、予期しない動作が発生する可能性があります。この問題のため、 AWS DMS はこのタイプのレプリケーションをサポートしていません。

  • ほとんどの場合、 は tables の CREATE、ALTER、および DROPDDLステートメントの変更処理 AWS DMS をサポートします。テーブルが内部関数またはプロシージャ本文ブロックまたは他のネストされたコンストラクトに保持されている場合、 はこの変更処理をサポート AWS DMS しません。

    たとえば、以下の変更はキャプチャされません。

    CREATE OR REPLACE FUNCTION attu.create_distributors1() RETURNS void
LANGUAGE plpgsql
AS $$
BEGIN
create table attu.distributors1(did serial PRIMARY KEY,name
varchar(40) NOT NULL);
END;
$$;

  • 現在、PostgreSQL ソースbooleanのデータ型は、一貫性のない値を持つbitデータ型としてSQLサーバーターゲットに移行されます。回避策として、列VARCHAR(1)のデータ型を使用してテーブルを事前に作成します (または、 に AWS DMSテーブルを作成させます）。次に、ダウンストリーム処理で「F」を False、「T」を True として扱います。

  • AWS DMS はTRUNCATEオペレーションの変更処理をサポートしていません。

  • OID LOB データ型はターゲットに移行されません。

  • AWS DMS は、同種移行にのみ PostGIS データ型をサポートします。

  • ソースがオンプレミスまたは Amazon EC2インスタンス上の PostgreSQL データベースの場合は、test_decoding 出力プラグインがソースエンドポイントにインストールされていることを確認します。このプラグインは、PostgreSQL contrib パッケージにあります。テストデコードプラグインの詳細については、PostgreSQL ドキュメントを参照してください。

  • AWS DMS では、列のデフォルト値を設定および設定解除する変更処理はサポートされていません ( ALTERTABLEステートメントで ALTERCOLUMNSETDEFAULT句を使用）。

  • AWS DMS では、列の null 性を設定するための変更処理はサポートされていません ( ALTERTABLEステートメントで ALTER COLUMN [SET|DROP] NOTNULL句を使用）。

  • 論理レプリケーションが有効な場合、トランザクションあたりのメモリに保持される変更の最大数は 4 MB です。その後、変更がディスクにこぼれます。その結果、ReplicationSlotDiskUsageが増加し、トランザクションが完了または停止し、ロールバックが完了するまで restart_lsn は進みません。長いトランザクションであるため、ロールバックに時間がかかることがあります。従って、論理レプリケーションが有効になっている場合は、トランザクションまたは多くのサブトランザクションの長期実行を避けてください。代わりに、トランザクションをいくつかの小さなトランザクションに分割します。

    Aurora PostgreSQL バージョン 13 以降では、 logical_decoding_work_memパラメータを調整して、 が変更データをディスクにDMSいつスピルするかを制御できます。詳細については、「Aurora PostgreSQL のスピルファイル」を参照してください。

  • ARRAY データ型のテーブルにはプライマリキーが必要です。データARRAY型にプライマリキーがないテーブルは、全ロード中に中断されます。

  • AWS DMS は、パーティション分割されたテーブルのレプリケーションをサポートしていません。パーティション分割されたテーブルが検出された場合、以下の状況が発生します。

    • エンドポイントは、親テーブルと子テーブルのリストを報告します。

    • AWS DMS は、選択したテーブルと同じプロパティを持つ通常のテーブルとしてターゲットにテーブルを作成します。

    • ソースデータベースの親テーブルに子テーブルと同じプライマリキー値がある場合、「重複するキー」エラーが生成されます。

  • パーティション分割されたテーブルを PostgreSQL ソースから PostgreSQL ターゲットにレプリケートするには、まずターゲットに親テーブルと子テーブルを手動で作成します。次に、それらのテーブルにレプリケーションする別個のタスクを定義します。その場合、タスク設定を [Truncate before loading] (読み取り前切り捨て) に設定します。

  • PostgreSQL NUMERIC データ型のサイズは固定されていません。NUMERIC データ型で、精度とスケールがないデータを転送する場合、 はデフォルトで NUMERIC(28,6) (精度 28、スケール 6) DMSを使用します。例えば、ソースからの値 0.611111104488373 は、PostgreSQL ターゲットで 0.61111 に変換されます。

  • AWS DMS は、全ロードタスクのソースとしてのみ Aurora PostgreSQL Serverless V1 をサポートします。 は、全ロード、全ロード、および CDCのソースとして Aurora PostgreSQL Serverless V2 CDC AWS DMS をサポートします。

  • AWS DMS は、coalesce 関数で作成された一意のインデックスを持つテーブルのレプリケーションをサポートしていません。

  • LOB モードを使用する場合、ソーステーブルと対応するターゲットテーブルの両方に同じプライマリキーが必要です。いずれかのテーブルにプライマリキーがない場合、 DELETEおよび UPDATEレコードオペレーションの結果は予測できません。

  • 並列ロード機能を使用する場合、パーティションまたはサブパーティションに基づくテーブルのセグメント化はサポートされません。並列ロードの詳細については、「選択したテーブルおよびビューさらにコレクションで並列ロードを使用する」を参照してください。

  • AWS DMS は遅延制約をサポートしていません。

  • AWS DMS バージョン 3.4.7 では、PostgreSQL 14.x がソースとしてサポートされていますが、次の制限があります。

    • AWS DMS は、2 つのフェーズコミットの変更処理をサポートしていません。

    • AWS DMS は、進行中の長いトランザクションをストリーミングするための論理レプリケーションをサポートしていません。

  • AWS DMS はCDC、ソースとしての Amazon RDS Proxy for PostgreSQL をサポートしていません。

  • プライマリキー列を含まない ソースフィルター を使用する場合、DELETE 操作はキャプチャされません。

  • ソースデータベースが別のサードパーティーのレプリケーションシステムのターゲットでもある場合、 中にDDL変更が移行されない可能性がありますCDC。これは、このような状況では awsdms_intercept_ddl イベントトリガーが起動しなくなる可能性があるためです。この状況を回避するには、ソースデータベースでこのトリガーを次のとおり変更します。

    alter event trigger awsdms_intercept_ddl enable always;

  • AWS DMS は PostgreSQL CDCの Amazon RDS マルチ AZ データベースクラスターをソースとしてサポートしていません。これは、 RDSの PostgreSQL マルチ AZ データベースクラスターが論理レプリケーションをサポートしていないためです。

Postgre のソースデータ型SQL

次の表は、 の使用時にサポートされる PostgreSQL ソースデータ型 AWS DMS と、 AWS DMS データ型へのデフォルトのマッピングを示しています。

ターゲットにマッピングされるデータ型を表示する方法については、使用しているターゲットエンドポイントのセクションをご参照ください。

AWS DMS データ型の詳細については、「」を参照してくださいAWS Database Migration Service のデータ型。

PostgreSQL データ型

DMS データ型

INTEGER

INT4

SMALLINT

INT2

BIGINT

INT8

NUMERIC (p,s)

精度が 0～38 の場合は、 を使用しますNUMERIC。

精度が 39 以上の場合は、 を使用しますSTRING。

DECIMAL(P、S)

精度が 0～38 の場合は、 を使用しますNUMERIC。

精度が 39 以上の場合は、 を使用しますSTRING。

REAL

REAL4

DOUBLE

REAL8

SMALLSERIAL

INT2

SERIAL

INT4

BIGSERIAL

INT8

MONEY

NUMERIC(38,4)

MONEY データ型は SQL Server FLOATの にマッピングされます。

CHAR

WSTRING (1)

CHAR(N)

WSTRING (n)

VARCHAR(N)

WSTRING (n)

TEXT

NCLOB

CITEXT

NCLOB

BYTEA

BLOB

TIMESTAMP

DATETIME

TIMESTAMP WITH TIME ZONE

DATETIME

DATE

DATE

TIME

TIME

TIME WITH TIME ZONE

TIME

INTERVAL

STRING (128) - 1 YEAR、2 MONTHS、3 DAYS、4 HOURS、5 MINUTES、6 SECONDS

BOOLEAN

CHAR (5) false または true

ENUM

STRING (64)

CIDR

STRING (50)

INET

STRING (50)

MACADDR

STRING (18)

BIT (n)

STRING (n)

BIT VARYING (n)

STRING (n)

UUID

STRING

TSVECTOR

CLOB

TSQUERY

CLOB

XML

CLOB

POINT

STRING (255) 「(x,y)」

LINE

STRING (255) 「(x,y,z)」

LSEG

STRING (255) 「(x1,y1),(x2,y2))」

BOX

STRING (255) 「(x1,y1),(x2,y2))」

PATH

CLOB 「(x1,y1),(xn,yn))」

POLYGON

CLOB 「(x1,y1),(xn,yn))」

CIRCLE

STRING (255) 「(x,y),r」

JSON

NCLOB

JSONB

NCLOB

ARRAY

NCLOB

COMPOSITE

NCLOB

HSTORE

NCLOB

INT4RANGE

STRING (255)

INT8RANGE

STRING (255)

NUMRANGE

STRING (255)

STRRANGE

STRING (255)

Postgre のLOBソースデータ型の使用SQL

PostgreSQL 列のサイズは、PostgreSQL LOB データ型から AWS DMS データ型への変換に影響します。これを使用するには、次の AWS DMS データ型で以下の手順を実行します。

  • BLOB – タスク作成時に制限LOBサイズを最大LOBサイズ (KB) 値に設定します。

  • CLOB – レプリケーションは各文字をUTF8文字として処理します。次に、列で最長の文字テキストの長さ (ここでは、max_num_chars_text) を見つけます。この長さを使用して、制限LOBサイズの値を指定します。データに 4 バイト文字が含まれている場合は、2 を掛けて、制限LOBサイズをバイト単位で指定します。この場合、 の制限LOBサイズは に 2 max_num_chars_textを乗算した値に等しくなります。

  • NCLOB – レプリケーションは各文字を 2 バイト文字として処理します。次に、列で最長の文字テキストの長さ (max_num_chars_text) を見つけ、2 倍します。これは、制限LOBサイズの値を指定する場合に使用します。この場合、 の制限LOBサイズは 2 をmax_num_chars_text乗算した値に等しくなります。データに 4 バイト文字が含まれている場合は、再度 2 倍にします。この場合、 の制限LOBサイズは に 4 max_num_chars_textを掛けた値に等しくなります。