翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# のターゲットとしての PostgreSQL データベースの使用 AWS Database Migration Service
別の PostgreSQL データベースまたはサポートされている他のデータベースのいずれかから AWS DMS、 を使用して PostgreSQL データベースにデータを移行できます。
がターゲットとして AWS DMS サポートする PostgreSQL のバージョンについては、「」を参照してください[のターゲット AWS DMS](CHAP_Introduction.Targets.md)。
**注記**
Amazon Aurora Serverless は、PostgreSQL と互換性のある Amazon Aurora のターゲットとして利用できます。Amazon Aurora Serverless の詳細については、「*Amazon Aurora ユーザーガイド*」の「[Amazon Aurora Serverless v2 を使用する](https://docs.aws.amazon.com//AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html)」を参照してください。
Aurora Serverless DB クラスターは Amazon VPC からのみアクセスでき、[[public IP address]](https://docs.aws.amazon.com//AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.requirements.html) (パブリック IP アドレス) を使用することはできません。そのため、レプリケーション インスタンスを Aurora PostgreSQL Serverless とは異なるリージョンに配置する場合は、[[vpc peering]](https://docs.aws.amazon.com//dms/latest/userguide/CHAP_ReplicationInstance.VPC.html#CHAP_ReplicationInstance.VPC.Configurations.ScenarioVPCPeer) (VPC ピアリング接続) を構成します。それ以外の場合は、Aurora PostgreSQL Serverless [[regions]](https://docs.aws.amazon.com//AmazonRDS/latest/AuroraUserGuide/Concepts.AuroraFeaturesRegionsDBEngines.grids.html#Concepts.Aurora_Fea_Regions_DB-eng.Feature.Serverless) (リージョン) の可用性をチェックし、これらのリージョンのいずれかを Aurora PostgreSQL Serverless とレプリケーション インスタンスの両方に使用しました。
Babelfish の機能は Amazon Aurora に組み込まれており、追加のコストは発生しません。詳細については、「[Using Babelfish for Aurora PostgreSQL as a target for AWS Database Migration Service](#CHAP_Target.PostgreSQL.Babelfish)」を参照してください。
AWS DMS は、フルロードフェーズでソースからターゲットにデータを移行するときにtable-by-tableアプローチを取ります。全ロードフェーズ中のテーブルの順序は保証されません。テーブル全ロードフェーズ中、および個々のテーブルのキャッシュしたトランザクションが適用されている間は、テーブルは同期されません。その結果、アクティブな参照整合性制約により、全ロードフェーズ中にタスクが失敗する可能性があります。
PostgreSQL では、外部キー (参照整合性制約) はトリガーを使用して実装されます。全ロードフェーズ中、 は各テーブルを一度に 1 つずつ AWS DMS ロードします。次のいずれかの方法を使用して、全ロード中に外部キーの制約を無効にすることを強くお勧めします。
+ インスタンスからすべてのトリガーを一時的に無効にして、全ロードを終了します。
+ PostgreSQL では、`session_replication_role` パラメータを使用します。
特定の時間において、トリガーは `origin`、`replica`、`always`、または `disabled` のいずれかの状態になります。`session_replication_role` パラメータが `replica` に設定されている場合、`replica` 状態のトリガーのみがアクティブになり、呼び出されると実行されます。それ以外の場合、トリガーは非アクティブなままです。
PostgreSQL には、`session_replication_role` が設定されている場合でも、テーブルの切り捨てを防止するフェールセーフメカニズムが備わっています。これを、トリガーを無効にする代わりに使用して、全ロードの完了を支援できます。これを行うには、ターゲットテーブルの準備モードを `DO_NOTHING` に設定します それ以外の場合、外部キーの制約があると DROP および TRUNCATE オペレーションは失敗します。
Amazon RDS では、パラメータグループを使用してこのパラメータの設定を管理できます。Amazon EC2 で実行されている PostgreSQL インスタンスの場合、パラメータを直接設定できます。
のターゲットとして PostgreSQL データベースを使用する方法の詳細については AWS DMS、以下のセクションを参照してください。
**Topics**
+ [のターゲットとしての PostgreSQL の使用に関する制限 AWS Database Migration Service](#CHAP_Target.PostgreSQL.Limitations)
+ [Amazon Aurora PostgreSQL Limitless を のターゲットとして使用する場合の制限 AWS Database Migration Service](#CHAP_Target.PostgreSQL.Aurora.Limitations)
+ [のターゲットとして PostgreSQL データベースを使用する場合のセキュリティ要件 AWS Database Migration Service](#CHAP_Target.PostgreSQL.Security)
+ [のターゲットとして PostgreSQL を使用する場合のエンドポイント設定と追加の接続属性 (ECAs) AWS DMS](#CHAP_Target.PostgreSQL.ConnectionAttrib)
+ [PostgreSQL のターゲットデータ型](#CHAP_Target.PostgreSQL.DataTypes)
+ [のターゲットとしての Babelfish for Aurora PostgreSQL の使用 AWS Database Migration Service](#CHAP_Target.PostgreSQL.Babelfish)
## のターゲットとしての PostgreSQL の使用に関する制限 AWS Database Migration Service
PostgreSQL データベースを AWS DMSのターゲットとして使用する場合、以下の制限が適用されます。
+ 異種の移行の場合、JSON データ型は内部でネイティブな CLOB データ型に変換されます。
+ Oracle から PostgreSQL への移行では、Oracle の列に NULL 文字 (16 進値 U\$10000) が含まれている場合、 は NULL 文字をスペース (16 進値 U\$10020) AWS DMS に変換します。これは、PostgreSQL の制限によるものです。
+ AWS DMS は、coalesce 関数で作成された一意のインデックスを持つテーブルへのレプリケーションをサポートしていません。
+ テーブルでシーケンスを使用する場合は、ソースデータベースからレプリケーションを停止した後、ターゲットデータベース内のシーケンス`NEXTVAL`ごとに の値を更新します。 はソースデータベースからデータ AWS DMS をコピーしますが、進行中のレプリケーション中にシーケンスをターゲットに移行しません。
## Amazon Aurora PostgreSQL Limitless を のターゲットとして使用する場合の制限 AWS Database Migration Service
Amazon Aurora PostgreSQL Limitless をターゲットとして使用する場合は、次の制限が適用されます AWS DMS。
+ AWS DMS データ検証は Amazon Aurora PostgreSQL Limitless をサポートしていません。
+ AWS DMS はソーステーブルを標準テーブルとして移行しますが、これは分散されません。移行後、公式の変換ガイドに従って、これらの標準テーブルを Limitless テーブルに変換できます。
## のターゲットとして PostgreSQL データベースを使用する場合のセキュリティ要件 AWS Database Migration Service
セキュリティ上の観点から、データ移行に使用されるユーザーアカウントは、ターゲットとして使用する PostgreSQL データベースにおける登録済みユーザーにする必要があります。
PostgreSQL ターゲットエンドポイントでは、 AWS DMS 移行を実行するために最小限のユーザーアクセス許可が必要です。次の例を参照してください。
```
CREATE USER newuser WITH PASSWORD 'your-password';
ALTER SCHEMA schema_name OWNER TO newuser;
```
または
```
GRANT USAGE ON SCHEMA schema_name TO myuser;
GRANT CONNECT ON DATABASE postgres to myuser;
GRANT CREATE ON DATABASE postgres TO myuser;
GRANT CREATE ON SCHEMA schema_name TO myuser;
GRANT UPDATE, INSERT, SELECT, DELETE, TRUNCATE ON ALL TABLES IN SCHEMA schema_name TO myuser;
GRANT TRUNCATE ON schema_name."BasicFeed" TO myuser;
```
## のターゲットとして PostgreSQL を使用する場合のエンドポイント設定と追加の接続属性 (ECAs) AWS DMS
エンドポイント設定と追加の接続属性 (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)、ターゲットエンドポイントを作成するときに設定を指定します。
エンドポイントの `ExtraConnectionAttributes` パラメータを使用して ECA を指定します。
次の表は、PostgreSQL をターゲットとして使用できるエンドポイント設定を説明しています。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Target.PostgreSQL.html)
## PostgreSQL のターゲットデータ型
の PostgreSQL データベースエンドポイントは、ほとんどの PostgreSQL データベースデータ型 AWS DMS をサポートしています。次の表は、 の使用時にサポートされる PostgreSQL データベースターゲットデータ型 AWS DMS と AWS DMS 、データ型からのデフォルトのマッピングを示しています。
AWS DMS データ型の詳細については、「」を参照してください[AWS Database Migration Service のデータ型](CHAP_Reference.DataTypes.md)。
| AWS DMS データ型 | PostgreSQL のデータ型 |
| --- | --- |
| BOOLEAN | BOOLEAN |
| BLOB | BYTEA |
| BYTES | BYTEA |
| DATE | DATE |
| TIME | TIME |
| DATETIME | スケールが 0 ～ 6 の場合、タイムスタンプ を使用します。 スケールが 7 ～ 9 の場合、VARCHAR (37) を使用します。 |
| INT1 | SMALLINT |
| INT2 | SMALLINT |
| INT4 | INTEGER |
| INT8 | BIGINT |
| NUMERIC | DECIMAL (P,S) |
| REAL4 | FLOAT4 |
| REAL8 | FLOAT8 |
| STRING | 長さが 1 ～ 21,845 の場合、VARCHAR (バイト単位の長さ) を使用します。 長さが 21,846 ～ 2,147,483,647 の場合、VARCHAR (65535) を使用します。 |
| UINT1 | SMALLINT |
| UINT2 | INTEGER |
| UINT4 | BIGINT |
| UINT8 | BIGINT |
| WSTRING | 長さが 1 ～ 21,845 の場合、VARCHAR (バイト単位の長さ) を使用します。 長さが 21,846 ～ 2,147,483,647 の場合、VARCHAR (65535) を使用します。 |
| NCLOB | TEXT |
| CLOB | TEXT |
**注記**
PostgreSQL ソースからレプリケートする場合、 は、ユーザー定義のデータ型の列を除き、すべての列に対して同じデータ型のターゲットテーブル AWS DMS を作成します。このような場合、データ型はターゲットで「character varying」として作成されます。
## のターゲットとしての Babelfish for Aurora PostgreSQL の使用 AWS Database Migration Service
AWS Database Migration Serviceを使用して SQL Server ソーステーブルを Babelfish for Amazon Aurora PostgreSQL のターゲットに移行できます。Babelfishを使用すると、Aurora PostgreSQL は Microsoft SQL Server 独自の SQL 言語である T-SQL を認識し、同じ通信プロトコルをサポートします。これにより、SQL Server 向けに作成されたアプリケーションのコード変更量が低減し、Aurora と連携できるようになります。Babelfish の機能は Amazon Aurora に組み込まれており、追加のコストは発生しません。Amazon Aurora クラスターのBabelfish は、Amazon RDS コンソールで有効化できます。
AWS DMS コンソール、API、または CLI コマンドを使用して AWS DMS ターゲットエンドポイントを作成するときは、ターゲットエンジンを **Amazon Aurora PostgreSQL** として指定し、データベースに **babelfish\$1db** という名前を付けます。**[エンドポイント設定]** セクションで、`DatabaseMode` を `Babelfish` に設定して、`BabelfishDatabaseName` をターゲットの Babelfish T-SQL データベース名に指定する設定を追加します。
### 移行タスクへの変換ルールの追加
Babelfish のターゲットの移行タスクを定義する場合、DMS がターゲットデータベース内で事前に作成された T-SQL Babelfish テーブルを使用するようにする変換ルールを含める必要があります。
まず、すべてのテーブル名を小文字にする変換ルールを移行タスクに追加します。Babelfish は、T-SQLを使用して作成したテーブル名前 PostgreSQL の `pg_class` カタログに小文字で保存します。ただし、大文字と小文字が混在する名前の SQL Server テーブルがある場合、DMS は T-SQL 互換のデータ型ではなく PostgreSQL ネイティブのデータ型を使用してテーブルを作成します。このため、すべてのテーブル名を小文字にする変換ルールを必ず追加します。列名は小文字に変換しないように注意してください。
次に、クラスターを定義する際にマルチデータベース移行モードを使用した場合は、元の SQL Server スキーマ名を変更する変換ルールを追加します。T-SQL データベース名が含まれるように SQL Server スキーマ名は必ず変更します。例えば、元の SQL Server のスキーマ名が dbo で、T-SQL データベース名が mydb の場合、変換ルールを使用してスキーマ名を mydb\$1dbo に変更します。
**注記**
Babelfish for Aurora PostgreSQL 16 以降を使用する場合、デフォルトの移行モードは「mutidatabase」です。DMS 移行タスクを実行する場合、移行モードパラメータを確認し、必要に応じて変換ルールを更新してください。
単一のデータベースモードを使用する場合、スキーマ名を変更するための変換ルールは必要ありません。スキーマ名は、ターゲットの Babelfish の T-SQL データベースと 1 対 1 でマッピングされます。
次の変換ルールサンプルでは、すべてのテーブル名を小文字にして、元の SQL Server スキーマ名を `dbo` から `mydb_dbo` に変更しています。
```
{
"rules": [
{
"rule-type": "transformation",
"rule-id": "566251737",
"rule-name": "566251737",
"rule-target": "schema",
"object-locator": {
"schema-name": "dbo"
},
"rule-action": "rename",
"value": "mydb_dbo",
"old-value": null
},
{
"rule-type": "transformation",
"rule-id": "566139410",
"rule-name": "566139410",
"rule-target": "table",
"object-locator": {
"schema-name": "%",
"table-name": "%"
},
"rule-action": "convert-lowercase",
"value": null,
"old-value": null
},
{
"rule-type": "selection",
"rule-id": "566111704",
"rule-name": "566111704",
"object-locator": {
"schema-name": "dbo",
"table-name": "%"
},
"rule-action": "include",
"filters": []
}
]
}
```
### Babelfish テーブルで PostgreSQL のターゲットエンドポイントを使用する場合の制限
Babelfish テーブルで PostgreSQL のターゲットエンドポイントを使用する場合、次の制限が適用されます。
+ **[ターゲットテーブル作成モード]** では、**[何もしない]** モードまたは **[切り捨て]** モードのみを使用します。**[ターゲット上のテーブルを削除]** モードは使用しないでください。このモードの場合、DMS は T-SQL が認識しない可能性のある PostgreSQL テーブルとしてテーブルを作成します。
+ AWS DMS は sql\$1variant データ型をサポートしていません。
+ Postgres エンドポイントの Babelfish は、`HEIRARCHYID`、`GEOMETRY` (3.5.4 以前)、`GEOGRAPHY` (3.5.4 以前) のデータ型をサポートしていません。上記のデータ型を移行するには、変換ルールを追加してデータ型を wstring (250) に変換します。
+ Babelfish での `BINARY` データ型、`VARBINARY` データ型、`IMAGE` データ型の以降は、`BYTEA` データ型を使用することでのみサポートされます。Aurora PostgreSQL の以前のバージョンの場合、DMS を使用してこのようなテーブルを [Babelfish のターゲットエンドポイント](CHAP_Target.Babelfish.md) に移行できます。次の例のとおり、`BYTEA` データ型で長さを指定する必要はありません。
```
[Picture] [VARBINARY](max) NULL
```
上記の T-SQL データ型を T-SQL がサポートする `BYTEA` データ型に変更します。
```
[Picture] BYTEA NULL
```
+ Aurora PostgreSQL Babelfish の以前のバージョンでは、PostgreSQL ターゲットエンドポイントを使用して SQL Server から Babelfish への継続的なレプリケーションのための移行タスクを作成する場合、`IDENTITY` 列を使用するすべてのテーブルに `SERIAL` データ型を割り当てる必要があります。Aurora PostgreSQL (バージョン 15.3、14.8 以降) と Babelfish (バージョン 3.2.0 以降) 以降では、アイデンティティ列がサポートされるようになったため、SERIAL データ型を割り当てる必要はありません。詳細については、「**SQL Server to Aurora PostgreSQL 移行プレイブック」の「Sequences and Identity」セクションの「[SERIAL Usage](https://docs.aws.amazon.com/dms/latest/sql-server-to-aurora-postgresql-migration-playbook/chap-sql-server-aurora-pg.tsql.sequences..html)」を参照してください。Babelfish でテーブルを作成する際は、列の定義を次のとおり変更します。
```
[IDCol] [INT] IDENTITY(1,1) NOT NULL PRIMARY KEY
```
上記の内容を次のとおり変更します。
```
[IDCol] SERIAL PRIMARY KEY
```
Babelfish 互換の Aurora PostgreSQL では、デフォルト設定を使用してシーケンスを作成し、列に `NOT NULL` 制約を追加します。新たに作成されるシーケンスは通常のシーケンス (1 でインクリメント) と同様に動作し、複合型の `SERIAL` のオプションはありません。
+ `IDENTITY` 列または `SERIAL` データ型を使用するテーブルのデータを移行した後、列の最大値に基づいて PostgreSQL ベースのシーケンスオブジェクトをリセットします。テーブルのフルロード実行後、次の T-SQL クエリを使用してステートメントを生成し、関連づけられたシーケンスオブジェクトをシードします。
```
DECLARE @schema_prefix NVARCHAR(200) = ''
IF current_setting('babelfishpg_tsql.migration_mode') = 'multi-db'
SET @schema_prefix = db_name() + '_'
SELECT 'SELECT setval(pg_get_serial_sequence(''' + @schema_prefix + schema_name(tables.schema_id) + '.' + tables.name + ''', ''' + columns.name + ''')
,(select max(' + columns.name + ') from ' + schema_name(tables.schema_id) + '.' + tables.name + '));'
FROM sys.tables tables
JOIN sys.columns columns ON tables.object_id = columns.object_id
WHERE columns.is_identity = 1
UNION ALL
SELECT 'SELECT setval(pg_get_serial_sequence(''' + @schema_prefix + table_schema + '.' + table_name + ''',
''' + column_name + '''),(select max(' + column_name + ') from ' + table_schema + '.' + table_name + '));'
FROM information_schema.columns
WHERE column_default LIKE 'nextval(%';
```
このクエリは、最大 IDENTITY 値と SERIAL 値を更新する SELECT ステートメントのセットを生成します。
+ バージョン 3.2 以前の Babelfish では、**[完全 LOB モード]** の場合、テーブルエラーが発生する可能性があります。エラーが発生した場合は、ロードに失敗したテーブルのために別のタスクを作成します。その後、**[制限付き LOB モード]** を使用して **[最大 LOB サイズ (KB)]** に適切な値を指定します。もう 1 つのオプションとして、SQL Server エンドポイント接続属性設定を `ForceFullLob=True` と指定する方法があります。
+ バージョン 3.2 以前の Babelfish では、整数ベースのプライマリキーを使用しない Babelfish テーブルでデータ検証を実行すると、適切な一意のキーが見つからないというメッセージが表示されます。整数以外のプライマリキーのデータ検証は、Aurora PostgreSQL (バージョン 15.3、14.8 以降) と Babelfish (バージョン 3.2.0 以降) 以降ではサポートされています。
+ 秒の小数点以下の桁数の精度の違いにより、DMS は `DATETIME` データ型を使用する Babelfish テーブルでデータ検証エラーを報告します。このようなエラーが表示されないようにするには、`DATETIME` データ型に次のとおりの検証ルールタイプを追加します。
```
{
"rule-type": "validation",
"rule-id": "3",
"rule-name": "3",
"rule-target": "column",
"object-locator": {
"schema-name": "dbo",
"table-name": "%",
"column-name": "%",
"data-type": "datetime"
},
"rule-action": "override-validation-function",
"source-function": "case when ${column-name} is NULL then NULL else 0 end",
"target-function": "case when ${column-name} is NULL then NULL else 0 end"
}
```