ソースを構成する

MySQL   |  PostgreSQL   |  PostgreSQL から AlloyDB

概要

Database Migration Service は、移行元データベースから Cloud SQL 移行先データベースへの継続的な移行をサポートしています。

PostgreSQL でサポートされている移行元のデータベースには次のものが含まれます。

• Amazon RDS 9.6.10 以降、10.5 以降、11.1 以降、12、13、14、15、16、17、18。
• Amazon Aurora 10.11 以降、11.6 以降、12.4 以降、13.3 以降、14.6 以降、15.2 以降、16、17、18。
• セルフマネージド（オンプレミス、またはお客様が完全に管理するクラウド VM 上）の PostgreSQL 9.4、9.5、9.6、10、11、12、13、14、15、16、17、18。
• Cloud SQL for PostgreSQL 9.6、10、11、12、13、14、15、16、17、18。
• Microsoft Azure Database for PostgreSQL フレキシブル サーバー: 11 以降

移行元を構成するには、移行元インスタンスと基盤となる移行元データベースの両方を構成する必要があります。

移行元インスタンスを構成する

移行元インスタンスを構成する手順は次のとおりです。

1. 移行元が Cloud SQL の場合: プライベート IP 接続を使用する Cloud SQL インスタンスから、RFC 1918 以外のアドレス IP 範囲を使用する Cloud SQL インスタンスに移行する場合は、RFC 1918 以外の範囲を移行元 Cloud SQL インスタンスのネットワーク構成に追加します。 Cloud SQL ドキュメントの承認済みネットワークを構成する をご覧ください。
2. 移行元のインスタンスに postgres データベースが含まれている必要があります。このデータベースがない場合は、作成します。

3. 移行元インスタンスに pglogical パッケージをインストールし、 shared_preload_libraries 変数に含まれていることを確認します。環境の移行元インスタンスに パッケージをインストールするpglogicalをご覧ください。

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

5. `pg_cron` 拡張機能を使用する移行元の場合: `pg_cron` 拡張機能（または拡張機能に関連付けられた cron 設定）は Database Migration Service によって移行されませんが、Cloud SQL for PostgreSQL の移行先ではサポートされています。pg_cronpg_cron移行元データベースで pg_cron 拡張機能を使用している場合は、移行が完了した後に移行先インスタンスに再インストールできます。

移行元データベースを構成する

Database Migration Service は、次のデータベースを除き、移行元のインスタンス下にあるすべての データベースを移行します。

• 移行元がオンプレミスの PostgreSQL の場合: テンプレート データベース template0 と template1
• 移行元が Amazon RDS の場合: template0、template1、rdsadmin
• 移行元が Cloud SQL の場合: テンプレート データベース template0 と template1
• 移行元が Microsoft Azure の場合: azure_maintenance、azure_sys、template0、template1

上記以外の移行元のインスタンスで各データベース に次の操作を行います。

1. PostgreSQL バージョン 9.4 の移行元の場合のみ、移行元インスタンスの各データベースに次の pglogical 拡張機能をインストールします:

   • CREATE EXTENSION IF NOT EXISTS pglogical;
   • CREATE EXTENSION IF NOT EXISTS pglogical_origin;

2. 他のすべてのバージョン の場合は、移行元インスタンスの各データベースに pglogical 拡張機能のみをインストールします: CREATE EXTENSION IF NOT EXISTS pglogical。

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

   PostgreSQL データベース内で主キーのないテーブルを一覧表示するクエリを作成する方法については、デバッグとその他のツールをご覧ください。 主キーがなく、移行されないデータベースの一部ではないデータベース テーブルが見つかった場合は、テーブルを変更して主キーを追加するか、次のプロセスを行います。主キーのないテーブルの場合、最初のスナップショットと INSERT ステートメントのみが移行されます。

