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

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

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

このページでは、サポートされているすべてのソースのスタンドアロン手順について説明します。

セルフマネージド PostgreSQL（オンプレミスまたは Compute Engine VM 上）
Amazon RDS for PostgreSQL
Amazon Aurora for PostgreSQL
Cloud SQL for PostgreSQL

セルフホストの PostgreSQL ソースを構成する

継続的な移行のためにセルフホスト型の PostgreSQL 移行元インスタンス（オンプレミスまたは Compute Engine VM でホストされている）を構成するには、次の手順を完了します。

セルフホスト型の PostgreSQL ソースの場合、Database Migration Service は、テンプレートデータベース template0 と template1 を除く、移行元インスタンスのすべてのデータベースを移行します。
移行元インスタンスにデフォルトの postgres データベースが含まれていることを確認します。このデータベースが存在しない場合は、移行を構成する前に作成します。
pg_hba.conf ファイルでネットワーククライアント認証を構成します。移行先の AlloyDB for PostgreSQL クラスタの 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 は、AlloyDB for PostgreSQL でサポートされていない拡張機能を移行しません。ソースデータベースオブジェクトとアプリケーションクエリが、サポートされていない拡張機能を参照していないことを確認します。続行する前に、サポートされていない拡張機能と参照を移行元データベースから削除してください。
pg_cron 拡張機能は、Database Migration Service によって自動的に移行されませんが、AlloyDB for PostgreSQL の移行先でサポートされています。ソースデータベースで pg_cron を使用している場合は、移行をプロモートした後、移行先の AlloyDB for PostgreSQL クラスタに再インストールして構成します。
移行元インスタンスに移行専用のユーザーアカウントを作成し、必要な権限を付与します。
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 セキュリティグループの受信ルールを構成します。宛先の AlloyDB for PostgreSQL クラスタの IP アドレス範囲、VPC CIDR の範囲、またはリバース SSH 踏み台インスタンス VM からのポート 5432 での受信 TCP 接続を許可します。
ソースデータベースにインストールされている PostgreSQL 拡張機能を確認します。Database Migration Service は、AlloyDB for PostgreSQL でサポートされていない拡張機能を移行しません。ソースデータベースオブジェクトとアプリケーションクエリが、サポートされていない拡張機能を参照していないことを確認します。続行する前に、サポートされていない拡張機能と参照を移行元データベースから削除してください。
pg_cron 拡張機能は、Database Migration Service によって自動的に移行されませんが、AlloyDB for PostgreSQL の移行先でサポートされています。ソースデータベースで pg_cron を使用している場合は、移行をプロモートした後、移行先の AlloyDB for PostgreSQL クラスタに再インストールして構成します。
移行元インスタンスに移行専用のユーザーアカウントを作成し、必要な権限を付与します。
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;
```
要件の詳細については、AWS ドキュメントの Amazon RDS for PostgreSQL で PostgreSQL 拡張機能を使用するをご覧ください。

注: pglogical 拡張機能は、移行元インスタンスのデータベースログにログイン認証情報を書式なしテキストで記録できます。これは拡張機能自体の既知の動作であり、Database Migration Service や AlloyDB for PostgreSQL とは関係ありません。
テーブルに主キーがあることを確認します。継続的な移行の場合、PostgreSQL の論理レプリケーションでは、変更データキャプチャ（CDC）フェーズで UPDATE オペレーションと DELETE オペレーションを複製するために、テーブルに主キーが必要です。
- 主キーを持つテーブルは、すべての INSERT、UPDATE、DELETE オペレーションを自動的に複製します。
- 主キーがないテーブルの場合、Database Migration Service は、CDC フェーズでの初期スナップショットと後続の INSERT ステートメントの移行のみをサポートします。UPDATE ステートメントと DELETE ステートメントは手動で移行する必要があります。
  移行を開始する前に、主キーのないテーブルに主キーを追加することをおすすめします。PostgreSQL データベース内で主キーのないテーブルを一覧表示するクエリを作成する方法、または UPDATE オペレーションと DELETE オペレーションを手動で移行する方法については、デバッグとその他のツールをご覧ください。
  
  または、クイックスタート移行フローを使用することもできます。これは、REPLICA IDENTITY を使用して主キーのないテーブルを移行できる、簡素化された移行シナリオです。詳細については、クイックスタート移行を使用するガイドをご覧ください。
カスタム 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 PostgreSQL ソースを構成する

継続的な移行用に Amazon Aurora PostgreSQL ソースクラスタを構成するには、次の手順を完了します。

Amazon Aurora for PostgreSQL ソースの場合、Database Migration Service は、テンプレートデータベース template0、template1、AWS 内部データベース rdsadmin を除く、ソースクラスタ内のすべてのデータベースを移行します。
ソースクラスタにデフォルトの postgres データベースが含まれていることを確認します。このデータベースが存在しない場合は、移行を構成する前に作成します。
Amazon Aurora クラスタの VPC セキュリティグループの受信ルールを構成します。宛先の AlloyDB for PostgreSQL クラスタの IP アドレス範囲、VPC CIDR の範囲、またはリバース SSH 踏み台インスタンス VM からのポート 5432 での受信 TCP 接続を許可します。
ソースデータベースにインストールされている PostgreSQL 拡張機能を確認します。Database Migration Service は、AlloyDB for PostgreSQL でサポートされていない拡張機能を移行しません。ソースデータベースオブジェクトとアプリケーションクエリが、サポートされていない拡張機能を参照していないことを確認します。続行する前に、サポートされていない拡張機能と参照を移行元データベースから削除してください。
pg_cron 拡張機能は、Database Migration Service によって自動的に移行されませんが、AlloyDB for PostgreSQL の移行先でサポートされています。ソースデータベースで pg_cron を使用している場合は、移行をプロモートした後、移行先の AlloyDB for PostgreSQL クラスタに再インストールして構成します。
ソースクラスタに移行専用のユーザーアカウントを作成し、必要な権限を付与します。
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 や AlloyDB for PostgreSQL とは関係ありません。
テーブルに主キーがあることを確認します。継続的な移行の場合、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 クラスタを再起動します。

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

継続的な移行用に Cloud SQL for PostgreSQL ソースインスタンスを構成するには、次の手順を完了します。

Cloud SQL for PostgreSQL の移行元の場合、Database Migration Service は、テンプレートデータベース template0 と template1 を除く、移行元インスタンスのすべてのデータベースを移行します。
移行元インスタンスにデフォルトの postgres データベースが含まれていることを確認します。このデータベースが存在しない場合は、移行を構成する前に作成します。
プライベート IP アドレスで構成された Cloud SQL 移行元インスタンスから、RFC 1918 以外のアドレス IP 範囲を使用する移行先の AlloyDB for PostgreSQL クラスタに移行する場合は、RFC 1918 以外の範囲を移行元インスタンスの承認済みネットワークに追加します。詳細については、承認済みネットワークを構成するをご覧ください。
ソースデータベースにインストールされている PostgreSQL 拡張機能を確認します。Database Migration Service は、 AlloyDB for PostgreSQL でサポートされていない拡張機能を移行しません。ソースデータベースオブジェクトとアプリケーションクエリが、サポートされていない拡張機能を参照していないことを確認します。続行する前に、サポートされていない拡張機能と参照をソースデータベースから削除します。
pg_cron 拡張機能は、Database Migration Service によって自動的に移行されませんが、AlloyDB for PostgreSQL の移行先でサポートされています。ソースデータベースで pg_cron を使用している場合は、移行をプロモートした後、移行先の AlloyDB for PostgreSQL クラスタに再インストールして構成します。
移行元インスタンスに移行専用のユーザーアカウントを作成し、必要な権限を付与します。
1. Cloud SQL ドキュメントのユーザーを作成するページの手順に沿って、ユーザーアカウントを作成します。
2. 移行ユーザーアカウントに cloudsqlsuperuser ロールを付与します。
```
GRANT cloudsqlsuperuser TO "MIGRATION_USER_ACCOUNT_NAME";
```
3. 移行ユーザーアカウントに、デフォルトの 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 拡張機能をインストールします。以下のコマンドを実行します。
```
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 を使用して主キーのないテーブルを移行できる、簡素化された移行シナリオです。詳細については、クイックスタート移行を使用するガイドをご覧ください。
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 インスタンスを再起動して、データベースフラグの変更を有効にします。

次のステップ

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