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

PostgreSQL の評価

このセクションでは、PostgreSQL のソースエンドポイントを使用する移行タスクの個別の移行前評価について説明します。

DDL イベントトリガーが ENABLE ALWAYS に設定されているかどうかを検証する

API キー: postgres-check-ddl-event-trigger

この移行前評価では、DDL イベントトリガーが ENABLE ALWAYS に設定されているかどうかを検証します。ソースデータベースが別のサードパーティーのレプリケーションシステムのターゲットでもある場合、CDC 中に DDL の変更が移行されない可能性があります。この状況では、DMS が awsdms_intercept_ddl イベントをトリガーできなくなる可能性があります。この状況を回避するには、ソースデータベースでトリガーを次の例のように変更します。

alter event trigger awsdms_intercept_ddl enable always;

詳細については、「Limitations on using a PostgreSQL database as a DMS source」を参照してください。

PostGIS 列がソースデータベースに存在するかどうかを検証する

API キー: postgres-check-postgis-data-type

この移行前評価では、ケースソースエンジンとターゲットエンジンに存在する PostGIS データ型の列が異なるかどうかを検証します。 は、同種 (like-to-like) 移行に対してのみ PostGIS データ型AWS DMSをサポートします。

詳細については、「Limitations on using a PostgreSQL database as a DMS source」を参照してください。

フルロードプロセス中にターゲットテーブルの外部キー制約が無効になっているかどうかを検証する

API キー: postgres-check-session-replication-role

この移行前評価では、フルロードフェーズ中に外部キーの制約を無効にするために、ターゲットで session_replication_role parameter が REPLICA に設定されているかどうかを検証します。フルロード移行タイプでは、外部キー制約を無効にする必要があります。

PostgreSQL エンドポイントの制約事項については、「Using a PostgreSQL database as a target for AWS Database Migration Service」を参照してください。

名前が似ているテーブルが存在するかどうかを検証する

API キー: postgres-check-similar-table-name

この移行前評価では、ソースに名前が似ているテーブルがあるかどうかを検証します。同じ名前の複数のテーブルを異なるケースで書き込むと、レプリケーション中に予測不可能な動作が発生する可能性があります。

PostgreSQL エンドポイントの制約事項については、「Limitations on using a PostgreSQL database as a DMS source」を参照してください。

プライマリキーのない ARRAY データ型を持つテーブルがあるかどうかを検証する

API キー: postgres-check-table-with-array

この移行前評価では、プライマリキーのない配列データ型を持つテーブルがあるかどうかを検証します。プライマリキーがない ARRAY データ型を持つテーブルは、フルロード中に無視されます。

PostgreSQL エンドポイントの制約事項については、「Limitations on using a PostgreSQL database as a DMS source」を参照してください。

BatchApplyEnabled が有効になっている場合、ターゲットテーブルにプライマリキーまたは一意のインデックスが存在するかどうかを検証する

API キー: postgres-check-batch-apply-target-pk-ui-absence

バッチ適用は、ターゲットテーブルでプライマリキーまたは一意のインデックスを持つテーブルでのみサポートされます。プライマリキーまたは一意のインデックスがないテーブルは、バッチを失敗させ、変更を 1 つずつ処理AWS DMSします。そのようなテーブルには別々のタスクを作成し、代わりにトランザクション適用モードを使用することをお勧めします。または、ターゲットテーブルに一意のキーを作成することができます。

詳細については、「Using a PostgreSQL database as a target for AWS Database Migration Service」を参照してください。

ターゲットデータベースのテーブルにフルロード移行タスクのセカンダリインデックスがあるかどうかを検証する

API キー: postgres-check-target-secondary-indexes

この移行前評価では、フルロード移行タスクの範囲にセカンダリインデックスを持つテーブルがあるかどうかを検証します。フルロードタスクの期間中は、セカンダリインデックスを削除することをお勧めします。

詳細については、「AWS Database Migration Service ソースとしての PostgreSQL データベースの使用」を参照してください。

BatchApplyEnabled が true に設定されている場合、制限付き LOB モードのみを使用していることを検証する

API キー: postgres-batch-apply-lob-mode