4. 移行元のインスタンスへの接続に使用する USER（Connection Profiles ページでユーザーとして構成）には、移行した各データベースとデフォルトの postgres データベースに対する一定の権限が必要です。新しいユーザーを作成することも、既存のユーザーを再利用することもできます。これらの権限を設定するには、インスタンスに接続して次のコマンドを実行します。

   1. GRANT USAGE on SCHEMA SCHEMA to USER 移行する各データベースのすべてのスキーマ（情報スキーマと「pg_」で始まるスキーマを除く）に対する。
   2. GRANT USAGE on SCHEMA pglogical to PUBLIC; : 移行する各データベースに対する。
   3. GRANT SELECT on ALL TABLES in SCHEMA pglogical to USER 移行元データベースからレプリケーション情報を取得するすべてのデータベースに対する。
   4. GRANT SELECT on ALL TABLES in SCHEMA SCHEMA to USER 移行する各データベースのすべてのスキーマ（情報スキーマと「pg_」で始まるスキーマを除く）に対する。
   5. GRANT SELECT on ALL SEQUENCES in SCHEMA SCHEMA to USER 移行する各データベースのすべてのスキーマ（情報スキーマと「pg_」で始まるスキーマを除く）に対する。
   6. 移行元が Amazon RDS の場合は、次のコマンドを実行します。
      1. GRANT rds_replication to USER
   7. 移行元が Amazon RDS でない場合は、次のコマンドを実行します。
      1. ALTER USER USER with REPLICATION ロール

移行元のインスタンスに pglogical パッケージをインストールする

このセクションでは、移行元インスタンスに応じて pglogical パッケージと適用可能なパラメータを構成する方法について説明します。

注: これらのパラメータの正しい値は、移行ジョブの作成時に 移行ジョブのテストを実行することで取得できます。 このテスト中に、Database Migration Service は設定を確認し、正しい値を提案します。

オンプレミスまたはセルフマネージド PostgreSQL

1. サーバーに pglogical パッケージをインストールする。
2. インスタンスに接続し、必要に応じて次のパラメータを設定します。

   • shared_preload_libraries に pglogical を含める必要があります。

     このパラメータを設定するには、ALTER SYSTEM SET shared_preload_libraries = 'pglogical,[any other libraries in your instance]'; コマンドを実行します。

     インスタンスの既存のライブラリを取得するには、show shared_preload_libraries コマンドを実行します。

   • wal_level を logical に設定します。

     このパラメータを設定するには、ALTER SYSTEM SET wal_level = 'logical'; コマンドを実行します。

   • wal_sender_timeout を 0 に設定します。

     このパラメータを設定するには、ALTER SYSTEM SET wal_sender_timeout = 0; コマンドを実行します。0 は、非アクティブなレプリケーション接続を終了するために使用するタイムアウト メカニズムを無効にします。

   • max_replication_slots では、移行元インスタンスでサポート可能なレプリケーションのスロット数を定義します。少なくとも、接続が予想されるサブスクリプションの数とテーブル同期用の予約分を合計した値を設定する必要があります。

     Database Migration Service では、移行されるデータベースごとに 1 つのスロットが必要です（移行元インスタンス下のすべてのデータベース）。

     たとえば、移行元インスタンスに 5 つのデータベースがあり、移行元に 2 つの移行ジョブが作成された場合、すでに使用されていたレプリケーション スロットの数以外に、5 × 2 = 10 以上のレプリケーション スロットが必要です。調整されたデータダンプの並列処理設定を使用する場合は、 レプリケーション スロットの数を増やし、 構成を 移行ジョブのテストを実行して移行ジョブの作成時に確認してください。

     このパラメータを設定するには、ALTER SYSTEM SET max_replication_slots = #; コマンドを実行します。# は、レプリケーション スロットの最大数を表します。

   • max_wal_senders には、少なくとも max_replication_slots と同じ値に、インスタンスですでに使用されている送信者の数を加えた値を設定します。

     たとえば、max_replication_slots パラメータが 10 に設定されていて、すでに 2 つの送信者を使用している場合、同時に実行される WAL 送信者プロセスの数は 10 + 2 = 12 になります。 調整されたデータダンプの並列処理設定を使用する場合は、 送信者の数を増やし、 構成を 移行ジョブのテストを実行して移行ジョブの作成時に確認してください。

     このパラメータを設定するには、ALTER SYSTEM SET max_wal_senders = #; コマンドを実行します。# は、同時に実行される WAL 送信者プロセスの数を表します。

   • max_worker_processes には、Database Migration Service が移行するデータベースの数（移行元インスタンス下のすべてのデータベース）に、インスタンスですでに使用されている max_worker_processes の数を加えた値を設定します。

     調整されたデータダンプの並列処理設定を使用する場合は、 ワーカー プロセスの数を増やし、 構成を確認するには、 移行ジョブのテストを実行します。移行ジョブを作成するときに

     このパラメータを設定するには、ALTER SYSTEM SET max_worker_processes = #; コマンドを実行します。# は、移行されるデータベースの数を表します。

   この手順で設定するパラメータは、実行中の PostgreSQL データベース サーバーに適用されます。次のコード行を postgresql.conf ファイルに追加して、これらの変更を永続的にすることもできます。

   • shared_preload_libraries = 'pglogical';
   • wal_level = 'logical';
   • wal_sender_timeout = 0;
   • max_replication_slots = #;
   • max_wal_senders = #;
   • max_worker_processes = #;
