ソースを構成する

MySQL   |  PostgreSQL   |  PostgreSQL to AlloyDB

概要

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

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

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

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

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

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

1. 移行元のインスタンスに postgres データベースが含まれている必要があります。このデータベースがない場合は作成します。
2. 移行元インスタンスに pglogical パッケージをインストールし、shared_preload_libraries 変数に含まれていることを確認します。
   1. 環境については、移行元インスタンスに pglogical パッケージをインストールするをご覧ください。

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

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

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

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

このセクションでは、max_replication_slots、max_wal_senders、max_worker_processes パラメータの設定など、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. 構成の変更を適用するには、移行元インスタンスを再起動します。

Amazon RDS PostgreSQL

1. 移行元データベースに pglogical 拡張機能をインストールします。詳細については、Amazon RDS ドキュメントの Amazon RDS for PostgreSQL での PostgreSQL 拡張機能の使用をご覧ください。

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

   • 新しいパラメータ グループを作成します。パラメータ グループで次の操作を行います。
   • 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 です。

3. パラメータ グループをインスタンスにアタッチします。新しいインスタンスを作成する場合は、[追加の構成] でこのオプションを確認できます。それ以外の場合は、インスタンスを変更してパラメータ グループを関連付けます。

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

注: 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 の数の合計以上に設定します。調整されたデータダンプの並列処理設定を使用する場合は、接続ごとに 2 つの追加のワーカー プロセス（最大 20 個のワーカー）を考慮してください。

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

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

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

9.6 より前の PostgreSQL バージョンから移行する場合、デフォルトではレプリケーション遅延の指標を使用できません。データベースをプロモートする際のダウンタイムを最小限にするために、この指標を追跡できるようにする代替手段が 3 つあります。

1. オプション 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. 次のコマンドを実行して、EXECUTE 権限を USER に付与します。

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

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

3. オプション 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%';
     

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