LOB 列がレプリケーションに含まれる場合、制限付き LOB モードのみで BatchApplyEnabled を使用できます。LOB モードの他のオプションを使用すると、バッチは失敗し、 AWS DMSは変更を 1 つずつ処理します。これらのテーブルを独自のタスクに移動し、代わりにトランザクション適用モードを使用することをお勧めします。

BatchApplyEnabled 設定に関する詳細については、「DMS バッチ適用機能を使用して CDC レプリケーションパフォーマンスを向上させるにはどうすればよいですか?」を参照してください。

ソースデータベースバージョンが DMS の移行でサポートされているかどうかを検証する

API キー: postgres-check-dbversion

この移行前評価では、ソースデータベースのバージョンが と互換性があるかどうかを検証しますAWS DMS。

ソースデータベースの logical_decoding_work_mem パラメータを検証する

API キー: postgres-check-for-logical-decoding-work-mem

この移行前評価では、ソースデータベースの logical_decoding_work_mem パラメータを調整することをお勧めします。長時間のトランザクションや多数のサブトランザクションが実行される可能性のあるトランザクション性が高いデータベースでは、論理デコードメモリの消費量が増加し、ディスクに書き込む必要が生じる可能性があります。これにより、レプリケーション中に DMS ソースのレイテンシーが高くなります。このようなシナリオでは、logical_decoding_work_mem を調整する必要がある場合があります。このパラメータは PostgreSQL バージョン 13 以降でサポートされています。

ソースデータベースに長時間実行しているトランザクションがあるかどうかを検証する

API キー: postgres-check-longrunningtxn

この移行前評価では、ソースデータベースに 10 分を超えて長時間実行されているトランザクションがあるかどうかを検証します。デフォルトでは、DMS はタスクの開始中に開いているトランザクションをチェックするため、タスクの開始が失敗することがあります。

ソースデータベースのパラメータ max_slot_wal_keep_size を検証する

API キー: postgres-check-maxslot-wal-keep-size

この移行前評価では、max_slot_wal_keep_size に設定された値を検証します。max_slot_wal_keep_size をデフォルト値以外の値に設定すると、必要な WAL ファイルが削除されるため、DMS タスクが失敗する可能性があります。

ソースデータベースパラメータ postgres-check-maxwalsenders が CDC をサポートするように設定されていることを確認する。

API キー: postgres-check-maxwalsenders

この移行前評価では、ソースデータベースの max_wal_senders に設定された値を検証します。DMS は、変更データキャプチャ (CDC) をサポートするために max_wal_senders を 1 より大きく設定する必要があります。

ソースデータベースが PGLOGICAL に設定されているかどうかを確認する

API キー: postgres-check-pglogical

この移行前評価では、CDC の PGLOGICAL をサポートするように shared_preload_libraries 値が pglogical に設定されているかどうかを確認します。論理レプリケーションにテストデコードを使用する場合、この評価を無視できることに注意してください。

ソーステーブルのプライマリキーが LOB データ型であるかどうかを検証する

API キー: postgres-check-pk-lob

この移行前評価では、テーブルのプライマリキーが大容量オブジェクト (LOB) データ型であるかどうかを検証します。ソーステーブルにプライマリキーとして LOB 列がある場合、DMS はレプリケーションをサポートしません。

ソーステーブルにプライマリキーがあるかどうかを検証する

API キー: postgres-check-pk

この移行前評価では、タスクの範囲で使用されるテーブルにプライマリキーが存在するかどうかを検証します。DMS は、レプリカアイデンティティがソーステーブルで full に設定されていない限り、プライマリキーのないテーブルのレプリケーションをサポートしていません。

準備済みのトランザクションがソースデータベースに存在するかどうかを検証する

API キー: postgres-check-preparedtxn

この移行前評価では、ソースデータベースに準備済みのトランザクションが存在するかどうかを確認します。レプリケーションスロットの作成は、ソースデータベースに準備済みのトランザクションがある場合、応答を停止することがあります。

DMS CDC をサポートするために wal_sender_timeout が必要最小限の値に設定されているかどうかを検証する

API キー: postgres-check-walsenderstimeout

