Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

継続的な移行のためにソース PostgreSQL データベースを構成する

このページでは、標準の同種 PostgreSQL 移行用にソースデータベースインスタンスを構成する方法について説明します。クイックスタート移行を使用する場合は、クイックスタート移行を使用するガイドに沿って操作します。クイックスタート移行では、pgnative レプリケーションと Private Service Connect インターフェースに基づく専用接続を使用する、簡素化された移行フローが提供されます。詳細については、Database Migration Service のメインドキュメントのクイックスタート移行についてをご覧ください。

このページには、サポートされている各ソースのセクションがあります。

セルフマネージド PostgreSQL（オンプレミスまたは Compute Engine VM 上）
Amazon RDS for PostgreSQL
Amazon Aurora for PostgreSQL
Microsoft Azure Database for PostgreSQL フレキシブルサーバー
Cloud SQL for PostgreSQL

セルフマネージド PostgreSQL ソースを構成する

移行プロセス用にセルフマネージド PostgreSQL ソースインスタンス（オンプレミスまたは Compute Engine VM でホストされている）を構成するには、次の操作を行います。

セルフマネージド PostgreSQL ソースの場合、Database Migration Service は、テンプレートデータベース template0 と template1 を除く、移行元インスタンスのすべてのデータベースを移行します。
移行元インスタンスにデフォルトの postgres データベースが含まれていることを確認します。このデータベースが存在しない場合は、移行を構成する前に作成します。
pg_hba.conf ファイルでネットワーククライアント認証を構成します。移行先の Cloud SQL アウトバウンド IP アドレス、VPC CIDR の範囲、またはリバース SSH 踏み台インスタンスからのレプリケーション接続とデータベースアクセスを許可するエントリを追加します。
```
# Allow replication connections
host  replication  MIGRATION_USER_ACCOUNT_NAME  DESTINATION_IP_OR_CIDR  md5
# Allow database access
host  all          MIGRATION_USER_ACCOUNT_NAME  DESTINATION_IP_OR_CIDR  md5
```
PostgreSQL 構成を再読み込みして、pg_hba.conf ルールを適用します。
```
SELECT pg_reload_conf();
```
ソースデータベースにインストールされている PostgreSQL 拡張機能を確認します。Database Migration Service は、Cloud SQL でサポートされていない拡張機能を移行しません。ソースデータベースオブジェクトとアプリケーションクエリが、サポートされていない拡張機能を参照していないことを確認します。続行する前に、サポートされていない拡張機能と参照を移行元データベースから削除してください。
pg_cron 拡張機能は Database Migration Service によって自動的に移行されませんが、Cloud SQL for PostgreSQL の移行先でサポートされています。移行元データベースで pg_cron を使用している場合は、移行をプロモートした後に、移行先インスタンスに再インストールして構成します。
移行元インスタンスに移行専用のユーザーアカウントを作成し、必要な権限を付与します。
1. 管理者アカウントを使用してソースインスタンスに接続し、ユーザーを作成して、レプリケーションロールを割り当てます。
```
CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
ALTER USER MIGRATION_USER_ACCOUNT_NAME WITH REPLICATION;
```
2. 移行ユーザーアカウントに、デフォルトの postgres データベースと、移行するすべてのデータベースに必要な権限を付与します。各データベースで、各スキーマ（情報スキーマと pg_ で始まるスキーマを除く）に対して次のコマンドを実行します。
```
GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
```
移行する各データベース（template0 と template1 を除く）に pglogical 拡張機能をインストールします。
- PostgreSQL バージョン 9.4 の場合: 次のコマンドを実行します。
```
CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
```
- PostgreSQL バージョン 9.5 以降の場合: 次のコマンドを実行します。
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
テーブルに主キーがあることを確認します。継続的な移行の場合、PostgreSQL の論理レプリケーションでは、変更データキャプチャ（CDC）フェーズで UPDATE オペレーションと DELETE オペレーションを複製するために、テーブルに主キーが必要です。
- 主キーを持つテーブルは、すべての INSERT、UPDATE、DELETE オペレーションを自動的に複製します。
- 主キーがないテーブルの場合、Database Migration Service は、CDC フェーズでの初期スナップショットと後続の INSERT ステートメントの移行のみをサポートします。UPDATE ステートメントと DELETE ステートメントは手動で移行する必要があります。
  移行を開始する前に、主キーのないテーブルに主キーを追加することをおすすめします。PostgreSQL データベース内で主キーのないテーブルを一覧表示するクエリを作成する方法、または UPDATE オペレーションと DELETE オペレーションを手動で移行する方法については、デバッグとその他のツールをご覧ください。
  
  または、クイックスタート移行フローを使用することもできます。これは、REPLICA IDENTITY を使用して主キーのないテーブルを移行できる、簡素化された移行シナリオです。詳細については、クイックスタート移行を使用するガイドをご覧ください。
