概要
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。
- セルフマネージド PostgreSQL(オンプレミスまたはお客様が完全に管理するクラウド VM 上)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 Flexible Server: 11 以降
移行元を構成するには、移行元インスタンスと基盤となる移行元データベースの両方を構成する必要があります。
移行元インスタンスを構成する
移行元のインスタンスを構成する手順は次のとおりです。
- Cloud SQL ソースの場合: プライベート IP 接続を使用する Cloud SQL インスタンスから、RFC 1918 以外のアドレス IP 範囲を使用する Cloud SQL インスタンスに移行する場合は、ソースの Cloud SQL インスタンスのネットワーク構成に RFC 1918 以外の範囲を追加します。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;
他のすべてのバージョンの場合は、移行元インスタンスの各データベース(
CREATE EXTENSION IF NOT EXISTS pglogical
)にpglogical
拡張機能のみをインストールします。主キーのないテーブルの場合、Database Migration Service は、CDC フェーズでの初期スナップショットと
INSERT
ステートメントの移行をサポートします。UPDATE
ステートメントとDELETE
ステートメントは手動で移行する必要があります。移行元インスタンスへの接続に使用する USER([接続プロファイル] ページでユーザーとして構成)には、移行した各データベースとデフォルトの
postgres
データベースに対する一定の権限が必要です。新しいユーザーを作成することも、既存のユーザーを再利用することもできます。これらの権限を設定するには、インスタンスに接続して次のコマンドを実行します。- 移行する各データベースのすべてのスキーマ(情報スキーマと「pg_」で始まるスキーマを除く)に対する
GRANT USAGE on SCHEMA SCHEMA to USER
。 - 移行する各データベースに対する
GRANT USAGE on SCHEMA pglogical to PUBLIC;
。 - 移行元データベースからレプリケーション情報を取得するすべてのデータベースに対する
GRANT SELECT on ALL TABLES in SCHEMA pglogical to USER
。 - 移行する各データベースのすべてのスキーマ(情報スキーマと「pg_」で始まるスキーマを除く)に対する
GRANT SELECT on ALL TABLES in SCHEMA SCHEMA to USER
。 - 移行する各データベースのすべてのスキーマ(情報スキーマと「pg_」で始まるスキーマを除く)に対する
GRANT SELECT on ALL SEQUENCES in SCHEMA SCHEMA to USER
。 - 移行元が Amazon RDS の場合は、次のコマンドを実行します。
GRANT rds_replication to USER
- 移行元が Amazon RDS でない場合は、次のコマンドを実行します。
ALTER USER USER with REPLICATION
ロール
- 移行する各データベースのすべてのスキーマ(情報スキーマと「pg_」で始まるスキーマを除く)に対する
移行元のインスタンスに pglogical
パッケージをインストールする
このセクションでは、ソース インスタンスに応じて、pglogical
パッケージと適用可能なパラメータを構成する方法について説明します。
オンプレミスまたはセルフマネージドの PostgreSQL
- サーバーに pglogical パッケージをインストールします。
- インスタンスに接続し、必要に応じて次のパラメータを設定します。
shared_preload_libraries
にはpglogical
を含める必要があります。このパラメータを設定するには、
ALTER SYSTEM SET shared_preload_libraries = 'pglogical,[any other libraries in your instance]';
コマンドを実行します。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 = #;
コマンドを実行します。ここで、# は移行されるデータベースの数を表します。
- 構成の変更を適用するには、移行元インスタンスを再起動します。
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;
他のすべてのバージョンの場合は、移行元インスタンスの各データベース(
CREATE EXTENSION IF NOT EXISTS pglogical
)に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
に設定されている場合は、[基本]、[TLS]、または [mTLS] を選択します。require_secure_transport
がoff
に設定されている場合は、[なし] を選択します。
- 構成の変更を適用するには、移行元インスタンスを再起動します。
Amazon RDS PostgreSQL
移行元データベースに
pglogical
拡張機能をインストールします。詳細については、Amazon RDS ドキュメントの Amazon RDS for PostgreSQL で PostgreSQL 拡張機能を使用するをご覧ください。
パラメータ グループを使用してソース インスタンスを構成します。
- 新しいパラメータ グループを作成します。パラメータ グループで、次のように設定します。
shared_preload_libraries
パラメータにpglogical
が含まれていることを確認します。rds.logical_replication
パラメータを 1 に設定します。これにより、「logical」レベルで 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 です。
パラメータ グループをインスタンスにアタッチします。新しいインスタンスを作成する場合は、[追加の構成] でこのオプションを見つけることができます。
それ以外の場合は、インスタンスを変更してパラメータ グループをアタッチします。
構成の変更を適用するには、移行元インスタンスを再起動します。
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
に設定します。ALTER SYSTEM SET 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; $$;
次のコマンドを実行して、USER に
EXECUTE
権限を付与します。REVOKE EXECUTE ON FUNCTION pg_stat_replication_user() FROM public;
GRANT EXECUTE ON FUNCTION pg_stat_replication_user() to {replication_user};
オプション 2: 移行元インスタンスに接続する USER に直接
SUPERUSER
権限を付与する。これにより、Database Migration Service はレプリケーションの遅延を直接読み取ることができます。オプション 3: 次のクエリを使用して、レプリケーションの遅延を個別に追跡する。
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 レスポンスにレプリケーション遅延の指標が反映されません。