3. 構成の変更を適用するには、移行元インスタンスを再起動 します。

Microsoft Azure Database for PostgreSQL

Microsoft Azure Database for PostgreSQL の移行元を構成する手順は次のとおりです。

1. サーバーに pglogical パッケージ をインストールする。

2. PostgreSQL バージョン 9.4 の移行元の場合のみ 、移行元インスタンスの各データベースに次の pglogical 拡張機能をインストールします。

   • CREATE EXTENSION IF NOT EXISTS pglogical;
   • CREATE EXTENSION IF NOT EXISTS pglogical_origin;

3. 他のすべてのバージョン の場合は、移行元インスタンスの各データベースに pglogical 拡張機能をインストールします: CREATE EXTENSION IF NOT EXISTS pglogical。

4. Microsoft Azure ポータルを使用して、移行元に必要なサーバー パラメータを構成します。詳細については、Microsoft ドキュメントの Azure Database for PostgreSQL でサーバー パラメータを構成すると Azure Database for PostgreSQL のサーバー パラメータをご覧ください。

   次のパラメータを構成します。

   • shared_preload_libraries を設定して pglogical を含めます。
   • azure.extensions を設定して pglogical を含めます。
   • wal_level を logical に設定します。

   • max_replication_slots を、接続が予想されるサブスクリプションの数とテーブル同期用の予約分を合計した値以上に設定します。

     max_replication_slots パラメータは、移行元インスタンスがサポートできるレプリケーション スロットの最大数を定義します。

     Database Migration Service では、移行されるデータベースごとに 1 つのスロットが必要です（移行元インスタンス下のすべてのデータベース）。

     たとえば、移行元インスタンスに 5 つのデータベースがあり、移行元に 2 つの移行ジョブが作成された場合、すでに使用されていたレプリケーション スロットの数以外に、5 × 2 = 10 以上のレプリケーション スロットが必要です。調整されたデータダンプの並列処理設定を使用する場合は、 レプリケーション スロットの数を増やし、 構成を 移行ジョブのテストを実行して移行ジョブの作成時に確認してください。

   • max_wal_senders を、max_replication_slots と同じ値に、インスタンスですでに使用されている送信者の数を加えた値以上に設定します。

     たとえば、max_replication_slots パラメータが 10 に設定されていて、すでに 2 つの送信者を使用している場合、同時に実行される WAL 送信者プロセスの数は 10 + 2 = 12 になります。

     調整されたデータダンプの並列処理設定を使用する場合は、 送信者の数を増やし、 構成を 移行ジョブのテストを実行して移行ジョブの作成時に確認してください。

   • max_worker_processes には、Database Migration Service が移行するデータベースの数（移行元インスタンス下のすべてのデータベース）に、インスタンスですでに使用されている max_worker_processes の数を加えた値を設定します。

     調整されたデータダンプの並列処理設定を使用する場合は、 ワーカー プロセスの数を増やし、 構成を確認するには、 移行ジョブのテストを実行します。移行ジョブを作成するときに

5. require_secure_transport 設定の値を確認します。

   デフォルトでは、Microsoft Azure データベースでは、すべての受信接続に SSL/TLS 暗号化が必要です。require_secure_transport の値に応じて、移行元接続プロファイルの作成時に次のいずれかの暗号化設定を使用します。

   • `require_secure_transport` が `on` に設定されている場合は、[Basic]、[TLS]、または [mTLS] を選択します。
   • require_secure_transport が off に設定されている場合は、[None] を選択します。