PostgreSQL バージョン 9.5 以前を実行しているソース: PostgreSQL バージョン 9.6 以前を実行しているソースインスタンスでは、レプリケーション遅延の指標を使用できません。この指標を使用して移行の進行状況を追跡する場合は、レプリケーション遅延を有効にするをご覧ください。
pglogical パッケージをインストールし、PostgreSQL サーバーで WAL とレプリケーションパラメータを構成します。
1. データベースサーバーのホストオペレーティングシステムに pglogical パッケージをインストールします。ディストリビューションのパッケージとインストール手順については、pglogical GitHub リポジトリをご覧ください。
2. 管理アカウントを使用して PostgreSQL インスタンスに接続し、次のパラメータを設定します。
  1. shared_preload_libraries を 'pglogical' を含むように設定します。
```
ALTER SYSTEM SET shared_preload_libraries = 'pglogical';
```
    他のライブラリがすでにインスタンスに読み込まれている場合は、既存のカンマ区切りのリストに 'pglogical' を追加します。
    既存のライブラリを表示するには、SHOW shared_preload_libraries; を実行します。
  2. wal_level を 'logical' に設定します。
```
ALTER SYSTEM SET wal_level = 'logical';
```
    PostgreSQL のドキュメントで wal_level をご覧ください。
  3. wal_sender_timeout を 0 に設定します。
```
ALTER SYSTEM SET wal_sender_timeout = 0;
```
    0 値は、非アクティブなレプリケーション接続を終了するタイムアウトメカニズムを無効にします。wal_sender_timeout をご覧ください。
  4. max_replication_slots は、移行するデータベースの数に移行ジョブの数を掛けた値に、テーブル同期用の予約分を加えた値以上に設定します。
    たとえば、移行元インスタンスに 5 つのデータベースがあり、その移行元に 2 つの移行ジョブを作成する場合、レプリケーションスロットの数は 5 × 2 = 10 以上にする必要があります。これに加えて、他のタスクによって移行元ですでに使用されているレプリケーションスロットの数も必要です。調整されたデータダンプ並列処理設定を使用する場合は、レプリケーションスロットの数を増やし、移行ジョブの作成時に移行ジョブテストを実行して構成を確認してください。
```
ALTER SYSTEM SET max_replication_slots = MAX_REPLICATION_SLOTS;
```
    このパラメータのデフォルト値は 10 です。max_replication_slots をご覧ください。
  5. max_wal_senders は、max_replication_slots の値とインスタンスですでに使用されている送信者の数を合計した値以上に設定します。
    たとえば、max_replication_slots パラメータが 10 に設定されていて、すでに 2 つの送信者を使用している場合、同時に実行される WAL 送信者プロセスの数は 10 + 2 = 12 になります。調整されたデータダンプ並列処理設定を使用する場合は、移行ジョブの作成時に移行ジョブテストを実行して、送信者の数を増やし、構成を確認してください。
```
ALTER SYSTEM SET max_wal_senders = MAX_WAL_SENDERS;
```
    このパラメータのデフォルト値は 10 です。max_wal_senders をご覧ください。
  6. max_worker_processes は、移行するデータベースの数とインスタンス上の既存のワーカープロセスの数の合計以上に設定します。調整されたデータダンプの並列処理設定を使用する場合は、接続ごとに 2 つの追加ワーカープロセス（最大 20 ワーカー）を考慮します。
```
ALTER SYSTEM SET max_worker_processes = MAX_WORKER_PROCESSES;
```
    このパラメータのデフォルト値は 8 です。max_worker_processes をご覧ください。
  または、パラメータを postgresql.conf 構成ファイルに直接追加して、これらの変更を永続化することもできます。
