移行の忠実性

MySQL   |  PostgreSQL   |  PostgreSQL から AlloyDB

概要

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

移行プロセスでは、データと制約が別々に移行されます。 データが最初に移行され、最初の完全ダンプとロードの後に、主キー、外部キー、インデックスなどの制約がインスタンス上に再作成されます。

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

データ

• 次のスキーマを除く、すべてのデータベースとスキーマのすべてのテーブル:

  • 情報スキーマ information_schema
  • pg で始まるスキーマ（pg_catalog など）

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

スキーマ

• 命名

• 主キー

• データ型

• 序数位置

• デフォルト値

• null 可能性

• 自動増分属性

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

メタデータ

• ストアド プロシージャ

• 関数

• トリガー

• ビュー

• 外部キー制約

継続的な移行

継続的な移行では、データ操作言語（DML）の変更のみが自動的に更新されます。移行元と移行先のデータベースの互換性を保つようにデータ定義言語（DDL）の変更を管理する作業は、ユーザーが行う必要があり、次の 2 つの方法があります。

1. 移行元への書き込みを停止し、移行元と移行先の両方で DDL コマンドを実行します。 移行先で DDL コマンドを実行する前に、DDL 変更を適用する Cloud SQL のユーザーに cloudsqlexternalsyncを付与します。データのクエリや変更を有効にするには、該当する Cloud SQL ユーザーに cloudsqlexternalsync ロールを付与します。
2. pglogical.replicate_ddl_command を使用して、移行元と移行先の一貫したポイントで DDL を実行できるようにします。このコマンドを実行するユーザーは、移行元と移行先で同じユーザー名を持ち、移行するアーティファクト（テーブル、シーケンス、ビュー、データベースなど）のスーパーユーザーまたはオーナーである必要があります。

   pglogical.replicate_ddl_command の使用例をいくつか示します。

   次のように置き換えます。

   • [SCHEMA] は、使用するテーブル スキーマの名前に置き換えます。
   • [TABLE_NAME] は、テーブル名に置き換えます。
   • [NEW_NAME_FOR_TABLE] は、名前変更オペレーションを実行する際のテーブルの新しい名前に置き換えます。

   主キーを持つデータベース テーブルに列を追加する

   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] 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}'
   );

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

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

   主キーを持つデータベース テーブルを作成する

   次のコマンドを実行します。

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

   2. select pglogical.replication_set_add_table('default', '[SCHEMA].[TABLE_NAME]');

   主キーのないデータベース テーブルを作成する

   次のコマンドを実行します。

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

   2. select pglogical.replication_set_add_table(
        'default_insert_only', '[SCHEMA].[TABLE_NAME]'
      );

移行されないもの

• 移行先の Cloud SQL インスタンスにユーザーを追加するには、インスタンスに移動して [ユーザー] タブからユーザーを追加するか、PostgreSQL クライアントから追加します。PostgreSQL ユーザーの作成 と管理の詳細をご覧ください。

• Database Migration Service は、Cloud SQL でサポートされていない拡張機能を移行しません 。これらの拡張機能が存在しても移行はブロックされませんが、スムーズな移行プロセスを確保するため、オブジェクトまたはアプリケーションがサポートされていない拡張機能を参照していないことを確認してください。続行する前に、移行元データベースからこれらの拡張機能と参照を削除することをおすすめします。

• 大きなオブジェクト はレプリケートできません。PostgreSQL の論理デコード機能では、大きなオブジェクトの変更のデコードがサポートされていないためです。 大きなオブジェクトを参照する列タイプ oid を持つテーブルの場合、行は同期され、新しい行がレプリケートされます。 ただし、移行先データベースで大きなオブジェクトにアクセスしようとすると （lo_getを使用して読み取る、 lo_exportを使用してエクスポートする、 または指定された oidのカタログpg_largeobjectを確認する）、大きなオブジェクトが存在しないというメッセージが表示されて失敗します。

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

• Database Migration Service は、マテリアライズド ビューからデータを移行せず、ビュー スキーマのみを移行します。ビューにデータを入力するには、REFRESH MATERIALIZED VIEW view_name コマンドを実行します。

• 新しい移行先の SEQUENCE 状態（last_value など）は、移行元の SEQUENCE 状態と異なる場合があります。

• カスタマイズされたテーブルスペースは、移行先の Cloud SQL インスタンスではサポートされていません。カスタマイズされたテーブルスペース内のすべてのデータは、Cloud SQL のデフォルトの pg_default テーブルスペースに移行されます。