6. 構成の変更を適用するには、移行元インスタンスを再起動 します。

Amazon RDS PostgreSQL

1. 移行元データベースに pglogical 拡張機能をインストールします。

   詳細については、Amazon RDS ドキュメントの Amazon RDS for PostgreSQL で PostgreSQL 拡張機能を使用するをご覧ください。

2. パラメータ グループを使用して移行元インスタンスを構成します。

   1. 新しいパラメータ グループを作成します。パラメータ グループで次の操作を行います。
   • shared_preload_libraries パラメータに pglogical が含まれていることを確認します。
   • rds.logical_replication パラメータを 1 に設定します。これにより、WAL ログが「論理」レベルで有効になります。
   • wal_sender_timeout パラメータを 0 に設定します。これにより、非アクティブなレプリケーション接続を終了するために使用するタイムアウト メカニズムが無効になります。

   • max_replication_slots パラメータを設定します。このパラメータは、移行元インスタンスがサポートできるレプリケーション スロットの最大数を定義します。少なくとも、接続が予想されるサブスクリプションの数とテーブル同期用の予約分を合計した値を設定する必要があります。

     Database Migration Service では、移行されるデータベースごとに 1 つのスロットが必要です（移行元インスタンス下のすべてのデータベース）。

     たとえば、移行元インスタンスに 5 つのデータベースがあり、移行元に 2 つの移行ジョブが作成された場合、すでに使用されていたレプリケーション スロットの数以外に、5 × 2 = 10 以上のレプリケーション スロットが必要です。調整されたデータダンプの並列処理設定を使用する場合は、 レプリケーション スロットの数を増やし、 移行ジョブの作成時に 移行ジョブのテストを実行して構成を確認してください。

     このパラメータのデフォルト値は 10 です。

   • max_wal_senders パラメータを、max_replication_slots と同じ値に、インスタンスですでに使用されている送信者の数を加えた値以上に設定します。

     たとえば、max_replication_slots パラメータが 10 に設定されていて、すでに 2 つの送信者を使用している場合、同時に実行される WAL 送信者プロセスの数は 10 + 2 = 12 になります。 調整されたデータダンプの並列処理設定を使用する場合は、 送信者の数を増やし、 移行ジョブの作成時に 移行ジョブのテストを実行して構成を確認してください。

     このパラメータのデフォルト値は 10 です。

   • max_worker_processes パラメータを、Database Migration Service が移行するデータベースの数（移行元インスタンス下のすべてのデータベース）に、インスタンスですでに使用されている max_worker_processes の数を加えた値以上に設定します。調整されたデータダンプの並列処理設定を使用する場合は、 ワーカー プロセスの数を増やし、 移行ジョブの作成時に 移行ジョブのテストを実行して構成を確認してください。

     このパラメータのデフォルト値は 8 です。

   2. パラメータ グループをインスタンスにアタッチします。新しいインスタンスを作成する場合は、[追加構成] でこのオプションを確認できます。

      それ以外の場合は、インスタンスを変更してパラメータ グループをアタッチします。

3. 構成の変更を適用するには、移行元インスタンスを再起動 します。

注: pglogical 拡張機能は、移行元インスタンスの認証情報をログに書式なしテキストで記録できます。この動作は拡張機能自体によって行われ、Database Migration Service や Cloud SQL とは関係ありません。

Cloud SQL for PostgreSQL

次のフラグを構成して、移行元データベースの論理レプリケーションとデコードを有効にします。

このセクションのすべての設定は、Cloud SQL のフラグを使用して構成されます。 Cloud SQL でフラグを有効にするには、 データベース フラグの構成をご覧ください。

1. cloudsql.logical_decoding フラグと cloudsql.enable_pglogical フラグを on に設定します。

2. max_replication_slots フラグを設定します。このフラグは、移行元インスタンスがサポートできるレプリケーション スロットの最大数を定義します。少なくとも、接続が予想されるサブスクリプションの数とテーブル同期用の予約分を合計した値を設定する必要があります。

   Database Migration Service では、移行されるデータベースごとに 1 つのスロットが必要です（移行元インスタンス下のすべてのデータベース）。

   たとえば、移行元インスタンスに 5 つのデータベースがあり、移行元に 2 つの移行ジョブが作成された場合、すでに使用されていたレプリケーション スロットの数以外に、5 × 2 = 10 以上のレプリケーション スロットが必要です。調整されたデータダンプの並列処理設定を使用する場合は、 レプリケーション スロットの数を増やし、 構成を 移行ジョブのテストを実行して移行ジョブの作成時に確認してください。

   このフラグのデフォルト値は 10 です。

