既知の制限事項

データベースを AlloyDB for PostgreSQL に移行する前に、この移行シナリオの既知の制限事項を考慮してください。

PostgreSQL データベースを移行元として使用する場合の既知の制限事項は次のとおりです。

  • pglogical 拡張機能は、PostgreSQL 12 以降の 生成列のレプリケーションをサポートしていません。

  • テーブル構造（DDL）の変更は、標準の DDL コマンドではレプリケートされません。レプリケーションに使用される pglogical 拡張機能を使用して実行されるコマンドでのみレプリケートされます。これには、enum 型の変更が含まれます。

    • たとえば、pglogical には pglogical.replicate_ddl_command 関数が用意されており、ソース データベースとレプリカの両方で DDL を一貫したポイントで実行できます。ソースでこのコマンドを実行するユーザーは、レプリカにすでに存在している必要があります。
    • 新しく作成されたテーブルのデータを複製するには、pglogical.replication_set_add_table コマンドを使用して、既存のレプリケーション セットに新しいテーブルを追加する必要があります。
    • 移行中の DDL レプリケーションの詳細については、移行の忠実度をご覧ください。

  • オブジェクトの制限事項:

    • 外部テーブルは論理レプリケーションによって複製されません。
    • UNLOGGED テーブルと TEMPORARY テーブルは複製されず、複製できません。
    • ラージ オブジェクト データ型（pg_largeobject を参照する oid）は、PostgreSQL の論理デコードではサポートされていません。
    • Database Migration Service は、マテリアライズド ビューからデータを移行せず、ビューのスキーマのみを移行します。宛先データベースのビューにデータを入力するには、REFRESH MATERIALIZED VIEW view_name; を実行します。
    • CDC の進行中に、宛先の SEQUENCE 状態（last_value など）がソースと異なる場合があります。シーケンス値は、最終プロモーション ステップで同期されます。

  • 主キーがないテーブルの場合、Database Migration Service は、変更データ キャプチャ（CDC）フェーズでの初期スナップショットと INSERT ステートメントの移行をサポートします。UPDATE ステートメントと DELETE ステートメントの移行は、次の点で異なります。

    • 標準移行: 主キーのないテーブルの場合、UPDATE ステートメントと DELETE ステートメントは移行されません。移行前に列の主キーを追加するか、UPDATE ステートメントと DELETE ステートメントを手動で移行する必要があります。
    • クイックスタート移行: クイックスタート移行では、レプリカ ID を INDEX または FULL に設定すると、UPDATE オペレーションと DELETE オペレーションを複製するために主キーは必要ありません。REPLICA IDENTITY FULL を構成すると、write-ahead log（WAL）のボリュームとリソースのオーバーヘッドが増加します。可能な場合は、主キーを追加することをおすすめします。詳細については、 PostgreSQL レプリカ ID のドキュメントと クイックスタート移行ガイドをご覧ください。

  • 移行できるのは、AlloyDB for PostgreSQL が PostgreSQL でサポートしている拡張機能と拡張機能のバージョンのみです。Database Migration Service は、AlloyDB for PostgreSQL でサポートされていない拡張機能を移行しません。AlloyDB for PostgreSQL でサポートされていないバージョンの拡張機能が移行元データベースに存在する場合、移行ジョブのテストまたは開始が失敗することがあります。スムーズに移行できるように、ソース拡張機能がサポートされていること、アプリケーションがサポートされていない拡張機能を参照していないことを確認します。サポートされている拡張機能の一覧については、AlloyDB for PostgreSQL のドキュメントの サポートされている拡張機能をご覧ください。

  • pg_cron 拡張機能（または拡張機能内で構成された cron ジョブ）は、Database Migration Service では移行されませんが、AlloyDB for PostgreSQL の移行先でサポートされています。移行元データベースで pg_cron を使用している場合は、移行の完了後に拡張機能を再インストールし、移行先クラスタで cron ジョブを構成します。

  • Database Migration Service は、リカバリモードのリードレプリカからの移行をサポートしていません。

  • Database Migration Service は、AWS SCT 拡張パックが適用されている Amazon RDS ソースをサポートしていません。

  • C で記述されたユーザー定義関数は、AlloyDB for PostgreSQL でサポートされている拡張機能の作成時にインストールされる関数を除き、移行できません。

  • 移行ジョブの開始後に移行元インスタンスに追加されたデータベースは移行されません。

  • Database Migration Service を使用して移行する際に、特定のデータベースを選択できます。選択したデータベースのすべてのテーブルとスキーマが移行されます。ただし、次のものは除きます。

    • 情報スキーマ（information_schema）。
    • pg_ で始まるスキーマ（pg_catalog、pg_toast、pgtemp* など）。pg_ で始まる PostgreSQL カタログの完全なリストについては、PostgreSQL ドキュメントの PostgreSQL システム カタログをご覧ください。
    • ユーザーのログイン認証情報とロール。

  • 暗号化されたデータベースでデータの復号に顧客管理の暗号鍵（CMEK）が必要であり、Database Migration Service がその鍵にアクセスできない場合、データベースを移行できません。ただし、AlloyDB for PostgreSQL は pgcrypto をサポートしているため、 pgcrypto 拡張機能で暗号化されたデータは移行できます。AWS は復号を透過的に処理するため、Database Migration Service は、暗号化された Amazon Aurora データベースまたは Amazon RDS データベースからの移行もサポートしています。詳細については、 Amazon Aurora リソースの暗号化と Amazon RDS リソースの暗号化をご覧ください。

  • 移行中のデータベースは書き込み保護されない: AlloyDB for PostgreSQL は、移行中に移行先インスタンスを読み取り専用モードで実行しません。移行先クラスタに接続してデータベース ユーザーを作成および管理したり、必要なスキーマ変更（DDL）を適用したりできますが、移行中のデータベースまたはテーブルに対して書き込みオペレーション（INSERT、UPDATE、DELETE など）を実行しないでください。移行中のデータに書き込むと、 レプリケーションの競合や移行の失敗が発生する可能性があります。

  • トリガーの動作はトリガーの構成によって異なります。デフォルトでは、ALTER EVENT TRIGGER または ALTER TABLE ... ENABLE ALWAYS TRIGGER で構成されていない限り、レプリケーション中にレプリカでトリガーは起動しません。

  • カスタム テーブルスペースは、AlloyDB for PostgreSQL のデフォルトの pg_default テーブルスペースにマッピングされます。

  • Private Service Connect インターフェースの接続方法は、既存の宛先クラスタへの移行でのみサポートされています。プライベート IP 接続を使用して、標準移行で新しい宛先クラスタに移行する場合は、VPC ピアリングを使用します。

  • 宛先クラスタの Identity and Access Management データベース認証はサポートされていません。Database Migration Service は、データベース ユーザー認証を使用して移行先データベースに接続します。IAM の詳細については、AlloyDB for PostgreSQL のドキュメントの IAM 認証を管理するをご覧ください。

