データベースを Cloud SQL に移行する前に、この移行シナリオの既知の制限事項を考慮してください。
PostgreSQL データベースを移行元として使用する場合の既知の制限事項は次のとおりです。
pglogical拡張機能は、PostgreSQL 12 以降の 生成列のレプリケーションをサポートしていません。テーブル構造(DDL)の変更は、標準の DDL コマンドではレプリケートされません。レプリケーションに使用される
pglogical拡張機能を使用して実行されるコマンドでのみレプリケートされます。これには、enum型の変更が含まれます。- たとえば、
pglogicalにはpglogical.replicate_ddl_command関数が用意されており、DDL をソース データベースとレプリカの両方で一貫したポイントで実行できます。 - 新しく作成されたテーブルのデータを複製するには、
pglogical.replication_set_add_tableコマンドを使用して、既存のレプリケーション セットに新しいテーブルを追加する必要があります。 - 移行中の DDL レプリケーションの詳細については、移行の忠実度をご覧ください。
- たとえば、
主キーがないテーブルの場合、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 のドキュメントと クイックスタート移行ガイドをご覧ください。
- 標準移行: 主キーのないテーブルの場合、
Database Migration Service は、マテリアライズド ビューからデータを移行しません。ビューのスキーマのみを移行します。宛先データベースのビューにデータを入力するには、
REFRESH MATERIALIZED VIEW view_nameを実行します。CDC の進行中に、宛先の
SEQUENCE状態(last_valueなど)がソースと異なる場合があります。シーケンス値は、最終プロモーション ステップで同期されます。UNLOGGEDテーブルとTEMPORARYテーブルは複製されず、複製できません。ラージ オブジェクト データ型(
pg_largeobjectを参照するoid)は、PostgreSQL の論理デコードではサポートされていません。移行できるのは、Cloud SQL for PostgreSQL でサポートされている拡張機能のみです。Database Migration Service は、Cloud SQL でサポートされていない拡張機能を移行しません。これらの拡張機能が存在しても移行はブロックされませんが、スムーズに移行できるように、アプリケーションがサポートされていない拡張機能を参照していないことを確認してください。サポートされている拡張機能の一覧については、Cloud SQL ドキュメントの PostgreSQL 拡張機能をご覧ください。
pg_cron拡張機能(または拡張機能内で構成された cron ジョブ)は、Database Migration Service では移行されませんが、Cloud SQL for PostgreSQL の移行先でサポートされています。ソース データベースでpg_cronを使用している場合は、移行の完了後に拡張機能を再インストールし、移行先インスタンスで cron ジョブを構成します。Database Migration Service は、リカバリモードのリードレプリカからの移行をサポートしていません。
Database Migration Service は、AWS SCT 拡張パックが適用されている Amazon RDS ソースをサポートしていません。
C で記述されたユーザー定義関数は移行できません。ただし、Cloud SQL でサポートされている拡張機能の作成時にインストールされる関数は除きます。
移行元データベースに他の拡張機能が存在し、そのバージョンが Cloud SQL でサポートされていない場合、移行ジョブのテストまたは開始は失敗します。
移行ジョブの開始後に移行元インスタンスに追加されたデータベースは移行されません。
Database Migration Service を使用して移行する際に、特定のデータベースを選択できます。選択したデータベースのすべてのテーブルとスキーマが移行されます。ただし、次のものは除きます。
- 情報スキーマ(
information_schema)。 pg_で始まるスキーマ(pg_catalog、pg_toast、pgtemp*など)。pg_で始まる PostgreSQL カタログの完全なリストについては、PostgreSQL ドキュメントの PostgreSQL システム カタログをご覧ください。- ユーザーのログイン認証情報とロール。
- 情報スキーマ(
暗号化されたデータベースでデータの復号に顧客管理の暗号鍵(CMEK)が必要であり、Database Migration Service がその鍵にアクセスできない場合、データベースを移行できません。ただし、Cloud SQL は
pgcryptoをサポートしているため、pgcrypto拡張機能で暗号化されたデータは移行できます。AWS は復号を透過的に処理するため、Database Migration Service は暗号化された Amazon Aurora データベースまたは Amazon RDS データベースからの移行もサポートしています。詳細については、 Amazon Aurora リソースの暗号化と Amazon RDS リソースの暗号化をご覧ください。移行中の移行先データベースの運用動作:
書き込み可能な移行先データベース: Cloud SQL for PostgreSQL は、移行中に移行先データベースを読み取り専用モードで実行しません。Database Migration Service によって作成された移行先インスタンスは降格されません。
移行中のデータに対する書き込みオペレーションを回避する: 移行対象のテーブルまたはデータベースに対して書き込みオペレーション(
INSERT、UPDATE、DELETE、DDL スキーマの変更など)を実行しないでください。移行中のデータに対して書き込みを実行すると、受信する変更データ キャプチャ(CDC)ストリームとのレプリケーション競合が発生する可能性があります。データベース ユーザーを管理する: 標準の
psqlコマンドを使用するか、 Google Cloud コンソールの Cloud SQL を使用して、いつでもデータベース ユーザーを作成して管理できます。詳細については、Cloud SQL ドキュメントのユーザーを管理するをご覧ください。一時停止される機能: 継続的なレプリケーション中は、自動バックアップとポイントインタイム リカバリ(PITR)が一時停止されます。また、移行ジョブがプロモートされるまで、移行先インスタンスから Cloud SQL リードレプリカを作成することはできません。
トリガーの動作はトリガーの構成によって異なります。デフォルトでは、
ALTER EVENT TRIGGERまたはALTER TABLE ... ENABLE ALWAYS TRIGGERで構成されていない限り、レプリケーション中にレプリカでトリガーは起動しません。SECURITY DEFINERで定義された関数は、移行先の Cloud SQL インスタンスでcloudsqlexternalsyncによって作成されます。このインスタンスには権限昇格が保持されます。公開権限を取り消し、アクセス権を選択的に付与することで、機密性の高いSECURITY DEFINER関数に対する実行権限を制限します。Cloud SQL はカスタム テーブルスペースをサポートしていません。カスタム テーブルスペース内のすべてのオブジェクトは、Cloud SQL のデフォルトの
pg_defaultテーブルスペースに移行されます。Private Service Connect インターフェースの接続方法は、既存の移行先インスタンスへの移行でのみサポートされています。プライベート IP 接続を使用して新しい移行先インスタンスに移行する場合は、VPC ピアリングを使用します。
既存の移行先インスタンスへの移行に関する制限事項
- 標準移行の移行先インスタンスの降格: 既存の Cloud SQL インスタンスへの標準移行の場合、Database Migration Service はスタンドアロン インスタンスを降格して、移行元データベースの外部レプリカとして構成します。
- インスタンスを降格しても、PostgreSQL エンジンは読み取り専用モードになりませんが、レプリケーションの競合を防ぐために、移行中のテーブルに対する書き込みオペレーションは避ける必要があります。
- インスタンスを降格すると、自動バックアップとポイントインタイム リカバリ(PITR)が一時停止し、昇格するまで Cloud SQL リードレプリカを追加できなくなります。
- Google Cloud コンソールで移行ジョブを作成するときに、宛先インスタンス ID を入力して(または
gcloud database-migration migration-jobs demote-destinationを実行して)、降格を確認する必要があります。 -
クイック スタート移行では、PostgreSQL
pgnativeの論理レプリケーションが使用されます。移行先インスタンスの降格は必要ありません。
- 既存の移行先インスタンスに含めることができるのは、移行先インスタンスの作成時に自動的に設定されるデフォルトのシステム データベースのみです。ユーザーデータを含む既存の移行先インスタンスへの移行はサポートされていません。
既存の移行先インスタンスに余分なデータがあるために問題が発生した場合は、移行先インスタンスのデータベースを消去して、移行ジョブを再試行します。 既存の宛先インスタンスから余分なデータを消去するをご覧ください。
- 移行先インスタンスごとに構成できる移行ジョブは 1 つだけです。
- 移行できるのは、スタンドアロンの Cloud SQL インスタンスのみです。 外部サーバー レプリカへの移行はサポートされていません。
- インスタンスをプロモートした後、ポイントインタイム リカバリを有効にする必要があります。
- インスタンスのバックアップ設定がカスタマイズされている場合( カスタム バックアップ ロケーションなど)は、プロモート後にバックアップ設定を再度復元する必要があります。プロモーション プロセス中に、Cloud SQL はバックアップ設定をデフォルト値にリセットします。
- Terraform ユーザーの場合: Database Migration Service は、移行先インスタンスのバックアップと復元の設定を変更します。これにより、宛先インスタンスの設定が、プロビジョニングに使用される Terraform 構成と異なる場合があります。この問題が発生した場合は、 問題の診断のガイダンスをご覧ください。
割り当て
- 同時に最大 2,000 個の接続プロファイルと 1,000 個の移行ジョブを維持できます。さらに作成するには、未使用の移行ジョブと接続プロファイルを削除してください。
メジャー バージョンのアップグレード中の PostgreSQL 拡張機能のバージョン互換性
PostgreSQL の上位のメジャー バージョンに移行する場合、Database Migration Service は pg_restore ユーティリティを使用します。このユーティリティは、ターゲット PostgreSQL メジャー バージョンのデフォルトの拡張機能バージョンをインストールします。pg_restore ユーティリティに正確な拡張機能のバージョンを指定することはできません。
ソース データベースで、ターゲット PostgreSQL メジャー バージョンにインストールされているデフォルト バージョンとスキーマ互換性のない拡張機能バージョンを使用している場合、スキーマの不一致または内部エラーが原因で移行が失敗することがあります。
移行エラーを回避するには、スキーマの互換性を確認します。移行する前に、ソース データベースの拡張機能を、ターゲットの PostgreSQL メジャー バージョンと互換性のあるバージョンにアップグレードします。