翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # PostgreSQL データベースを AWS DMS ソースとして使用する を使用して、1 つ以上の PostgreSQL データベースからデータを移行できます AWS DMS。PostgreSQL データベースをソースとして使用する場合、別の PostgreSQL データベースまたはサポートされているその他の データベースのいずれかにデータを移行できます。 がソースとして AWS DMS サポートする PostgreSQL のバージョンについては、「」を参照してください[のソース AWS DMS](CHAP_Introduction.Sources.md)。 AWS DMS は、次のタイプのデータベースに対して PostgreSQL をサポートしています。 +  オンプレミスのデータベース + Amazon EC2 インスタンスでのデータベース + Amazon RDS DB インスタンス上のデータベース + Amazon Aurora PostgreSQL 互換エディションに基づく DB インスタンス上のデータベース + Amazon Aurora PostgreSQL 互換 Serverless エディションを基盤とする DB インスタンス上のデータベース **注記** DMS は Amazon Aurora PostgreSQL—Serverless V1 についてはフルロードのソースとしてのみサポートしています。ただし、Amazon Aurora PostgreSQL—Serverless V2 は、フルロード、フルロード \$1 CDC、CDC のみのタスクのソースとして使用することができます。 Secure Sockets Layer (SSL) を使用して、PostgreSQL エンドポイントとレプリケーション インスタンスとの接続を暗号化できます。PostgreSQL エンドポイントで SSL を使用する方法の詳細については、「[での SSL の使用 AWS Database Migration Service](CHAP_Security.SSL.md)」をご参照ください。 ソースとして PostgreSQL を使用する場合の追加セキュリティ要件として、指定されるユーザーアカウントは PostgreSQL データベースの登録済みユーザーでなければなりません。 PostgreSQL データベースを AWS DMS ソースエンドポイントとして設定するには、次の手順を実行します。 + PostgreSQL ソースデータベース AWS DMS へのアクセスを提供する適切なアクセス許可を持つ PostgreSQL ユーザーを作成します。 **注記** PostgreSQL ソースデータベースが自己管理型の場合は詳細については、「[でのソースとしてのセルフマネージド PostgreSQL データベースの使用 AWS DMS](#CHAP_Source.PostgreSQL.Prerequisites)」をご参照ください。 PostgreSQL ソースデータベースが Amazon RDS によって管理されている場合詳細については、「[DMS ソースとしての AWSマネージド PostgreSQL データベースの使用](#CHAP_Source.PostgreSQL.RDSPostgreSQL)」をご参照ください。 + 選択した PostgreSQL データベース設定に準拠する PostgreSQL ソース エンドポイントを作成します。 + テーブルを移行するタスクまたはタスクのセットを作成します。 全ロードのみのタスクを作成する場合、これ以上エンドポイントの設定は必要ありません。 変更データキャプチャのタスク(CDC のみ、または全ロードおよび CDC タスク)を作成する前に、「[セルフマネージド PostgreSQL データベースを AWS DMS ソースとして使用して CDC を有効にする](#CHAP_Source.PostgreSQL.Prerequisites.CDC)」または「[で AWS管理された PostgreSQL DB インスタンスで CDC を有効にする AWS DMS](#CHAP_Source.PostgreSQL.RDSPostgreSQL.CDC)」をご参照ください。 **Topics** + [でのソースとしてのセルフマネージド PostgreSQL データベースの使用 AWS DMS](#CHAP_Source.PostgreSQL.Prerequisites) + [DMS ソースとしての AWSマネージド PostgreSQL データベースの使用](#CHAP_Source.PostgreSQL.RDSPostgreSQL) + [論理レプリケーションを使用した変更データ キャプチャ (CDC) の有効化](#CHAP_Source.PostgreSQL.Security) + [ネイティブ CDC スタートポイントを使用して PostgreSQL ソース エンドポイントの CDC ロードを設定するには](#CHAP_Source.PostgreSQL.v10) + [を使用した PostgreSQL から PostgreSQL への移行 AWS DMS](#CHAP_Source.PostgreSQL.Homogeneous) + [を使用した Babelfish for Amazon Aurora PostgreSQL からの移行 AWS DMS](#CHAP_Source.PostgreSQL.Babelfish) + [PostgreSQL ソースデータベースからの AWS DMS アーティファクトの削除](#CHAP_Source.PostgreSQL.CleanUp) + [DMS ソースとして PostgreSQL データベースを使用する場合の追加設定](#CHAP_Source.PostgreSQL.Advanced) + [PostgreSQL のソースとしてのリードレプリカ](#CHAP_Source.PostgreSQL.ReadReplica) + [`MapBooleanAsBoolean` PostgreSQL エンドポイント設定の使用](#CHAP_Source.PostgreSQL.ConnectionAttrib.Endpointsetting) + [DMS ソースとして PostgreSQL を使用する場合のエンドポイント設定と追加の接続属性 (ECA)](#CHAP_Source.PostgreSQL.ConnectionAttrib) + [DMS のソースとして PostgreSQL データベースを使用する場合の制限](#CHAP_Source.PostgreSQL.Limitations) + [PostgreSQL のソースデータ型](#CHAP_Source-PostgreSQL-DataTypes) ## でのソースとしてのセルフマネージド PostgreSQL データベースの使用 AWS DMS セルフマネージド PostgreSQL データベースをソースとして使用すると、別の PostgreSQL データベース、または でサポートされている他のターゲットデータベースのいずれかにデータを移行できます AWS DMS。データベースソースには、オンプレミスのデータベースまたは Amazon EC2 インスタンスで実行されているセルフ管理エンジンを使用できます。DB インスタンスは、全ロードタスクと継続的レプリケーションの変更データキャプチャ (CDC) タスクの両方に使用できます。 ### セルフマネージド PostgreSQL データベースを AWS DMS ソースとして使用するための前提条件 自己管理 PostgreSQL ソースデータベースからデータを移行する前に、次の操作を行います： + バージョン 9.4.x 以降の PostgreSQL データベースを使用していることを確認する。 + 全ロードと CDC タスクまたは CDC のみのタスクの場合は、PostgreSQL ソースデータベースに指定されたユーザーアカウントにスーパーユーザー許可を付与します。ユーザー アカウントはソース内のレプリケーション固有機能にアクセスするには、スーパーユーザー許可が必要です。テーブルを正常に移行するため、DMS ユーザーアカウントには、すべての列に対する SELECT のアクセス許可が必要です。列に対するアクセス許可がない場合、DMS は通常の DMS データ型マッピングを使用してターゲットテーブルを作成するため、メタデータの相違やタスクの失敗につながります。 + 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 ``` PostgreSQL の `pg_hba.conf` の設定ファイルはクライアント認証を制御します。(HBA はホストベースの認証を表します) ファイルは従来、データベースクラスターのデータディレクトリに保存されています。 + を使用して論理レプリケーションのソースとしてデータベースを設定する場合は、 AWS DMS 「」を参照してください。 [セルフマネージド PostgreSQL データベースを AWS DMS ソースとして使用して CDC を有効にする](#CHAP_Source.PostgreSQL.Prerequisites.CDC) **注記** 一部の AWS DMS トランザクションは、DMS エンジンが再度使用する前にしばらくアイドル状態になります。PostgreSQL バージョン 9.6 以降で `idle_in_transaction_session_timeout` パラメータを使用すると、アイドル状態のトランザクションでタイムアウトやエラーが生じる場合があります。 AWS DMSを使用する際、アイドル状態のトランザクションを終了しないでください。 ### セルフマネージド PostgreSQL データベースを AWS DMS ソースとして使用して CDC を有効にする 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 データベースのデフォルトは 60,000 ミリ秒 (60 秒)。値を 0 (ゼロ) に設定するとタイムアウトメカニズムが無効になる。この設定は DMS では有効。 `wal_sender_timeout` をゼロ以外の値に設定すると、CDC での DMS タスクには最低 10,000 ミリ秒 (10 秒) が必要となり、値が 10,000 ミリ秒未満になると失敗する。DMS レプリケーションインスタンスのマルチ AZ フェイルオーバー中に遅延が発生しないように、この値は 5 分未満にする。 一部のパラメータは静的であり、サーバースタート時にのみ設定できます。設定ファイル (セルフマネージドデータベースの場合) または DB パラメータグループ (RDS for PostgreSQL データベース) への変更は、サーバーが再起動されるまで無視されます。詳細については、[PostgreSQL ドキュメント](https://www.postgresql.org/docs/current/intro-whatis.html)をご参照ください。 CDC を有効にすることに関する詳細については、「[論理レプリケーションを使用した変更データ キャプチャ (CDC) の有効化](#CHAP_Source.PostgreSQL.Security)」をご参照ください。 ## DMS ソースとしての AWSマネージド PostgreSQL データベースの使用 AWSマネージド PostgreSQL DB インスタンスをソースとして使用できます AWS DMS。 AWSが管理する PostgreSQL ソースを使用して、全ロードタスクと変更データキャプチャ (CDC) タスクの両方を実行できます。 ### AWSマネージド PostgreSQL データベースを DMS ソースとして使用するための前提条件 AWSマネージド PostgreSQL ソースデータベースからデータを移行する前に、次の操作を行います。 + PostgreSQL DB インスタンスに必要な最小限のアクセス許可を持つ AWS ユーザーアカウントをPostgreSQL ソースエンドポイントのユーザーアカウントとして使用することをお勧めします AWS DMS。管理アカウントの使用はお勧めしません。このアカウントには `rds_superuser` ロールと `rds_replication` ロールが必要です。`rds_replication` ロールは、論理スロットを管理し、論理スロットを使用してデータをストリーミングするアクセス権許可付与します。 使用するアカウントの管理ユーザーアカウントで複数のオブジェクトを作成します。その作成についての詳細は、「[マスター ユーザーアカウントを使用せず Amazon RDS for PostgreSQL データベースの移行](#CHAP_Source.PostgreSQL.RDSPostgreSQL.NonMasterUser)」をご参照ください。 + ソースデータベースが仮想プライベートクラウド (VPC) にある場合は、データベースが常駐する DB インスタンスへのアクセス権を提供する VPC セキュリティグループを選択します。これは、DMS レプリケーション インスタンスがソース DB インスタンスに正常に接続するために必要です。データベースと DMS レプリケーション インスタンスが同じ VPC 内にある場合は、適切なセキュリティグループを独自のインバウンド ルールに追加します。 **注記** 一部の AWS DMS トランザクションは、DMS エンジンが再度使用する前にしばらくアイドル状態になります。PostgreSQL バージョン 9.6 以降で `idle_in_transaction_session_timeout` パラメータを使用すると、アイドル状態のトランザクションでタイムアウトやエラーが生じる場合があります。 AWS DMSを使用する際、アイドル状態のトランザクションを終了しないでください。 ### で AWS管理された PostgreSQL DB インスタンスで CDC を有効にする AWS DMS AWS DMS DB インスタンスが論理レプリケーションを使用するように設定されている場合、 は Amazon RDS PostgreSQL データベースで CDC をサポートします。次の表は、各マネージド PostgreSQL バージョンの論理レプリケーションの互換性をまとめ AWSたものです。 | PostgreSQL バージョン | AWS DMS フルロードのサポート | AWS DMS CDC サポート | | --- | --- | --- | | Aurora PostgreSQL バージョン 2.1 (PostgreSQL 10.5 以前と互換) | はい | なし | | PostgreSQL 10.6 と互換性のある Aurora PostgreSQL バージョン 2.2 (またはそれ以降) | はい | はい | | PostgreSQL 10.21 と互換性のある RDS for PostgreSQL (またはそれ以降) | はい | はい | **RDS PostgreSQL DB インスタンスに対して論理レプリケーションを有効にするには** 1. PostgreSQL DB インスタンスの AWS マスターユーザーアカウントを PostgreSQL ソースエンドポイントのユーザーアカウントとして使用します。マスターユーザーアカウントには、CDC を設定するために必要なロールがあります。 マスター ユーザーアカウント以外のアカウントを使用する場合は、使用するアカウントのマスター ユーザーアカウントから複数のオブジェクトを作成する必要があります。詳細については、「[マスター ユーザーアカウントを使用せず Amazon RDS for PostgreSQL データベースの移行](#CHAP_Source.PostgreSQL.RDSPostgreSQL.NonMasterUser)」を参照してください。 1. DB CLUSTER パラメータグループの `rds.logical_replication` パラメータを 1 に設定します。この静的パラメータを有効にするには、DB インスタンスを再起動する必要があります。このパラメータを適用する一環として、 AWS DMS は `wal_level`、`max_wal_senders`、`max_replication_slots`、`max_connections` の各パラメータを設定します。これらのパラメータの変更によって先書きログ (WAL) の生成が増える可能性があるため、論理レプリケーションスロットを使用する場合にのみ `rds.logical_replication` を設定してください。 1. `wal_sender_timeout` パラメータは、指定されたミリ秒数が過ぎても非アクティブなレプリケーション接続を終了します。 AWSマネージド PostgreSQL データベースのデフォルトは 30,000 ミリ秒 (30 秒) です。値を 0 (ゼロ) に設定するとタイムアウトメカニズムが無効になる。この設定は DMS では有効です。 `wal_sender_timeout` をゼロ以外の値に設定すると、CDC での DMS タスクには最低 10,000 ミリ秒 (10 秒) が必要となり、値が 0～10,000 ミリ秒の場合は失敗します。DMS レプリケーションインスタンスのマルチ AZ フェイルオーバー中に遅延が発生しないように、この値は 5 分未満にします。 1. DB クラスター パラメータグループで `max_worker_processes` パラメータの値が、`max_logical_replication_workers`、`autovacuum_max_workers`、`max_parallel_workers`の合計値以上となるようにしてください。多数のバックグラウンド ワーカー プロセスが、スモールインスタンスではアプリケーション ワークロードに影響を与える可能性があります。したがって、`max_worker_processes` をデフォルト値より大きく設定した場合は、データベースのパフォーマンスをモニタリングしてください。 1. Aurora PostgreSQL を CDC のソースとして使用する場合は、`synchronous_commit` を `ON` に設定します。 **CDC に PostgreSQL MultiAZ DB クラスターリードレプリカを使用するには (継続的なレプリケーション)** 1. DB CLUSTER パラメータグループの `rds.logical_replication` と `sync_replication_slots` のパラメータを 1 に設定します。この静的パラメータを有効にするには、DB インスタンスを再起動する必要があります。 1. 次のコマンドを実行して、ライターに `awsdms_ddl_audit` テーブルを作成し、`objects_schema` を使用するスキーマの名前に置き換えます。 ``` 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 ); ``` 1. 次のコマンドを実行して、`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; $$; ``` 1. 次のコマンドを実行してイベントトリガー `awsdms_intercept_ddl` を作成します。 ``` CREATE EVENT TRIGGER awsdms_intercept_ddl ON ddl_command_end EXECUTE PROCEDURE objects_schema.awsdms_intercept_ddl(); ``` これらのイベントにアクセスするすべてのユーザーおよびロールに必要な DDL 許可があることを確認します。例えば、次のようになります。 ``` grant all on public.awsdms_ddl_audit to public; grant all on public.awsdms_ddl_audit_c_key_seq to public; ``` 1. ライターでレプリケーションスロットを作成します。 ``` SELECT * FROM pg_create_logical_replication_slot('dms_read_replica_slot', 'test_decoding', false, true); ``` 1. レプリケーションスロットがリーダーで使用可能であることを確認します。 ``` select * from pg_catalog.pg_replication_slots where slot_name = 'dms_read_replica_slot'; slot_name |plugin |slot_type|datoid|database|temporary|active|active_pid|xmin|catalog_xmin|restart_lsn|confirmed_flush_lsn|wal_status|safe_wal_size|two_phase|inactive_since |conflicting|invalidation_reason|failover|synced| ---------------------+-------------+---------+------+--------+---------+------+----------+----+------------+-----------+-------------------+----------+-------------+---------+-----------------------------+-----------+-------------------+--------+------+ dms_read_replica_slot|test_decoding|logical | 5|postgres|false |false | | |3559 |0/180011B8 |0/180011F0 |reserved | |true |2025-02-10 15:45:04.083 +0100|false | |false |false | ``` 1. リードレプリカの DMS ソースエンドポイントを作成し、追加の接続属性を使用して論理レプリケーションスロット名を設定します。 ``` slotName=dms_read_replica_slot; ``` 1. CDC/FL\$1CDC タスクを作成して開始します。 **注記** CDC/FL\$1CDC 移行の場合、DMS はタスク開始時刻を CDC 開始位置と見なします。レプリケーションスロットからの古い LSN はすべて無視されます。 ### マスター ユーザーアカウントを使用せず Amazon RDS for PostgreSQL データベースの移行 場合によっては、ソースとして使用している Amazon RDS PostgreSQL DB インスタンス用マスター ユーザーアカウントを使用しない場合があります。このような場合は、データ定義言語 (DDL) イベントをキャプチャするために複数のオブジェクトを作成します。マスターアカウント以外のアカウントでこれらのオブジェクトを作成し、マスターユーザーアカウントでトリガーを作成します。 **注記** ソースエンドポイントで `CaptureDdls` エンドポイント設定を `false` に設定すると、ソースデータベース上で次のテーブルおよびトリガーを作成する必要はありません。 これらのオブジェクトを作成するには、以下の手順を実行します。 **オブジェクトを作成するには** 1. オブジェクトが作成されるスキーマを選択します。デフォルトのスキーマは `public` です。スキーマが存在し、`OtherThanMaster` アカウントからアクセス可能であることを確認します。 1. マスターアカウント以外のユーザーアカウントを使用して PostgreSQL DB インスタンス、ここでは `OtherThanMaster` アカウントにログインします。 1. 以下のコマンドを実行し、以下のコード内の `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 ); ``` 1. 以下のコマンドを実行して `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; $$; ``` 1. `OtherThanMaster` アカウントからログアウトし、`rds_superuser` ロールが割り当てられたアカウントを使用してログインします。 1. 以下のコマンドを実行してイベントトリガー `awsdms_intercept_ddl` を作成します。 ``` CREATE EVENT TRIGGER awsdms_intercept_ddl ON ddl_command_end EXECUTE PROCEDURE objects_schema.awsdms_intercept_ddl(); ``` 1. これらのイベントにアクセスするすべてのユーザーおよびロールに必要な 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) の有効化 PostgreSQL のネイティブ論理レプリケーション機能を使用して、PostgreSQL DB ソース用データベース移行中に変更データ キャプチャ (CDC) を有効にすることができます。この機能は、セルフ管理 PostgreSQL および Amazon RDS for PostgreSQL SQL DB インスタンスで使用できます。この方法では、ダウンタイムが短縮され、ターゲットデータベースがソース PostgreSQL データベースと同期しやすくなります。 AWS DMS は、プライマリキーを持つ PostgreSQL テーブルの CDC をサポートします。テーブルにプライマリキーがない場合、先書きログ (WAL) にはデータベース行の前イメージが含まれません。この場合、DMS はテーブルを更新できません。ここでは、追加の構成設定を使用し、回避策としてテーブルレプリカ アイデンティティを使用できます。ただし、この方法では追加のログが生成される可能性があります。注意深いテストの後にのみ、回避策としてテーブルレプリカ アイデンティティ を使用することをお勧めします。詳細については、「[DMS ソースとして PostgreSQL データベースを使用する場合の追加設定](#CHAP_Source.PostgreSQL.Advanced)」を参照してください。 **注記** REPLICA IDENTITY FULL は論理デコードプラグインではサポートされていますが、pglogical プラグインではサポートされていません。詳細については、「[pglogical ドキュメント](https://github.com/2ndQuadrant/pglogical#primary-key-or-replica-identity-required)」を参照してください。 全ロードタスク、CDC および CDC のみのタスクの場合、 は論理レプリケーションスロット AWS DMS を使用して、ログがデコードされるまでレプリケーション用の WAL ログを保持します。全ロードおよび CDC タスクまたは CDC タスクの再起動(再開ではない)によって、レプリケーション スロットが再作成されます。 **注記** 論理デコードの場合、DMS は test\$1decoding または pglogical プラグインのいずれかを使用します。pglogical プラグインがソース PostgreSQL データベースで使用できる場合、DMS は pglogical を使用してレプリケーション スロットを作成し、それ以外の場合は test\$1decoding プラグインが使用されます。test\$1decoding プラグインの詳細については、「[PostgreSQL のドキュメント](https://www.postgresql.org/docs/9.4/test-decoding.html)」を参照してください。 データベースパラメータ `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 以上 | はい | | Aurora PostgreSQL 3.3 以上 | はい | で使用する pglogical を設定する前に AWS DMS、まず PostgreSQL ソースデータベースで変更データキャプチャ (CDC) の論理レプリケーションを有効にします。 + *セルフ管理* PostgreSQL ソースデータベースにおいて CDC での論理レプリケーションの有効化について詳しくは、「[セルフマネージド PostgreSQL データベースを AWS DMS ソースとして使用して CDC を有効にする](#CHAP_Source.PostgreSQL.Prerequisites.CDC)」をご参照ください。 + *AWSが管理する*PostgreSQL ソースデータベースでの CDC 用論理レプリケーションの有効化については、「[で AWS管理された PostgreSQL DB インスタンスで CDC を有効にする AWS DMS](#CHAP_Source.PostgreSQL.RDSPostgreSQL.CDC)」をご参照ください。 PostgreSQL ソースデータベースで論理レプリケーションを有効にした後、次のステップに従って、DMS で使用する pglogical を設定します。 **で PostgreSQL ソースデータベースの論理レプリケーションに pglogical プラグインを使用するには AWS DMS** 1. PostgreSQL ソースデータベースに pglogical 拡張機能を作成します： 1. 正しいパラメータを設定します： + セルフ管理 PostgreSQL データベースの場合は、データベースパラメータ `shared_preload_libraries= 'pglogical'` を設定します。 + Amazon RDS と Amazon Aurora PostgreSQL 互換エディションの PostgreSQL で、パラメーター `shared_preload_libraries` を同じ RDS パラメーターグループ内の `pglogical` に設定します。 1. PostgreSQL ソースデータベースを再起動します。 1. PostgreSQL データベースで、コマンド `create extension pglogical;` を実行します。 1. pglogical が正常にインストールされたことを確認するには、次のコマンドを実行します： `select * FROM pg_catalog.pg_extension` PostgreSQL ソースデータベースエンドポイントの変更データキャプチャを実行する AWS DMS タスクを作成できるようになりました。 **注記** PostgreSQL ソースデータベースで pglogical を有効にしないとき、 AWS DMS はデフォルトで `test_decoding` プラグインを使用します。pglogical が論理デコードに対して有効になっている場合、 はデフォルトで pglogical AWS DMS を使用します。ただし、代わりに `test_decoding` のプラグインを使用する追加の接続属性 `PluginName` を設定することもできます。 ## ネイティブ CDC スタートポイントを使用して PostgreSQL ソース エンドポイントの CDC ロードを設定するには エンドポイントを作成するときに、`slotName` の追加の接続属性を既存の論理レプリケーション スロットの名前に設定することで、ソースとして PostgreSQL によりネイティブ CDC スタートポイントを有効にします。この論理レプリケーションスロットは、エンドポイントの作成時点からの継続的な変更を保持するため、以前の時点からのレプリケーションをサポートします。 PostgreSQL は、 AWS DMS が論理レプリケーションスロットから変更を正常に読み取った後にのみ破棄される WAL ファイルにデータベースの変更を書き込みます。論理レプリケーションスロットを使用すると、ログに記録された変更がレプリケーションエンジンによって消費される前に削除されないように保護できます。 ただし、変更率と消費率によっては、論理レプリケーションスロットに保持されている変更により、ディスク使用率が高くなることがあります。論理レプリケーション スロットを使用する場合は、ソース PostgreSQL インスタンスにスペース使用アラームを設定することをお勧めします。追加の `slotName` 接続属性の設定についての詳細は、「[DMS ソースとして PostgreSQL を使用する場合のエンドポイント設定と追加の接続属性 (ECA)](#CHAP_Source.PostgreSQL.ConnectionAttrib)」をご参照ください。 次の手順では、このアプローチについて詳しく説明します。 **ネイティブ CDC 開始ポイントを使用して PostgreSQL ソースエンドポイントの CDC ロードを設定するには** 1. 開始点として使用する以前のレプリケーションタスク (親タスク) によって使用されていた論理レプリケーションスロットを特定します。次に、ソースデータベースの `pg_replication_slots` ビューにクエリを実行して、このスロットにアクティブな接続がないことを確認します。その場合は、先に進む前に解決して終了します。 次のステップでは、論理レプリケーションスロットが `abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef` であると仮定します。 1. 次の追加接続属性設定を含む新しいソースエンドポイントを作成します。 ``` slotName=abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef; ``` 1. コンソール AWS CLI または AWS DMS API を使用して、新しい CDC 専用タスクを作成します。たとえば、CLI を使用して、次の `create-replication-task` コマンドを実行できます。 ``` 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 ネイティブのスタートポイントの決定](CHAP_Task.CDC.md#CHAP_Task.CDC.StartPoint.Native)」を参照してください。 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'); ``` 1. データベースがレプリケーションスロットを作成した後、次のとおりスロットの **restart\$1lsn** と **confirmed\$1flush\$1lsn** の値を取得してメモしておきます。 ``` select * from pg_replication_slots where slot_name like 'replication_slot_name'; ``` レプリケーションスロットの後に作成された CDC タスクのネイティブな CDC 開始点は、**confirmed\$1flush\$1lsn** 値以前にできないことに注意します。 **restart\$1lsn** と **confirmed\$1flush\$1lsn** の値の詳細については、「[pg\$1replication\$1slots](https://www.postgresql.org/docs/14/view-pg-replication-slots.html)」を参照してください。 1. pglogical ノードを作成します。 ``` SELECT pglogical.create_node(node_name := 'node_name', dsn := 'your_dsn_name'); ``` 1. `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); ``` 1. レプリケーション集合にテーブルを追加します。 ``` SELECT pglogical.replication_set_add_table('replication_slot_name', 'schemaname.tablename', true); SELECT pglogical.replication_set_add_table('ireplication_slot_name', 'schemaname.tablename', true); ``` 1. ソース エンドポイントを作成するときに、次の追加接続属性 (ECA) を設定します。 ``` PluginName=PGLOGICAL;slotName=slot_name; ``` 新しいレプリケーション スロットを使用して PostgreSQL ネイティブのスタートポイントを使用して CDC のみのタスクを作成できるようになりました。pglogical プラグインの詳細については、「[pglogical 3.7 ドキュメント](https://www.enterprisedb.com/docs/pgd/3.7/pglogical/)」を参照してください。 ## を使用した PostgreSQL から PostgreSQL への移行 AWS DMS PostgreSQL 以外のデータベースエンジンから PostgreSQL データベースに移行する場合、 AWS DMS はほとんどの場合、最適な移行ツールです。一方、PostgreSQL データベースから PostgreSQL データベースに移行する場合、PostgreSQL ツールがより効果的な場合があります。 ### PostgreSQL ネイティブ ツールを使用してデータを移行する 以下の条件では、`pg_dump` などの PostgreSQL データベース移行ツールを使用することをお勧めします。 + ソース PostgreSQL データベースからターゲット PostgreSQL データベースに移行する同種移行である。 + データベース全体を移行する。 + ネイティブツールで最小のダウンタイムでデータを移行できる。 pg\$1dump ユーティリティでは、COPY コマンドを使用して、PostgreSQL データベースのスキーマとデータダンプを作成します。pg\$1dump によって生成されるダンプ スクリプトは、同じ名前のデータベースにデータをロードし、テーブル、インデックス、外部キーを再作成します。`pg_restore` コマンドと `-d` パラメータを使用して、データを別の名前でデータベースに復元できます。 EC2 で実行されている PostgreSQL ソースデータベースから Amazon RDS for PostgreSQL ターゲットにデータを移行する場合は、pglogical プラグインを使用できます。 PostgreSQL データベースを Amazon RDS for PostgreSQL や Amazon Aurora (PostgreSQL 互換エディション) にインポートする詳しい方法については、「[https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Procedural.Importing.html](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Procedural.Importing.html)」をご参照ください。 ### DMS を使用した PostgreSQL から PostgreSQL へのデータの移行 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 以前では、DMS はデフォルトでは 28 の精度と 6 のスケール (NUMERIC (28,6)) を使用します。たとえば、ソースからの値 0.611111104488373 は、PostgreSQL ターゲットの 0.611111 に変換されます。 + ARRAY データ型を持つテーブルにはプライマリ キーが必要です。ARRAY データ型にプライマリ キーがないテーブルは、全ロード中に中断されます。 次の表は、ソース PostgreSQL のデータ型と、これらのデータ型が正常に移行されるかどうかを示しています。 | データ型 | 正常に移行 | 部分的に移行 | 移行しない | コメント | | --- | --- | --- | --- | --- | | INTEGER | X | | | | | SMALLINT | X | | | | | BIGINT | X | | | | | NUMERIC/DECIMAL(p,s) | | X | | この場合、038 または 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 | | | PostGIS 空間データ型 | | LINE | | | X | | | LSEG | | | X | | | BOX | | | X | | | PATH | | | X | | | POLYGON | X | | | PostGIS 空間データ型 | | CIRCLE | | | X | | | JSON | | X | | | | 配列 | X | | | プライマリ キーが必要です | | COMPOSITE | | | X | | | RANGE | | | X | | | LINESTRING | X | | | PostGIS 空間データ型 | | MULTIPOINT | X | | | PostGIS 空間データ型 | | MULTILINESTRING | X | | | PostGIS 空間データ型 | | MULTIPOLYGON | X | | | PostGIS 空間データ型 | | GEOMETRYCOLLECTION | X | | | PostGIS 空間データ型 | ### PostGIS 空間データ型の移行 *空間データ*は、空間内のオブジェクトまたは位置のジオメトリ情報を識別します。PostgreSQL オブジェクトリレーショナルデータベースは、PostGIS 空間データ型をサポートしています。 PostgreSQL 空間データオブジェクトを移行する前に、PostGIS プラグインがグローバルレベルで有効になっていることを確認してください。これにより、 は PostgreSQL ターゲット DB インスタンスの正確なソース空間データ列 AWS DMS を作成します。 PostgreSQL から PostgreSQL への同種移行の場合、 は PostGIS の幾何学的および地理的 (地理的座標) データオブジェクトタイプとサブタイプの移行 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\$1db**。**エンドポイント設定**セクションで、**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 のアーキテクチャ](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/babelfish-architecture.html)」を参照してください。 単一のデータベースモードを使用する場合、データベーススキーマの名前を変更するための変換ルールを使用する必要はありません。PostgreSQL スキーマ名は、T-SQL データベース内のスキーマ名に 1 対 1 でマッピングされています。 次の変換ルールの例は、スキーマ名を `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 テーブルを作成する場合、DMS は SQL Server をターゲットとして移行するときに、`varbinary(max)` データ型に変換します。 + 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} ``` ## DMS ソースとして PostgreSQL データベースを使用する場合の追加設定 PostgreSQL データベースからデータを移行するときは、2 つの方法で詳細設定を追加できます。 + 追加接続属性に値を追加して、DDL イベントをキャプチャし、運用中の DDL データベースアーティファクトが作成されたスキーマを指定します。詳細については、「[DMS ソースとして PostgreSQL を使用する場合のエンドポイント設定と追加の接続属性 (ECA)](#CHAP_Source.PostgreSQL.ConnectionAttrib)」を参照してください。 + 接続文字列パラメータを上書きできます。これを行うには、次のいずれかのオプションを選択します： + 内部 AWS DMS パラメータを指定します。このようなパラメータが必要になることはめったにないため、ユーザー インターフェイスには表示されません。 + 特定のデータベースクライアントのパススルー (パススルー) 値を指定します。 は、データベースクライアントに渡される接続スティングにパススルーパラメータ AWS DMS を含めます。 + PostgreSQL バージョン 9.4 以降でテーブルレベルのパラメータ `REPLICA IDENTITY` を使用すると、ログ先行書き込み (WAL) に書き込まれる情報を制御できる。特に、更新または削除される行を識別する WAL に対してそうします。`REPLICA IDENTITY FULL` は行のすべての列の古い値を記録します。不必要に余分な量の WAL が `FULL` により生成されるため、`REPLICA IDENTITY FULL` はテーブルごとに慎重に使用してください。詳細については、「[ALTER TABLE-REPLICA IDENTITY](https://www.postgresql.org/docs/devel/sql-altertable.html)」を参照。 ## PostgreSQL のソースとしてのリードレプリカ PostgreSQL リードレプリカを の CDC ソースとして使用 AWS DMS して、プライマリデータベースの負荷を軽減します。この機能は PostgreSQL 16.x から使用でき、 AWS DMS バージョン 3.6.1 以降が必要です。CDC 処理にリードレプリカを使用すると、プライマリデータベースに対する運用上の影響が軽減されます。 **注記** Amazon RDS PostgreSQL バージョン 16.x では、3-AZ (TAZ) 設定でのリードレプリカの論理レプリケーションに制限があります。TAZ デプロイで完全リードレプリカの論理レプリケーションをサポートするには、PostgreSQL バージョン 17.x 以降を使用する必要があります。 ### 前提条件 の CDC ソースとしてリードレプリカを使用する前に AWS DMS、プライマリデータベースインスタンスとそのリードレプリカの両方で論理レプリケーションを有効にして、リードレプリカに論理デコードを作成する必要があります。次のアクションを実行します。 + プライマリデータベースインスタンスとそのリードレプリカの両方で論理レプリケーションを有効化します (その他必要なデータベースパラメータを含む)。詳細については、[AWS「マネージド PostgreSQL データベースを DMS ソースとして使用する](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.RDSPostgreSQL)」を参照してください。 + CDC 専用タスクの場合は、プライマリ (ライター) インスタンスにレプリケーションスロットを作成します。詳細については、「[ネイティブ CDC スタートポイントを使用して PostgreSQL ソース エンドポイントの CDC ロードを設定するには](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.v10)」を参照してください。リードレプリカがレプリケーションスロットの作成をサポートしていないため、このアクションが必要になります。 + PostgreSQL バージョン 16 の場合、スロットはリードレプリカで手動で作成する必要があります。 + PostgreSQL バージョン 17 以降では、レプリケーションスロットをプライマリに作成する必要があります。これはリードレプリカと自動的に同期されます。 + Full Load \$1 CDC または CDC のみのタスクを使用する場合、 AWS DMS はプライマリインスタンスで論理レプリケーションスロットを自動的に管理できますが、リードレプリカでは管理できません。PostgreSQL バージョン 16 リードレプリカの場合、タスクを再起動 (再開ではない) する前に、レプリケーションスロットを手動で削除して再作成する必要があります。この手順を行わない場合、タスクが失敗する、CDC の開始位置が不正になるなどの可能性があります。PostgreSQL バージョン 17 以降では、プライマリインスタンスからの論理スロット同期によってこのプロセスは自動化されます。 前提条件を完了したら、 AWS DMS エンドポイント設定でリードレプリカソース`SlotName`のレプリケーションを使用してソースエンドポイントを設定し、ネイティブ CDC 開始ポイントを使用して AWS DMS タスクを設定できます。詳細については、「[PostgreSQL を DMS エンドポイントとして使用する場合のエンドポイント設定および追加の接続属性 (ECA)](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.ConnectionAttrib)」および「[ネイティブ CDC 開始点を使用して PostgreSQL ソースの CDC ロードを設定する](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html#CHAP_Source.PostgreSQL.v10)」を参照してください。 ## `MapBooleanAsBoolean` PostgreSQL エンドポイント設定の使用 PostgreSQL エンドポイント設定を使用して、ブール値を PostgreSQL ソースから Amazon Redshift ターゲットにブール値としてマッピングできます。ブール型はデフォルトで varchar (5) として移行されます。次の例のとおり、`MapBooleanAsBoolean` を指定すると、PostgreSQL がブール型をブール型として移行できるようになります。 ``` --postgre-sql-settings '{"MapBooleanAsBoolean": true}' ``` この設定を有効にするには、ソースエンドポイントとターゲットエンドポイントの両方でこの設定を設定する必要があることに注意します。 MySQL には BOOLEAN 型がないため、BOOLEAN データを MySQL に移行する場合は、この設定ではなく変換ルールを使用します。 ## DMS ソースとして PostgreSQL を使用する場合のエンドポイント設定と追加の接続属性 (ECA) エンドポイント設定と追加の接続属性 (ECA) を使用して、ソースの PostgreSQL データベースを設定することができます。エンドポイント設定は、 AWS DMS コンソールを使用するか、`--postgre-sql-settings '{"EndpointSetting": "value", ...}'`JSON 構文で の `create-endpoint` コマンドを使用して[AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html)、ソースエンドポイントを作成するときに指定します。 次の表は、PostgreSQL をソースとして使用できるエンドポイント設定と ECA を説明しています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Source.PostgreSQL.html) ## DMS のソースとして PostgreSQL データベースを使用する場合の制限 PostgreSQL を AWS DMSのソースとして使用する場合は、以下の制限が適用されます。 + AWS DMS は、Amazon RDS for PostgreSQL 10.4 または Amazon Aurora PostgreSQL 10.4 をソースまたはターゲットとして使用することはできません。 + キャプチャされたテーブルにはプライマリキーが必要です。テーブルにプライマリキーがない場合、 はそのテーブルの DELETE および UPDATE レコードオペレーション AWS DMS を無視します。回避策については、「[Enabling change data capture (CDC) using logical replication](#CHAP_Source.PostgreSQL.Security)」を参照してください。 **注:** プライマリキーまたは一意のインデックスなしでの移行はお勧めしません。この場合、「いいえ」Batch 適用機能、フル LOB 機能、データ検証、Redshift ターゲットへの効率的なレプリケートができないなどの追加の制限が適用されます。 + AWS DMS は、プライマリキーセグメントを更新しようとする試みを無視します。この場合、ターゲットは、その更新によってどの行も更新されないと識別します。ただし、PostgreSQL でのプライマリキーの更新結果は予測できないため、どのレコードも例外テーブルには書き込まれません。 + AWS DMS は、**タイムスタンプからプロセスの変更を開始する**実行オプションをサポートしていません。 + AWS DMS は、パーティションまたはサブパーティションオペレーション (`ADD`、`DROP`、または ) に起因する変更をレプリケートしません`TRUNCATE`。 + 大文字と小文字の組み合わせが異なる同じ名前 (table1、TABLE1、Table1) を持つ複数のテーブルをレプリケートすると、予測できない動作が生じることがあります。この問題のため、 AWS DMS はこのタイプのレプリケーションをサポートしていません。 + ほとんどの場合、 は tables の CREATE、ALTER、DROP DDL ステートメントの変更処理 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` データ型として SQLServer ターゲットに移行されます。回避策として、列`VARCHAR(1)`のデータ型を使用してテーブルを事前に作成します (または、 でテーブル AWS DMS を作成します）。次に、ダウンストリーム処理で「F」を False、「T」を True として扱います。 + AWS DMS は、TRUNCATE オペレーションの変更処理をサポートしていません。 + OID LOB データ型は、ターゲットに移行されません。 + AWS DMS は、同種移行のみの PostGIS データ型をサポートしています。 + 使用するソースがオンプレミスあるいは Amazon EC2 インスタンス上の PostgreSQL データベースの場合、test\$1decoding 出力プラグインがソースのエンドポイントにインストールされていることを確認してください。このプラグインは、PostgreSQL contrib パッケージで提供されています。test-decoding プラグインの詳細については、「[PostgreSQL のドキュメント](https://www.postgresql.org/docs/10/static/test-decoding.html)」をご参照ください。 + AWS DMS では、列のデフォルト値を設定および設定解除する変更処理はサポートされていません (ALTER TABLE ステートメントの ALTER COLUMN SET DEFAULT 句を使用）。 + AWS DMS は、列の nullability を設定する変更処理をサポートしていません (ALTER TABLE ステートメントで ALTER COLUMN [SET\$1DROP] NOT NULL 句を使用）。 + 論理レプリケーションが有効な場合、トランザクションあたりのメモリに保持される変更の最大数は 4 MB です。その後、変更がディスクにこぼれます。その結果、`ReplicationSlotDiskUsage`が増加し、トランザクションが完了または停止し、ロールバックが完了するまで `restart_lsn` は進みません。長いトランザクションであるため、ロールバックに時間がかかることがあります。従って、論理レプリケーションが有効になっている場合は、トランザクションまたは多くのサブトランザクションの長期実行を避けてください。代わりに、トランザクションをいくつかの小さなトランザクションに分割します。 Aurora PostgreSQL バージョン 13 以降では、`logical_decoding_work_mem` パラメータを調整して DMS がいつ変更データをディスクに書き出すかを制御することができます。詳細については、「[Aurora PostgreSQL のスピルファイル](CHAP_Troubleshooting_Latency_Source_PostgreSQL.md#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Spill)」を参照してください。 + ARRAY データ型を持つテーブルにはプライマリ キーが必要です。ARRAY データ型にプライマリ キーがないテーブルは、全ロード中に中断されます。 + AWS DMS は、テーブルのパーティショニングまたはテーブル[の継承に関連するテーブル](https://www.postgresql.org/docs/15/ddl-inherit.html)メタデータの移行をサポートしていません。がパーティション分割されたテーブルまたは継承を使用するテーブル AWS DMS を検出すると、次の動作が観察されます。 + AWS DMS は、ソースデータベースのパーティション化または継承に関連する親テーブルと子テーブルの両方を識別してレポートします。 + **ターゲットでのテーブルの作成**: ターゲットデータベースで、 はテーブルを標準 (非パーティション化、非継承) テーブルとして AWS DMS 作成し、選択したテーブルの構造とプロパティは保持しますが、パーティション化または継承ロジックは保持しません。 + **継承されたテーブルでのレコードの区別: **継承を使用するテーブルの場合、親テーブルの入力時に子テーブルに属するレコードを区別 AWS DMS しません。その結果、`SELECT * FROM ONLY parent_table_name` などの構文の SQL クエリは使用しません。 + パーティション分割されたテーブルを PostgreSQL ソースから PostgreSQL ターゲットにレプリケーションする場合、まずターゲットで親テーブルと子テーブルを手動で作成する必要があります。次に、それらのテーブルにレプリケーションする別個のタスクを定義します。その場合、タスク設定を **[Truncate before loading]** (読み取り前切り捨て) に設定します。 + PostgreSQL `NUMERIC` データ型はサイズが固定されていません。`NUMERIC` データ型ですが、精度とスケールがないデータを転送する場合、DMS はデフォルトで `NUMERIC(28,6)` (精度が 28、スケールが 6) を使用します。たとえば、ソースからの値 0.611111104488373 は、PostgreSQL ターゲットの 0.611111 に変換されます。 + AWS DMS は、全ロードタスクのソースとしてのみ Aurora PostgreSQL Serverless V1 をサポートします。 は、全ロード、全ロードおよび CDC、CDC のみのタスクのソースとして Aurora PostgreSQL Serverless V2 AWS DMS をサポートします。 + AWS DMS は、coalesce 関数で作成された一意のインデックスを持つテーブルのレプリケーションをサポートしていません。 + ソースとターゲットのプライマリキー定義が一致しない場合、レプリケーションの結果は予測できない可能性があります。 + 並列ロード機能を使用する場合、パーティションまたはサブパーティションに基づくテーブルのセグメント化はサポートされません。並列ロードの詳細については、「[選択したテーブルおよびビューさらにコレクションで並列ロードを使用する](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md#CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.ParallelLoad)」を参照してください。 + AWS DMS は遅延制約をサポートしていません。 + AWS DMS バージョン 3.4.7 では、PostgreSQL 14.x をソースとしてサポートしていますが、以下の制限があります。 + AWS DMS は、2 つのフェーズコミットの変更処理をサポートしていません。 + AWS DMS は、進行中の長いトランザクションをストリーミングするための論理レプリケーションをサポートしていません。 + AWS DMS は、ソースとして Amazon RDS Proxy for PostgreSQL の CDC をサポートしていません。 + プライマリキー列を含まない [ソースフィルター](CHAP_Tasks.CustomizingTasks.Filters.md) を使用する場合、`DELETE` 操作はキャプチャされません。 + ソースデータベースが別のサードパーティーのレプリケーションシステムのターゲットでもある場合、CDC 中に DDL の変更が移行されない可能性があります。これは、このような状況では `awsdms_intercept_ddl` イベントトリガーが起動しなくなる可能性があるためです。この状況を回避するには、ソースデータベースでこのトリガーを次のとおり変更します。 ``` alter event trigger awsdms_intercept_ddl enable always; ``` + AWS DMS は、ソースデータベースのプライマリキー定義に加えられた変更のレプリケーションをサポートしていません。アクティブなレプリケーションタスク中にプライマリキー構造が変更された場合、影響を受けるテーブルに対するその後の変更はターゲットにレプリケートされません。 + スクリプトの一部としての DDL レプリケーションでは、スクリプトあたりの DDL コマンドの最大合計数は 8192 で、スクリプトあたりの行の最大合計数は 8192 行です。 + AWS DMS はマテリアライズドビューをサポートしていません。 + ソースとしてリードレプリカを使用する全ロードおよび CDC タスクの場合、リードレプリカにレプリケーションスロットを作成 AWS DMS することはできません。 ## PostgreSQL のソースデータ型 次の表は、 の使用時にサポートされる PostgreSQL ソースデータ型 AWS DMS と、 AWS DMS データ型へのデフォルトのマッピングを示しています。 ターゲットにマッピングされるデータ型を表示する方法については、使用しているターゲットエンドポイントのセクションをご参照ください。 AWS DMS データ型の詳細については、「」を参照してください[AWS Database Migration Service のデータ型](CHAP_Reference.DataTypes.md)。 | 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 | | タイムスタンプ時間帯あり | 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 | | 配列 | NCLOB | | COMPOSITE | NCLOB | | HSTORE | NCLOB | | INT4RANGE | STRING (255) | | INT8RANGE | STRING (255) | | NUMRANGE | STRING (255) | | STRRANGE | STRING (255) | ### PostgreSQL 用の LOB ソースデータ型での作業 PostgreSQL の列サイズは、PostgreSQL LOB データ型の AWS DMS データ型への変換に影響します。これを使用するには、次の AWS DMS データ型で以下の手順を実行します。 + BLOB - タスク作成で **[Limit LOB size to]** (LOB サイズ制限) 値を **[Maximum LOB Size (KB)]** (最大 LOB サイズ (KB)) に設定します。 + CLOB - レプリケーションは各文字を UTF8 文字として処理します。次に、列で最長の文字テキストの長さ (ここでは、`max_num_chars_text`) を見つけます。この長さを使用して、**[Limit LOB size to]** (LOB サイズを以下に制限する) の値を指定します。データに 4 バイト文字が含まれている場合には、2 倍にして [**Limit LOB size to (LOB サイズ制限)**] 値をバイト単位で指定します。この場合、**[Limit LOB size to]** (LOB サイズ制限) は `max_num_chars_text` の 2 乗と等しくなります。 + NCLOB - レプリケーションは各文字を 2 バイト文字として処理します。次に、列で最長の文字テキストの長さ (`max_num_chars_text`) を見つけ、2 倍します。これは、**[Limit LOB size to]** (LOB サイズを以下に制限する) の値の値を指定するために行います。この場合、**[Limit LOB size to]** (LOB サイズ制限) は `max_num_chars_text` の 2 乗と等しくなります。データに 4 バイト文字が含まれている場合は、再度 2 倍にします。この場合、[**Limit LOB size to (LOB サイズ制限)**] は `max_num_chars_text` の 4 乗と等しくなります。