この移行前評価では、wal_sender_timeout が 10,000 ミリ秒 (10 秒) の最小値に設定されているかどうかを検証します。CDC での DMS タスクには最低 10,000 ミリ秒 (10 秒) が必要となり、値が 10,000 ミリ秒未満になると失敗する。

ソースデータベースで wal_level が論理に設定されているかどうかを検証する

API キー: postgres-check-wallevel

この移行前評価では、wal_level が論理に設定されているかどうかを検証します。DMS CDC が機能するには、ソースデータベースでこのパラメータを有効にする必要があります。

プライマリキーと一意のインデックスの両方がバッチ適用のターゲットに存在するかどうかを検証する

API キー: postgres-check-batch-apply-target-pk-ui-simultaneously

バッチ適用は、ターゲットテーブルでプライマリキーまたは一意のインデックスを持つテーブルでのみサポートされます。プライマリキーまたは一意のインデックスが同時に存在するテーブルはバッチが失敗し、変更は一つずつ処理されます。このようなテーブルは独自のタスクに移動し、代わりにトランザクション適用モードを活用することをお勧めします。または、移行を実行している場合は、ターゲットテーブルの一意のキーまたはプライマリキーを削除してから、ターゲットテーブルを再構築することもできます。

詳細については、「セルフマネージド PostgreSQL データベースをAWS DMSソースとして使用して CDC を有効にする」を参照してください。

LOB オブジェクトが見つかった場合は、最大 LOB 設定を推奨する

API キー: postgres-check-limited-lob-size

PostgreSQL の LOB サイズ計算は、その他のエンジンとは異なります。データの切り捨てを回避するため、必ずタスク設定で適切な最大 LOB サイズを設定してください。

詳細については、「AWSDMS データ検証」を参照してください。

DMS 検証が有効になっている場合にテーブルにプライマリキーまたは一意のインデックスがあり、その状態が良好かどうかを検証する

API キー: postgres-check-pk-validity

データ検証では、テーブルにプライマリキーまたは一意のインデックスがなければなりません。

詳細については、「AWSDMS データ検証」を参照してください。

AWS DMS ユーザーがターゲットに対して必要な権限を持っているかどうかを検証する

API キー: postgres-check-target-privileges

AWS DMSユーザーは、ターゲットデータベースに少なくとも db_owner ユーザーロールを持っている必要があります。

詳細については、「のターゲットとして PostgreSQL データベースを使用する場合のセキュリティ要件AWS Database Migration Service」を参照してください。

CDC が無料のレプリケーションスロットを利用できるかどうかを検証します

API キー: postgres-check-replication-slots-count

この評価では、CDC が変更をレプリケートするためのレプリケーションスロットが利用可能かどうかを検証します。

DMS ユーザーのフルロードアクセス許可を検証する

API キー: postgres-check-select-object-privileges

この評価では、DMS ユーザーがフルロードオペレーションに必要なテーブルに対して必要な SELECT 権限を持っているかどうかを検証します。

数字ランダム化の変換ルールを確認する

API キー: postgres-datamasking-digits-randomize

この評価では、テーブルマッピングで使用される列が数字ランダム化の変換ルールに適合しているかどうかを検証します。さらに、変換対象として選択された列がプライマリキー、一意の制約、または外部キーの一部であるかどうかも確認します。これは、数字ランダム化の変換を適用しても一意性は保証されないためです。

数字マスクの変換ルールを確認する

API キー: postgres-datamasking-digits-mask

この評価では、テーブルマッピングで使用される列が数字マスクの変換ルールでサポートされていないかどうかを検証します。さらに、変換対象として選択された列がプライマリキー、一意の制約、または外部キーの一部であるかどうかも確認します。これは、一意性が保証されないために、このような列に数字マスクの変換を適用すると、DMS タスクが失敗する可能性があるからです。

ハッシュマスクの変換ルールを確認する

API キー: postgres-datamasking-hash-mask

この評価では、テーブルマッピングで使用される列がハッシュマスクの変換ルールでサポートされていないかどうかを検証します。また、ソース列の長さが 64 文字を超えているかどうかも確認します。ハッシュマスキングをサポートするには、ターゲット列の長さが 64 文字を超えていることが理想的です。さらに、変換対象として選択された列がプライマリキー、一意の制約、または外部キーの一部であるかどうかも確認します。これは、数字ランダム化の変換を適用しても一意性は保証されないためです。