```
shared_preload_libraries = 'pglogical'
wal_level = 'logical'
wal_sender_timeout = 0
max_replication_slots = MAX_REPLICATION_SLOTS
max_wal_senders = MAX_WAL_SENDERS
max_worker_processes = MAX_WORKER_PROCESSES
```
構成の変更が反映されるように、PostgreSQL サーバーを再起動します。

Amazon RDS for PostgreSQL ソースを構成する

移行プロセス用に Amazon RDS for PostgreSQL ソースインスタンスを構成するには、次の操作を行います。

Amazon RDS for PostgreSQL ソースの場合、Database Migration Service は、テンプレートデータベース template0、template1、AWS 内部データベース rdsadmin を除く、ソースインスタンスのすべてのデータベースを移行します。
移行元インスタンスにデフォルトの postgres データベースが含まれていることを確認します。このデータベースが存在しない場合は、移行を構成する前に作成します。
Amazon RDS VPC セキュリティグループの受信ルールを構成します。宛先の Cloud SQL アウトバウンド IP アドレス、VPC CIDR の範囲、またはリバース SSH 踏み台インスタンス VM からのポート 5432 での受信 TCP 接続を許可します。
ソースデータベースにインストールされている PostgreSQL 拡張機能を確認します。Database Migration Service は、Cloud SQL でサポートされていない拡張機能を移行しません。ソースデータベースオブジェクトとアプリケーションクエリが、サポートされていない拡張機能を参照していないことを確認します。続行する前に、サポートされていない拡張機能と参照を移行元データベースから削除してください。
pg_cron 拡張機能は Database Migration Service によって自動的に移行されませんが、Cloud SQL for PostgreSQL の移行先でサポートされています。移行元データベースで pg_cron を使用している場合は、移行をプロモートした後に、移行先インスタンスに再インストールして構成します。
移行元インスタンスに移行専用のユーザーアカウントを作成し、必要な権限を付与します。
1. 管理アカウントを使用してソースインスタンスに接続し、ユーザーを作成して、AWS 管理の rds_replication ロールを付与します。
```
CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
GRANT rds_replication TO "MIGRATION_USER_ACCOUNT_NAME";
```
2. 移行ユーザーアカウントに、デフォルトの postgres データベースと、移行するすべてのデータベースに必要な権限を付与します。各データベースで、各スキーマ（情報スキーマと pg_ で始まるスキーマを除く）に対して次のコマンドを実行します。
```
GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
```
移行する各データベース（template0、template1、rdsadmin を除く）に pglogical 拡張機能をインストールします。
- PostgreSQL バージョン 9.4 の場合: 次のコマンドを実行します。
```
CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
```
- PostgreSQL バージョン 9.5 以降の場合: 次のコマンドを実行します。
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
要件の詳細については、AWS ドキュメントの Amazon RDS for PostgreSQL で PostgreSQL 拡張機能を使用するをご覧ください。

注: pglogical 拡張機能は、移行元インスタンスのデータベースログに認証情報を書式なしテキストで記録できます。これは拡張機能自体の既知の動作であり、Database Migration Service や Cloud SQL とは関係ありません。
テーブルに主キーがあることを確認します。継続的な移行の場合、PostgreSQL の論理レプリケーションでは、変更データキャプチャ（CDC）フェーズで UPDATE オペレーションと DELETE オペレーションを複製するために、テーブルに主キーが必要です。
- 主キーを持つテーブルは、すべての INSERT、UPDATE、DELETE オペレーションを自動的に複製します。
- 主キーがないテーブルの場合、Database Migration Service は、CDC フェーズでの初期スナップショットと後続の INSERT ステートメントの移行のみをサポートします。UPDATE ステートメントと DELETE ステートメントは手動で移行する必要があります。
  移行を開始する前に、主キーのないテーブルに主キーを追加することをおすすめします。PostgreSQL データベース内で主キーのないテーブルを一覧表示するクエリを作成する方法、または UPDATE オペレーションと DELETE オペレーションを手動で移行する方法については、デバッグとその他のツールをご覧ください。
  
  または、クイックスタート移行フローを使用することもできます。これは、REPLICA IDENTITY を使用して主キーのないテーブルを移行できる、簡素化された移行シナリオです。詳細については、クイックスタート移行を使用するガイドをご覧ください。
