移行の忠実性

スキーマ、データ、メタデータを移行元データベースから移行先データベースに移行する場合は、すべての情報が正確に移行されるようにする必要があります。Database Migration Service は、データベース オブジェクト（スキーマ、データ、メタデータなど）を PostgreSQL データベース間で移行するための高忠実度のメカニズムを提供します。

移行プロセスでは、データと制約が構造化されたフェーズで移行されます。データは最初のスナップショット読み込み時に最初に移行され、主キー、外部キー、インデックスなどの制約は、初期読み込みが完了した後に移行先インスタンスに再作成されます。

データベース移行の一環として、以下のデータ、スキーマ、メタデータ コンポーネントが移行されます。

データ

  • 移行対象として選択されたデータベースのすべてのテーブルとスキーマ。ただし、次のシステム スキーマは除きます。

    • 情報スキーマ（information_schema）
    • pg_ で始まるスキーマ（例: pg_catalog、pg_toast）

    これらのシステム スキーマの詳細については、既知の制限事項をご覧ください。

    移行の進行中に、移行ジョブにデータベースを追加したり、移行ジョブからデータベースを削除したりできます。データベースを削除すると、移行先インスタンスで移行済みのデータベースを削除することなく、そのデータベースのレプリケーションが停止します。詳細については、移行ジョブを編集するをご覧ください。

スキーマ

  • オブジェクトの命名

  • 主キー

  • データ型

  • 列の順序位置

  • デフォルト値

  • null 可能性

  • ID 属性とシリアル属性

  • セカンダリ インデックス

メタデータ

  • ストアド プロシージャ

  • 関数

  • トリガー

  • ビュー

  • 外部キー制約

継続的な移行

データ操作言語（DML）の変更（主キーまたはレプリカ ID を持つテーブルに対する INSERT、UPDATE、DELETE オペレーションなど）は、継続的な移行中に自動的に複製されます。

移行プロセス中にソース データベースでデータ定義言語（DDL）の変更があった場合は、データベースの互換性を維持するために、移行先インスタンスを更新する必要があります。DDL の変更は、次の方法で行うことができます。

  1. 手動 DDL 実行: 移行元データベースへの書き込みを停止し、移行元データベースで DDL コマンドを実行して、移行先データベースで一致する DDL コマンドを実行します。宛先で DDL コマンドを実行する前に、変更を適用する Cloud SQL ユーザーに cloudsqlexternalsync ロールを付与します。

  2. pglogical を使用したレプリケートされた DDL コマンド: pglogical.replicate_ddl_command を使用すると、レプリケーション ストリームの一貫したポイントで、ソース データベースと宛先データベースの両方で DDL を実行できます。このコマンドを実行するユーザーは、移行元インスタンスと移行先インスタンスの両方で一致する認証情報を持っている必要があります。また、スーパーユーザーまたは変更されたオブジェクトのオーナーである必要があります。

次のタブでは、pglogical.replicate_ddl_command を使用した一般的な DDL オペレーションの SQL コマンドの例を示します。

主キーを含むテーブル

主キーを含むテーブルに列を追加する

SELECT pglogical.replicate_ddl_command(
  'ALTER TABLE [SCHEMA].[TABLE_NAME] ADD COLUMN surname varchar(20)',
  '{default}'
);

主キーを持つテーブルの名前を変更する

SELECT pglogical.replicate_ddl_command(
  'ALTER TABLE [SCHEMA].[TABLE_NAME] RENAME TO [NEW_NAME_FOR_TABLE]',
  '{default}'
);

主キーを含むテーブルを作成する

ソース データベースで次のコマンドを実行します。

SELECT pglogical.replicate_ddl_command(
  command := 'CREATE TABLE [SCHEMA].[TABLE_NAME] (id INTEGER PRIMARY KEY, name VARCHAR);',
  replication_sets := ARRAY['default']
);
SELECT pglogical.replication_set_add_table('default', '[SCHEMA].[TABLE_NAME]');

主キーのないテーブル

主キーのないテーブルに列を追加する

SELECT pglogical.replicate_ddl_command(
  'ALTER TABLE [SCHEMA].[TABLE_NAME] ADD COLUMN surname varchar(20)',
  '{default_insert_only}'
);

主キーのないテーブルの名前を変更する

SELECT pglogical.replicate_ddl_command(
  'ALTER TABLE [SCHEMA].[TABLE_NAME] RENAME TO [NEW_NAME_FOR_TABLE]',
  '{default_insert_only}'
);

主キーのないテーブルを作成する

ソース データベースで次のコマンドを実行します。

SELECT pglogical.replicate_ddl_command(
  command := 'CREATE TABLE [SCHEMA].[TABLE_NAME] (id INTEGER PRIMARY KEY, name VARCHAR);',
  replication_sets := ARRAY['default_insert_only']
);
SELECT pglogical.replication_set_add_table('default_insert_only', '[SCHEMA].[TABLE_NAME]');

移行されないデータ

  • ユーザーと権限: ユーザーのログイン認証情報とロールは移行されません。移行先インスタンスでユーザーを構成するには、 Google Cloud コンソールの [ユーザー] タブを使用するか、SQL クライアントを使用してユーザーを管理します。詳細については、Cloud SQL ドキュメントの ユーザーの作成と管理をご覧ください。

  • サポートされていない拡張機能: Database Migration Service は、Cloud SQL でサポートされていない拡張機能を移行しません。これらの拡張機能が存在しても移行ジョブはブロックされませんが、サポートされていない拡張機能を参照するアプリケーションでエラーが発生する可能性があります。サポートされている拡張機能の一覧については、Cloud SQL ドキュメントの PostgreSQL 拡張機能をご覧ください。

  • ラージ オブジェクト: PostgreSQL ラージ オブジェクト（pg_largeobject を参照するデータ型 oid）は、論理デコードによって複製されません。

  • 主キーのないテーブル: Database Migration Service は、初期スナップショットを移行し、CDC フェーズで INSERT ステートメントを複製します。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 では、宛先インスタンスのシーケンス（last_value など）の現在の値がソースと異なる場合があります。シーケンス値は、最終プロモーション ステップ中に同期されます。

  • カスタム テーブルスペース: Cloud SQL はカスタム テーブルスペースをサポートしていません。カスタム テーブルスペースで定義されたオブジェクトは、Cloud SQL のデフォルトの pg_default テーブルスペースに自動的に再マッピングされます。

次のステップ