ソースを構成する

MySQL   |  PostgreSQL   |  PostgreSQL to AlloyDB

概要

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

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

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

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

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

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

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. 他のすべてのバージョンの場合は、移行元インスタンスの各データベース（CREATE EXTENSION IF NOT EXISTS pglogical）に pglogical 拡張機能のみをインストールします。

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

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

4. 移行元インスタンスへの接続に使用する USER（[接続プロファイル] ページでユーザーとして構成）には、移行した各データベースとデフォルトの 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. 移行元データベースに pglogical 拡張機能をインストールします。詳細については、Amazon RDS ドキュメントの Amazon RDS for PostgreSQL で PostgreSQL 拡張機能を使用するをご覧ください。

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

   • 新しいパラメータ グループを作成します。パラメータ グループで、次のように設定します。
   • 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 です。

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

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

注: 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 バージョンから移行する場合、デフォルトではレプリケーション遅延の指標を使用できません。この指標は、次のいずれかの方法で追跡できます。これにより、データベースを昇格する際のダウンタイムを最小限に抑えることができます。

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. 次のコマンドを実行して、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. オプション 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 レスポンスにレプリケーション遅延の指標が反映されません。