PostgreSQL バージョン 9.5 以前を実行しているソース: PostgreSQL バージョン 9.6 以前を実行しているソースインスタンスでは、レプリケーション遅延の指標を使用できません。この指標を使用して移行の進行状況を追跡する場合は、レプリケーション遅延を有効にするをご覧ください。
カスタム DB パラメータグループを構成し、インスタンスにアタッチします。
1. カスタムパラメータグループを作成し（AWS ドキュメントの DB パラメータグループの操作をご覧ください）、次のパラメータを構成します。
  1. shared_preload_libraries を設定して、pglogical を含めます。
  2. [rds.logical_replication] を [1] に設定します。このパラメータにより、Amazon RDS で論理 WAL ロギングが有効になります。Amazon RDS for PostgreSQL の論理レプリケーションをご覧ください。
  3. [wal_sender_timeout] を [0] に設定します。0 値は、非アクティブなレプリケーション接続を終了するタイムアウトメカニズムを無効にします。
  4. max_replication_slots は、移行するデータベースの数に移行ジョブの数を掛けた値に、テーブル同期用の予約分を加えた値以上に設定します。
    たとえば、移行元インスタンスに 5 つのデータベースがあり、その移行元に 2 つの移行ジョブを作成する場合、レプリケーションスロットの数は 5 × 2 = 10 以上にする必要があります。これに加えて、他のタスクによって移行元ですでに使用されているレプリケーションスロットの数も必要です。調整されたデータダンプ並列処理設定を使用する場合は、レプリケーションスロットの数を増やし、移行ジョブの作成時に移行ジョブテストを実行して構成を確認してください。
    
    このパラメータのデフォルト値は 10 です。
  5. max_wal_senders は、max_replication_slots の値とインスタンスですでに使用されている送信者の数を合計した値以上に設定します。
    たとえば、max_replication_slots パラメータが 10 に設定されていて、すでに 2 つの送信者を使用している場合、同時に実行される WAL 送信者プロセスの数は 10 + 2 = 12 になります。調整されたデータダンプ並列処理設定を使用する場合は、移行ジョブの作成時に移行ジョブテストを実行して、送信者の数を増やし、構成を確認してください。
    
    このパラメータのデフォルト値は 10 です。
  6. max_worker_processes は、移行するデータベースの数とインスタンス上の既存のワーカープロセスの数の合計以上に設定します。調整されたデータダンプの並列処理設定を使用する場合は、接続ごとに 2 つの追加ワーカープロセス（最大 20 ワーカー）を考慮します。
    このパラメータのデフォルト値は 8 です。
2. パラメータグループを RDS DB インスタンスにアタッチします。新しいインスタンスを作成する場合は、[追加構成] でこのオプションを確認できます。それ以外の場合は、インスタンスを変更してパラメータグループをアタッチします。
パラメータグループの変更が有効になるように、Amazon RDS インスタンスを再起動します。

Amazon Aurora for PostgreSQL ソースを構成する

移行プロセス用に Amazon Aurora PostgreSQL ソースクラスタを構成するには、次の操作を行います。