3. max_wal_senders フラグを、max_replication_slots と同じ値に、インスタンスですでに使用されている送信者の数を加えた値以上に設定します。

   たとえば、max_replication_slots フラグが 10 に設定されていて、すでに 2 つの送信者を使用している場合、同時に実行される WAL 送信者プロセスの数は 10 + 2 = 12 になります。 調整されたデータダンプの並列処理設定を使用する場合は、 送信者の数を増やし、 移行ジョブの作成時に 移行ジョブのテストを実行して構成を確認してください。

   このフラグのデフォルト値は 10 です。

4. max_worker_processes 移行元フラグを、Database Migration Service が移行するデータベースの数（移行元インスタンス下のすべてのデータベース）に、インスタンスですでに使用されている max_worker_processes の数を加えた値以上に設定します。調整されたデータダンプの並列処理 設定を使用する場合は、ワーカー プロセスの数を増やし、 構成を 移行ジョブのテストを実行して確認 してください。

   このフラグのデフォルト値は 8 です。

5. wal_sender_timeout パラメータを 0 に設定します。 0 値は、非アクティブなレプリケーション接続を終了するタイムアウト メカニズムを無効にします。

6. 移行元インスタンスを再起動して、フラグに対して行った構成の変更 が有効になるようにします。

9.6 より前のバージョンの PostgreSQL でレプリケーションの遅延モニタリングを有効にする

9.6 より前の PostgreSQL バージョンから移行する場合、デフォルトではレプリケーション遅延の指標を使用できません。この指標を追跡して、データベースをプロモートする際のダウンタイムを最小限に抑えるには、次の方法があります。

• オプション 1: 特定のクエリへのアクセス権を付与することで、Database Migration Service がレプリケーション の遅延を追跡できるようにします。SUPERUSER 権限を持つユーザーを使用して、次の操作を行います。

  1. 次の関数を定義して、Database Migration Service がレプリケーションの遅延をクエリできるようにします。

     CREATE OR REPLACE FUNCTION pg_stat_replication_user()
     RETURNS TABLE (
     pid               integer                  ,
     usesysid          oid                      ,
     username          name                    ,
     application_name  text                     ,
     client_addr       inet                     ,
     client_hostname   text                     ,
     client_port       integer                  ,
     backend_start     timestamp with time zone ,
     backend_xmin      xid                      ,
     state             text                     ,
     sent_location     pg_lsn                   ,
     write_location    pg_lsn                   ,
     flush_location    pg_lsn                   ,
     replay_location   pg_lsn                   ,
     sync_priority     integer                  ,
     sync_state        text
     )
     LANGUAGE SQL
     SECURITY DEFINER
     AS $$
      SELECT *
      FROM pg_catalog.pg_stat_replication;
     $$;
     

  2. 次のコマンドを実行して、USER に EXECUTE 権限を付与します。

     1. REVOKE EXECUTE ON FUNCTION pg_stat_replication_user() FROM public;
     2. GRANT EXECUTE ON FUNCTION pg_stat_replication_user() to {replication_user};

• オプション 2: 移行元インスタンスへの接続に使用する USER に直接 SUPERUSER 権限を付与します。これにより、Database Migration Service がレプリケーションの遅延を直接読み取ることができます。

• オプション 3: 次のクエリを使用して、レプリケーションの遅延を個別に追跡します。

  10 より前のバージョンの PostgreSQL の場合は、このコマンドを superuser として実行します。

      SELECT current_timestamp, application_name,
      pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.sent_location) AS sent_location_lag,
      pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.write_location) AS write_location_lag,
      pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.flush_location) AS flush_location_lag,
      pg_xlog_location_diff(pg_current_xlog_location(), pg_stat_replication.replay_location) AS replay_location_lag
      FROM pg_stat_replication
      WHERE application_name like 'cloudsql%';
    

  この方法では、Database Migration Service はグラフや API レスポンスにレプリケーション遅延の指標を反映しません。