ソースを構成する

MySQL   |  PostgreSQL   |  PostgreSQL から 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. 環境に応じて、移行元インスタンスに Install the pglogical package on the source instance をインストールするをご覧ください。

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

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. 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 パッケージをインストールする

このセクションでは、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. 次のコマンドを実行して、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%';
     

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