Amazon Aurora for PostgreSQL ソースの場合、Database Migration Service は、テンプレートデータベース template0、template1、AWS 内部データベース rdsadmin を除く、ソースクラスタ内のすべてのデータベースを移行します。
ソースクラスタにデフォルトの postgres データベースが含まれていることを確認します。このデータベースが存在しない場合は、移行を構成する前に作成します。
Amazon Aurora クラスタの VPC セキュリティグループの受信ルールを構成します。宛先の Cloud SQL アウトバウンド IP アドレス、VPC CIDR の範囲、またはリバース SSH 踏み台インスタンス VM からのポート 5432 での受信 TCP 接続を許可します。
ソースデータベースにインストールされている PostgreSQL 拡張機能を確認します。Database Migration Service は、Cloud SQL でサポートされていない拡張機能を移行しません。ソースデータベースオブジェクトとアプリケーションクエリが、サポートされていない拡張機能を参照していないことを確認します。続行する前に、サポートされていない拡張機能と参照を移行元データベースから削除してください。
pg_cron 拡張機能は Database Migration Service によって自動的に移行されませんが、Cloud SQL for PostgreSQL の移行先でサポートされています。移行元データベースで pg_cron を使用している場合は、移行をプロモートした後に、移行先インスタンスに再インストールして構成します。
ソースクラスタに移行専用のユーザーアカウントを作成し、必要な権限を付与します。
1. 管理アカウントを使用してソースクラスタに接続し、ユーザーを作成して、AWS 管理の rds_replication ロールを付与します。
```
CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
GRANT rds_replication TO "MIGRATION_USER_ACCOUNT_NAME";
```
2. 移行ユーザーアカウントに、デフォルトの postgres データベースと、移行するすべてのデータベースに必要な権限を付与します。各データベースで、各スキーマ（情報スキーマと pg_ で始まるスキーマを除く）に対して次のコマンドを実行します。
```
GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
```
移行する各データベース（template0、template1、rdsadmin を除く）に pglogical 拡張機能をインストールします。
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
注: pglogical 拡張機能は、移行元インスタンスのデータベースログに認証情報を書式なしテキストで記録できます。これは拡張機能自体の既知の動作であり、Database Migration Service や Cloud SQL とは関係ありません。
テーブルに主キーがあることを確認します。継続的な移行の場合、PostgreSQL の論理レプリケーションでは、変更データキャプチャ（CDC）フェーズで UPDATE オペレーションと DELETE オペレーションを複製するために、テーブルに主キーが必要です。
- 主キーを持つテーブルは、すべての INSERT、UPDATE、DELETE オペレーションを自動的に複製します。
- 主キーがないテーブルの場合、Database Migration Service は、CDC フェーズでの初期スナップショットと後続の INSERT ステートメントの移行のみをサポートします。UPDATE ステートメントと DELETE ステートメントは手動で移行する必要があります。
  移行を開始する前に、主キーのないテーブルに主キーを追加することをおすすめします。PostgreSQL データベース内で主キーのないテーブルを一覧表示するクエリを作成する方法、または UPDATE オペレーションと DELETE オペレーションを手動で移行する方法については、デバッグとその他のツールをご覧ください。
  
  または、クイックスタート移行フローを使用することもできます。これは、REPLICA IDENTITY を使用して主キーのないテーブルを移行できる、簡素化された移行シナリオです。詳細については、クイックスタート移行を使用するガイドをご覧ください。
カスタム DB クラスタパラメータグループを構成し、クラスタに接続します。
1. カスタム DB クラスタパラメータグループを作成し、次のパラメータを構成します。
  1. shared_preload_libraries を設定して、pglogical を含めます。
  2. [rds.logical_replication] を [1] に設定します。このパラメータは、論理 WAL ロギングを有効にします。
  3. [wal_sender_timeout] を [0] に設定します。0 値は、非アクティブなレプリケーション接続を終了するタイムアウトメカニズムを無効にします。
  4. max_replication_slots は、移行するデータベースの数に移行ジョブの数を掛けた値に、テーブル同期用の予約分を加えた値以上に設定します。
    たとえば、移行元インスタンスに 5 つのデータベースがあり、その移行元に 2 つの移行ジョブを作成する場合、レプリケーションスロットの数は 5 × 2 = 10 以上にする必要があります。これに加えて、他のタスクによって移行元ですでに使用されているレプリケーションスロットの数も必要です。調整されたデータダンプの並列処理設定を使用する場合は、レプリケーションスロットの数を増やし、移行ジョブの作成時に移行ジョブテストを実行して構成を確認してください。
    
    このパラメータのデフォルト値は 10 です。
  5. max_wal_senders は、max_replication_slots の値とインスタンスですでに使用されている送信者の数を合計した値以上に設定します。
    たとえば、max_replication_slots パラメータが 10 に設定されていて、すでに 2 つの送信者を使用している場合、同時に実行される WAL 送信者プロセスの数は 10 + 2 = 12 になります。調整されたデータダンプ並列処理設定を使用する場合は、移行ジョブの作成時に移行ジョブテストを実行して、送信者の数を増やし、構成を確認してください。
    
    このパラメータのデフォルト値は 10 です。
  6. max_worker_processes は、移行するデータベースの数とインスタンス上の既存のワーカープロセスの数の合計以上に設定します。調整されたデータダンプの並列処理設定を使用する場合は、接続ごとに 2 つの追加ワーカープロセス（最大 20 ワーカー）を考慮します。
    このパラメータのデフォルト値は 8 です。
2. DB クラスタパラメータグループを Aurora DB クラスタにアタッチします。
パラメータグループの変更が有効になるように、Amazon Aurora DB クラスタを再起動します。

