このページは Cloud Translation API によって翻訳されました。

ソースを構成する

MySQL | PostgreSQL | PostgreSQL to AlloyDB

概要

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

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.6 以降、15.2 以降、16、17。
セルフマネージド（オンプレミス、またはお客様が完全に管理するクラウド VM 上）の PostgreSQL 9.4、9.5、9.6、10、11、12、13、14、15、16、17。
Cloud SQL for PostgreSQL 9.6、10、11、12、13、14、15、16、17。
Microsoft Azure Database for PostgreSQL フレキシブルサーバー: 11 以降

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

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

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

Cloud SQL ソースの場合: プライベート IP 接続を使用する Cloud SQL インスタンスから、RFC 1918 以外の IP アドレス範囲を使用する Cloud SQL インスタンスに移行する場合は、RFC 1918 以外の範囲を移行元 Cloud SQL インスタンスのネットワーク構成に追加します。Cloud SQL ドキュメントの承認済みネットワークを構成するをご覧ください。
移行元のインスタンスに postgres データベースが含まれている必要があります。このデータベースがない場合は作成します。
移行元インスタンスに pglogical パッケージをインストールし、 shared_preload_libraries 変数に含まれていることを確認します。環境については、移行元インスタンスに pglogical パッケージをインストールするをご覧ください。
移行元インスタンスの拡張機能を確認します。Database Migration Service は、Cloud SQL でサポートされていない拡張機能を移行しません。これらの拡張機能が存在しても移行はブロックされませんが、スムーズな移行プロセスを確保するため、オブジェクトまたはアプリケーションがサポートされていない拡張機能を参照していないことを確認してください。続行する前に、移行元データベースからこれらの拡張機能と参照を削除することをおすすめします。
pg_cron 拡張機能を使用する移行元の場合: pg_cron 拡張機能（または拡張機能に関連付けられた cron 設定）は Database Migration Service によって移行されませんが、Cloud SQL for PostgreSQL の移行先ではサポートされています。移行元データベースで 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

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

PostgreSQL バージョン 9.4 のソースの場合のみ、ソースインスタンスの各データベースに次の pglogical 拡張機能をインストールします。
- CREATE EXTENSION IF NOT EXISTS pglogical;
- CREATE EXTENSION IF NOT EXISTS pglogical_origin;
他のすべてのバージョンでは、移行元インスタンスの各データベースに pglogical 拡張機能（CREATE EXTENSION IF NOT EXISTS pglogical）のみをインストールします。
主キーがないテーブルの場合、Database Migration Service は、CDC フェーズでの初期スナップショットと INSERT ステートメントの移行をサポートします。UPDATE ステートメントと DELETE ステートメントは手動で移行する必要があります。

PostgreSQL データベース内で主キーのないテーブルを一覧表示するクエリを作成する方法については、デバッグとその他のツールをご覧ください。主キーがないとわかり、テーブルが移行されていないデータベースの一部ではない場合は、主キーがあるようにテーブルを変更するか、このプロセスに沿って操作します。主キーのないテーブルの場合、最初のスナップショットと INSERT ステートメントのみが移行されます。
移行元のインスタンスへの接続に使用する 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` パッケージをインストールする

このセクションでは、ソースインスタンスに応じて pglogical パッケージと該当するパラメータを構成する方法について説明します。

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

サーバーに pglogical パッケージをインストールします。
インスタンスに接続し、必要に応じて次のパラメータを設定します。
- 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 = #;
構成の変更を適用するには、移行元インスタンスを再起動します。

Microsoft Azure Database for PostgreSQL

Microsoft Azure Database for PostgreSQL ソースを構成する手順は次のとおりです。

サーバーに pglogical パッケージをインストールします。
PostgreSQL バージョン 9.4 のソースの場合のみ、ソースインスタンスの各データベースに次の pglogical 拡張機能をインストールします。
- CREATE EXTENSION IF NOT EXISTS pglogical;
- CREATE EXTENSION IF NOT EXISTS pglogical_origin;
他のすべてのバージョンの場合は、移行元インスタンスの各データベースに pglogical 拡張機能（CREATE EXTENSION IF NOT EXISTS pglogical）をインストールします。
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 の数の合計以上に設定します。
  
  調整されたデータダンプの並列処理設定を使用する場合は、ワーカープロセスの数を増やし、移行ジョブの作成時に移行ジョブのテストを実行して構成を確認してください。
require_secure_transport 設定の値を確認します。

デフォルトでは、Microsoft Azure データベースではすべての受信接続で SSL/TLS 暗号化が必要です。require_secure_transport 値に応じて、ソース接続プロファイルを作成するときに、次のいずれかの暗号化設定を使用します。
- require_secure_transport が on に設定されている場合は、[Basic]、[TLS]、[mTLS] のいずれかを選択します。
- require_secure_transport が off に設定されている場合は、[なし] を選択します。
構成の変更を適用するには、移行元インスタンスを再起動します。

Amazon RDS PostgreSQL

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

詳細については、Amazon RDS ドキュメントの Amazon RDS for PostgreSQL での PostgreSQL 拡張機能の使用をご覧ください。
パラメータグループを使用して、ソースインスタンスを構成します。
1. 新しいパラメータグループを作成します。パラメータグループで次の操作を行います。
2. パラメータグループをインスタンスにアタッチします。新しいインスタンスを作成する場合は、[追加構成] でこのオプションを確認できます。
  
  それ以外の場合は、インスタンスを変更してパラメータグループを関連付けます。
構成の変更を適用するには、移行元インスタンスを再起動します。

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

Cloud SQL for PostgreSQL

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

cloudsql.logical_decoding フラグと cloudsql.enable_pglogical フラグを on に設定します。
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 です。
wal_sender_timeout パラメータを 0 に設定します。値 0 は、非アクティブなレプリケーション接続を終了するタイムアウトメカニズムを無効にします。
フラグに対して行った構成の変更が有効になるように、移行元インスタンスを再起動します。

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

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

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

次の関数を定義して、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;
$$;

次のコマンドを実行して、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: 移行元インスタンスに接続する 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%';

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

セットアップする

ソース接続プロファイルの作成