セキュリティ定義関数

SECURITY DEFINER で定義された関数は、関数を実行するユーザーではなく、関数を所有するユーザーの権限で実行されます。

AlloyDB for PostgreSQL への継続的な移行中、SECURITY DEFINER で定義されたルーティンは、移行先のプライマリ インスタンスの内部移行サービス ユーザー alloydbexternalsync が所有するようになります。alloydbexternalsync には、alloydbsuperuser ロールや alloydbreplica ロールなどの昇格された管理者権限が付与されているため、これらの関数の実行を許可されたユーザーは、完全な alloydbsuperuser 権限で関数を実行します。これにより、意図しない権限昇格のリスクが生じます。

このリスクを修正するには、移行先クラスタのすべての SECURITY DEFINER 関数を監査し、移行直後にパブリック実行権限を取り消します。

REVOKE EXECUTE ON FUNCTION SCHEMA_NAME.FUNCTION_NAME(ARGUMENT_TYPES) FROM PUBLIC;
GRANT EXECUTE ON FUNCTION SCHEMA_NAME.FUNCTION_NAME(ARGUMENT_TYPES) TO "AUTHORIZED_USER";

照合とロケールのアライメント

AlloyDB for PostgreSQL のデフォルトは、libc が提供する C.UTF-8 ロケールと en_US.utf8 ロケールです。AlloyDB for PostgreSQL の他のすべてのロケールでは、International Components for Unicode（ICU）照合が使用されます。

移行元データベースが別の libc 言語 / 地域に基づくデフォルトの照合を使用している場合、そのデフォルトは自動的に引き継がれません。ORDER BY を使用するクエリで一貫した並べ替えを行うには、移行後に明示的な ICU 照合を使用してテーブルを更新する必要がある場合があります。詳細については、AlloyDB for PostgreSQL のドキュメントの インポートされたデータでサポートされているロケールをご覧ください。