Microsoft Azure Database for PostgreSQL フレキシブルサーバーのソースを構成する

移行プロセス用に Microsoft Azure Database for PostgreSQL フレキシブルサーバーのソースインスタンスを構成するには、次の操作を行います。

Microsoft Azure Database for PostgreSQL フレキシブルサーバーのソースの場合、Database Migration Service は、Azure システムデータベースとテンプレートデータベース（azure_maintenance、azure_sys、template0、template1）を除く、ソースインスタンスのすべてのデータベースを移行します。
移行元インスタンスにデフォルトの postgres データベースが含まれていることを確認します。このデータベースが存在しない場合は、移行を構成する前に作成します。
Azure ファイアウォールと SSL/TLS の設定を構成します。
1. Azure のネットワーク設定で、宛先の Cloud SQL のアウトバウンド IP アドレス、VPC CIDR 範囲、またはリバース SSH 踏み台インスタンス VM からのポート 5432 でのインバウンド TCP 接続を許可するファイアウォールルールを追加します。
2. require_secure_transport サーバーパラメータの値を確認します。デフォルトでは、Azure データベースでは受信接続に SSL/TLS 暗号化が必要です。require_secure_transport の設定に応じて、ソース接続プロファイルを作成するときに、次のいずれかの暗号化設定を選択します。
  - require_secure_transport が on に設定されている場合は、[Basic]、[TLS]、[mTLS] のいずれかを選択します。
  - require_secure_transport が off に設定されている場合は、[なし] を選択します。
ソースデータベースにインストールされている PostgreSQL 拡張機能を確認します。Database Migration Service は、Cloud SQL でサポートされていない拡張機能を移行しません。ソースデータベースオブジェクトとアプリケーションクエリが、サポートされていない拡張機能を参照していないことを確認します。続行する前に、サポートされていない拡張機能と参照を移行元データベースから削除してください。
pg_cron 拡張機能は Database Migration Service によって自動的に移行されませんが、Cloud SQL for PostgreSQL の移行先でサポートされています。移行元データベースで pg_cron を使用している場合は、移行をプロモートした後に、移行先インスタンスに再インストールして構成します。
移行元インスタンスに移行専用のユーザーアカウントを作成し、必要な権限を付与します。
1. 管理者アカウントを使用してソースインスタンスに接続し、ユーザーを作成して、レプリケーションロールを割り当てます。
```
CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
ALTER USER MIGRATION_USER_ACCOUNT_NAME WITH REPLICATION;
```
2. 移行ユーザーアカウントに、デフォルトの postgres データベースと、移行するすべてのデータベースに必要な権限を付与します。各データベースで、各スキーマ（情報スキーマと pg_ で始まるスキーマを除く）に対して次のコマンドを実行します。
```
GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
```
移行する各データベース（azure_maintenance、azure_sys、template0、template1 を除く）に pglogical 拡張機能をインストールします。
- PostgreSQL バージョン 9.4 の場合: 次のコマンドを実行します。
```
CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
```
- PostgreSQL バージョン 9.5 以降の場合: 次のコマンドを実行します。
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
テーブルに主キーがあることを確認します。継続的な移行の場合、PostgreSQL の論理レプリケーションでは、変更データキャプチャ（CDC）フェーズで UPDATE オペレーションと DELETE オペレーションを複製するために、テーブルに主キーが必要です。
- 主キーを持つテーブルは、すべての INSERT、UPDATE、DELETE オペレーションを自動的に複製します。
- 主キーがないテーブルの場合、Database Migration Service は、CDC フェーズでの初期スナップショットと後続の INSERT ステートメントの移行のみをサポートします。UPDATE ステートメントと DELETE ステートメントは手動で移行する必要があります。
  移行を開始する前に、主キーのないテーブルに主キーを追加することをおすすめします。PostgreSQL データベース内で主キーのないテーブルを一覧表示するクエリを作成する方法、または UPDATE オペレーションと DELETE オペレーションを手動で移行する方法については、デバッグとその他のツールをご覧ください。
  
  または、クイックスタート移行フローを使用することもできます。これは、REPLICA IDENTITY を使用して主キーのないテーブルを移行できる、簡素化された移行シナリオです。詳細については、クイックスタート移行を使用するガイドをご覧ください。