データ検証タスク設定とデータマスキングの数字ランダム化が同時に有効になっていないことを確認する

API キー: all-to-all-validation-with-datamasking-digits-randomize

この移行前評価では、データ検証設定とデータマスキングの数字ランダム化が同時に有効になっていないことを確認します。これらの機能には互換性はありません。

データ検証タスク設定とデータマスキングのハッシュマスクが同時に有効になっていないことを確認する

API キー: all-to-all-validation-with-datamasking-hash-mask

この移行前評価では、データ検証設定とデータマスキングのハッシュマスクが同時に有効になっていないことを確認します。これらの機能には互換性はありません。

データ検証タスク設定とデータマスキングの数字マスクが同時に有効になっていないことを確認する

API キー: all-to-all-validation-with-digit-mask

この移行前評価では、データ検証設定とデータマスキングの数字マスクが同時に有効になっていないことを確認します。これらの機能には互換性はありません。

選択したオブジェクトが少なくとも 1 つソースデータベースに存在することを検証します。

API キー: all-check-source-selection-rules

この移行前評価では、ワイルドカードベースのルールのパターンマッチングなど、選択ルールで指定された少なくとも 1 つのオブジェクトがソースデータベースに存在することを確認します。

ターゲット PostgreSQL データベースに生成された列が含まれていることを確認する

API キー: postgres-check-target-generated-cols

この移行前評価では、ターゲット PostgreSQL データベースに、移行中に特別な処理が必要になる可能性のある生成された列 (STORED 型と VIRTUAL 型の両方を含む) が含まれているかどうかを検証します。生成された列は、他の列から値を計算するため、ターゲット PostgreSQL バージョンとの互換性と移行後の適切なデータ整合性を確保するために、特定の検証が必要です。

マテリアライズドビューが同種 PostgreSQL 移行に存在することを確認する

API キー: postgres-check-materialized-views

PostgreSQL データベース間で移行する場合、マテリアライズドビューAWS DMSを移行することはできません。マテリアライズドビューは、移行後にターゲットデータベースに手動で作成する必要があります。

詳細については、「DMS のソースとして PostgreSQL データベースを使用する場合の制限」を参照してください。

REPLICA IDENTITY FULL が pglogical プラグインの使用と競合することを検証する

API キー: postgres-check-pglogical-replica-identity-full

この移行前評価では、REPLICA IDENTITY FULL を使用してテーブルを検出します。REPLICA IDENTITY FULL は test_decoding プラグインを使用してサポートされていますが、pglogical で使用する場合、更新が正しくレプリケートされません。REPLICA IDENTITY 設定を DEFAULT/INDEX に変更するか、test_decoding プラグインに切り替えて REPLICA IDENTITY FULL を維持します。

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

セカンダリ制約とインデックス (非プライマリ) がソースデータベースに存在することを確認する

API キー: all-check-secondary-constraints

この移行前評価では、セカンダリ制約とインデックス (外部キー、チェック制約、クラスター化されていないインデックス) がソースデータベースに存在することを確認します。

Oracle への移行のために CHAR/VARCHAR 列の互換性を検証する

API キー: postgres-to-oracle-check-varchar-columns

この移行前評価では、ターゲットデータベースで使用される NCHAR/NVARCHAR2 データ型列がソースデータベースの CHAR/VARCHAR 列と互換性があることを確認します。

ソースデータベースでidle_in_transaction_session_timeout設定されていることを確認します。

API キー: postgres-check-idle-in-transaction-session-timeout

この移行前評価では、ソースデータベースで idle_in_transaction_session_timeoutパラメータが 0 に設定されていないことを確認します。

AWS DMSユーザーがAWSマネージド PostgreSQL データベースに必要なロールを持っていることを確認する

API キー: postgres-check-rds-roles

この移行前評価では、AWS DMSユーザーがAWSマネージド PostgreSQL データベースに必要なすべてのロールで設定されていることを確認します。ロールが不十分な場合、移行タスクが失敗する可能性があります。