既存の宛先クラスタへの移行に関する制限事項

  • 宛先クラスタごとに構成できるアクティブな移行ジョブは 1 つだけです。
  • 標準移行の移行先クラスタの降格: 既存の AlloyDB for PostgreSQL クラスタへの標準移行の場合、Database Migration Service はスタンドアロン クラスタを降格して、移行元データベースの外部レプリカとして構成します。
    • Google Cloud コンソールで移行ジョブを作成するときに、宛先クラスタ ID を入力して（または gcloud database-migration migration-jobs demote-destination を実行して）、降格を確認する必要があります。
    • クイック スタート移行では、PostgreSQL pgnative の論理レプリケーションが使用されます。移行先クラスタのデモートは必要ありません。
  • 標準移行の場合、既存の宛先クラスタは空であるか、デフォルトのシステム構成データのみが含まれている必要があります。標準移行では、ユーザーデータ（テーブルなど）を含む既存の移行先クラスタへの移行はサポートされていません。

    既存の移行先クラスタに余分なデータがあるために問題が発生した場合は、移行先クラスタのデータベースをクリアして、移行ジョブを再試行します。 既存の宛先クラスタから余分なデータを消去するをご覧ください。

  • 読み取りプール インスタンスを含むクラスタへの移行はサポートされています。AlloyDB for PostgreSQL のクラスタとインスタンスの詳細については、AlloyDB for PostgreSQL の概要をご覧ください。

データダンプの並列処理に関する考慮事項

移行ジョブを作成するときに、並列サブスクリプションの数を増やすことで、初期データダンプと継続的な変更データ キャプチャ（CDC）レプリケーションを高速化できます。データダンプの並列処理設定を高くすると、ソース データベースと移行先の AlloyDB for PostgreSQL クラスタの両方で接続とリソースの使用率も増加します。

  • 最大並列処理を使用する前に、移行元データベースに十分な CPU、メモリ、I/O のヘッドルームがあることを確認してください。
  • 調整されたデータダンプの並列処理を使用する場合は、ソース データベースで max_replication_slots、max_wal_senders、max_worker_processes に高い値を構成する必要があります。パラメータの計算の詳細については、ソース データベースを構成するをご覧ください。
  • pglogical 拡張機能は、最初の完全ダンプ時にテーブルレベルでデータを複製します。1 つのパーティション分割テーブルが 1 つのサブスクリプションに割り当てられ、複数の並列サブスクリプションまたはワーカー スレッドに分割されることはありません。
  • pglogical 拡張機能は、個々のリーフ パーティションを個別のテーブルとして複製し、最初の完全ダンプ中に複数のリーフ パーティションを並列サブスクリプションに分散できます。1 つの大きなリーフ パーティションを複数のサブスクリプションに分割することはできません。1 つのスレッドでコピーされます。
  • Database Migration Service は、テーブルをサイズで並べ替え、並列サブスクリプションに分散します。Database Migration Service は、最適な並列処理の場合はデータベースごとに最大 2 つのサブスクリプション（すべてのデータベースで合計最大 2 つ）、最大並列処理の場合はデータベースごとに最大 4 つのサブスクリプション（すべてのデータベースで合計最大 4 つ）を作成します。移行されたデータベースごとに少なくとも 1 つのサブスクリプションが作成されます。たとえば、データベースに 1 TB のテーブルが 1 つと、小さなテーブルがいくつかある場合、Database Migration Service は 1 TB のテーブルを 1 つのサブスクリプションに分離し、残りのサブスクリプションに小さなテーブルを分散します。複数のサブスクリプションがアクティブな場合でも、全体的な初期ダンプ速度は、1 TB のテーブルをコピーするのに必要な時間によって制限されます。
  • Database Migration Service は、主キーのないテーブルを専用の挿入専用レプリケーション セット（並列サブスクリプションごとに 1 つ）に割り当てます。主キーのない複数のテーブルを並列サブスクリプションに分散できますが、最初の完全ダンプでは、各テーブルが 1 つのサブスクリプション内で単一のテーブル ストリームとしてコピーされ、複数の並列スレッドに分割されることはありません。

割り当て

  • 同時に最大 2,000 個の接続プロファイルと 1,000 個の移行ジョブを維持できます。さらにスペースを確保するには、未使用の移行ジョブと接続プロファイルを削除します。詳細については、割り当てと上限をご覧ください。

メジャー バージョンのアップグレード中の PostgreSQL 拡張機能のバージョン互換性

PostgreSQL の上位のメジャー バージョンに移行する場合、Database Migration Service は pg_restore ユーティリティを使用します。このユーティリティは、ターゲットの PostgreSQL メジャー バージョンのデフォルトの拡張機能バージョンをインストールします。pg_restore ユーティリティに正確な拡張機能のバージョンを指定することはできません。

ソース データベースで、ターゲット PostgreSQL メジャー バージョンにインストールされているデフォルト バージョンとスキーマ互換性のない拡張機能バージョンを使用している場合、スキーマの不一致または内部エラーが原因で移行が失敗することがあります。

移行エラーを回避するには、スキーマの互換性を確認します。移行する前に、ソース データベースの拡張機能を、ターゲットの PostgreSQL メジャー バージョンと互換性のあるバージョンにアップグレードします。

次のステップ