PostgreSQL バージョン 9.5 以前を実行しているソース: PostgreSQL バージョン 9.6 以前を実行しているソースインスタンスでは、レプリケーション遅延の指標を使用できません。この指標を使用して移行の進行状況を追跡する場合は、レプリケーション遅延を有効にするをご覧ください。
Azure で次のサーバーパラメータを構成します。詳細については、Azure Database for PostgreSQL でサーバーパラメータを構成するをご覧ください。
1. shared_preload_libraries を設定して、pglogical を含めます。
2. azure.extensions を設定して、pglogical を含めます。
3. wal_level を logical に設定します。
4. [wal_sender_timeout] を [0] に設定します。0 値は、非アクティブなレプリケーション接続を終了するタイムアウトメカニズムを無効にします。
5. max_replication_slots には、移行するデータベースの数に移行ジョブの数を掛けた値に、テーブル同期用の予約分を加えた値を設定します。
  たとえば、移行元インスタンスに 5 つのデータベースがあり、その移行元に 2 つの移行ジョブを作成する場合、レプリケーションスロットの数は 5 × 2 = 10 以上にする必要があります。これに、他のタスクによって移行元ですでに使用されているレプリケーションスロットの数を加えます。調整されたデータダンプ並列処理設定を使用する場合は、レプリケーションスロットの数を増やし、移行ジョブの作成時に移行ジョブテストを実行して構成を確認してください。
  
  このパラメータのデフォルト値は 10 です。
6. max_wal_senders は、max_replication_slots の値とインスタンスですでに使用されている送信者の数を合計した値以上に設定します。
  たとえば、max_replication_slots パラメータが 10 に設定されていて、すでに 2 つの送信者を使用している場合、同時に実行される WAL 送信者プロセスの数は 10 + 2 = 12 になります。調整されたデータダンプ並列処理設定を使用する場合は、移行ジョブの作成時に移行ジョブテストを実行して、送信者の数を増やし、構成を確認してください。
  
  このパラメータのデフォルト値は 10 です。
7. max_worker_processes は、移行するデータベースの数とインスタンス上の既存のワーカープロセスの数の合計以上に設定します。調整されたデータダンプの並列処理設定を使用する場合は、接続ごとに 2 つの追加ワーカープロセス（最大 20 ワーカー）を考慮します。
  このパラメータのデフォルト値は 8 です。
パラメータの詳細については、Microsoft ドキュメントの Azure Database for PostgreSQL のサーバーパラメータの一覧をご覧ください。
Microsoft Azure Database for PostgreSQL フレキシブルサーバーインスタンスを再起動して、サーバーパラメータの変更を有効にします。

Cloud SQL for PostgreSQL ソースを構成する

移行プロセス用に Cloud SQL for PostgreSQL ソースインスタンスを構成するには、次の操作を行います。

Cloud SQL for PostgreSQL の移行元の場合、Database Migration Service は、テンプレートデータベース template0 と template1 を除く、移行元インスタンスのすべてのデータベースを移行します。
移行元インスタンスにデフォルトの postgres データベースが含まれていることを確認します。このデータベースが存在しない場合は、移行を構成する前に作成します。
プライベート IP アドレスで構成された Cloud SQL 移行元インスタンスから、RFC 1918 以外のアドレス IP 範囲を使用する Cloud SQL 移行先インスタンスに移行する場合は、RFC 1918 以外の範囲を移行元インスタンスの承認済みネットワークに追加します。詳細については、承認済みネットワークを構成するをご覧ください。
ソースデータベースにインストールされている PostgreSQL 拡張機能を確認します。Database Migration Service は、 Cloud SQL でサポートされていない拡張機能を移行しません。ソースデータベースオブジェクトとアプリケーションクエリが、サポートされていない拡張機能を参照していないことを確認します。続行する前に、サポートされていない拡張機能と参照をソースデータベースから削除します。
pg_cron 拡張機能は Database Migration Service によって自動的に移行されませんが、Cloud SQL for PostgreSQL の宛先でサポートされています。移行元データベースで pg_cron を使用している場合は、移行をプロモートした後に、移行先インスタンスに再インストールして構成します。
移行元インスタンスに移行専用のユーザーアカウントを作成し、必要な権限を付与します。
1. Cloud SQL ドキュメントのユーザーを作成するページの手順に沿って操作します。
2. 移行ユーザーアカウントに、デフォルトの postgres データベースと、移行するすべてのデータベースに必要な権限を付与します。各データベースで、各スキーマ（情報スキーマと pg_ で始まるスキーマを除く）に対して次のコマンドを実行します。
```
GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
```
移行する各データベース（template0 と template1 を除く）に pglogical 拡張機能をインストールします。
- PostgreSQL バージョン 9.4 の場合: 次のコマンドを実行します。
```
CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
```
- PostgreSQL バージョン 9.5 以降の場合: 次のコマンドを実行します。
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
テーブルに主キーがあることを確認します。継続的な移行の場合、PostgreSQL の論理レプリケーションでは、変更データキャプチャ（CDC）フェーズで UPDATE オペレーションと DELETE オペレーションを複製するために、テーブルに主キーが必要です。
- 主キーを持つテーブルは、すべての INSERT、UPDATE、DELETE オペレーションを自動的に複製します。
- 主キーがないテーブルの場合、Database Migration Service は、CDC フェーズで初期スナップショットと後続の INSERT ステートメントを移行します。UPDATE ステートメントと DELETE ステートメントは手動で移行する必要があります。
  移行を開始する前に、主キーのないテーブルに主キーを追加することをおすすめします。PostgreSQL データベース内で主キーのないテーブルを一覧表示するクエリを作成する方法、または UPDATE オペレーションと DELETE オペレーションを手動で移行する方法については、デバッグとその他のツールをご覧ください。
  
  または、クイックスタート移行フローを使用することもできます。これは、REPLICA IDENTITY を使用して主キーのないテーブルを移行できる、簡素化された移行シナリオです。詳細については、クイックスタート移行を使用するガイドをご覧ください。
PostgreSQL バージョン 9.5 以前を実行しているソース: PostgreSQL バージョン 9.6 以前を実行しているソースインスタンスでは、レプリケーション遅延の指標を使用できません。この指標を使用して移行の進行状況を追跡する場合は、レプリケーション遅延を有効にするをご覧ください。
Cloud SQL 移行元インスタンスで、次のデータベースフラグを構成します。
1. cloudsql.logical_decoding を on に設定します。
2. cloudsql.enable_pglogical を on に設定します。
3. [wal_sender_timeout] を [0] に設定します。0 値は、非アクティブなレプリケーション接続を終了するタイムアウトメカニズムを無効にします。
4. max_replication_slots は、移行するデータベースの数に移行ジョブの数を掛けた値に、テーブル同期用の予約分を加えた値以上に設定します。
  たとえば、移行元インスタンスに 5 つのデータベースがあり、その移行元に 2 つの移行ジョブを作成する場合、レプリケーションスロットの数は 5 × 2 = 10 以上にする必要があります。これに加えて、他のタスクによって移行元ですでに使用されているレプリケーションスロットの数も必要です。調整されたデータダンプ並列処理設定を使用する場合は、レプリケーションスロットの数を増やし、移行ジョブの作成時に移行ジョブテストを実行して構成を確認してください。
  
  このフラグのデフォルト値は 10 です。
5. max_wal_senders は、max_replication_slots の値とインスタンスですでに使用されている送信者の数を合計した値以上に設定します。
  たとえば、max_replication_slots フラグが 10 に設定されていて、すでに 2 つの送信者を使用している場合、同時に実行される WAL 送信者プロセスの数は 10 + 2 = 12 になります。調整されたデータダンプ並列処理設定を使用する場合は、移行ジョブの作成時に移行ジョブテストを実行して、送信者の数を増やし、構成を確認してください。
  
  このフラグのデフォルト値は 10 です。
6. max_worker_processes は、移行するデータベースの数とインスタンス上の既存のワーカープロセスの数の合計以上に設定します。調整されたデータダンプの並列処理設定を使用する場合は、接続ごとに 2 つの追加ワーカープロセス（最大 20 ワーカー）を考慮してください。
  
  このフラグのデフォルト値は 8 です。
フラグの変更の詳細については、Cloud SQL ドキュメントのデータベースフラグを構成するをご覧ください。
データベースフラグの変更が有効になるように、移行元の Cloud SQL インスタンスを再起動します。

次のステップ

移行手順の詳細については、 Cloud SQL for PostgreSQL への移行を開始するをご覧ください。
移行元インスタンスと移行先インスタンス間のネットワーク接続を計画するには、ネットワーキングの概要をご覧ください。