クイック スタート移行を使用して AlloyDB for PostgreSQL に移行する

MySQL   |  PostgreSQL   |  PostgreSQL to AlloyDB

プレビュー

この機能は、サービス固有規約の「一般サービス規約」セクションの「一般提供前のサービス規約」の対象となります。pre-GA の機能は「現状のまま」で提供されるものであり、サポートが制限されることがあります。 詳細については、リリース ステージの説明をご覧ください。

このページでは、同種 PostgreSQL 移行から AlloyDB for PostgreSQL へのクイック スタート移行を行う方法について説明します。

概要

クイック スタート移行は、同種 PostgreSQL シナリオ向けの軽量な継続的移行フローです。クイック スタート移行を使用すると、Database Migration Service は、データベースの移行に必要なすべてのもの（ネットワーキング コンポーネント（ネットワーク アタッチメント、サブネット、プライベート接続構成）、接続プロファイル、移行ジョブ）を自動的に設定できます。

クイック スタート移行では、既存の AlloyDB for PostgreSQL クラスタにデータを移動するか、移行の構成時に新しいクラスタを作成できます。クイック スタート移行は、次の場合に最適です。

• データダンプの並列処理設定を正確に制御する必要がない基本的な移行。
• データベースをある Google Cloud プロジェクトから別のプロジェクトに移行する。クイック スタート移行を構成するときに、移行元とは異なるプロジェクトに移行先クラスタを作成し、別のプロジェクトの Virtual Private Cloud（VPC）ネットワークにネットワーク アタッチメントとサブネットを作成するように Database Migration Service を設定できます。

• Google CloudVirtual Private Cloud（VPC）ネットワークにプライベート IP アドレスがあるソースからの移行。たとえば、Compute Engine 上のセルフマネージド データベースや、プライベート ネットワーキングが有効になっている Cloud SQL for PostgreSQL インスタンスなどです。

  外部でホストされているソース Google Cloud は、VPC ネットワーク内のプライベート IP アドレスでアクセスできるように、追加のネットワーク コンポーネント（Cloud VPN 接続など）が必要になる場合があります。

• データベース接続でサポートされている方法は、Database Migration Service のプライベート接続構成を使用した Private Service Connect インターフェースのみです。ソース データベースには、VPC ネットワークで割り当てられたプライベート IP が必要です。他の同種移行元接続方法（パブリック IP 許可リスト、リバース SSH トンネル、VPC ピアリングなど）は、クイック スタート移行ではサポートされていません。

クイック スタート移行の詳細については、Database Migration Service のメイン ドキュメントの クイック スタート移行の概要をご覧ください。

始める前に

1. クイック スタートの移行でシナリオを完全にサポートできるかどうかを確認します。 クイック スタート移行の制限事項をご覧ください。
Google アカウントにログインします。

Google アカウントをまだお持ちでない場合は、新しいアカウントを登録します。

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

2. Database Migration Service、Compute Engine、Network Connectivity Center、AlloyDB for PostgreSQL Admin の各 API を有効にします。

   API を有効にする

必要なロール

Database Migration Service を使用して AlloyDB for PostgreSQL へのクイック スタート移行を実行するために必要な権限を取得するには、関連するプロジェクトで、移行に関与するアカウントに必要な Identity and Access Management（IAM）ロールを付与するよう管理者に依頼してください。ロールの付与の詳細については、IAM ドキュメントの アクセス権の管理をご覧ください。

重要: ロールはこれらのアカウントに直接割り当てる必要があります。Google グループのグループ メンバーを通じて継承されたロールは、クイック スタート移行ではサポートされていません。

移行元プロジェクトのロールと権限

ソース データベースが存在する Google Cloud プロジェクトの特定のアカウントに、次のロールを付与します。

• 移行を実行するユーザー アカウントの場合: Compute ネットワーク管理者ロール（roles/compute.networkAdmin）
• 宛先プロジェクトの Database Migration Service サービス アカウントの場合: Compute ネットワーク閲覧者（roles/compute.networkViewer）

  Database Migration Service サービス アカウントは、Database Migration Service API を有効にしたときに作成されます。このアカウントに関連付けられたメールアドレスは自動的に生成され、変更できません。このメールアドレスの形式は次のとおりです。

  [e-mail]

これらの事前定義ロールには、Database Migration Service を使用したクイック スタート移行の一環として、移行元データベース プロジェクトで接続を設定するために必要な権限が含まれています。必要とされる正確な権限については、「必要な権限（ソース）」セクションを開いてご確認ください。

必要な権限（ソース）

Database Migration Service で同種のクイック スタート移行を行うには、次の権限が必要です。

移行を実行するユーザー アカウントの場合:

• compute.networks.*
• compute.subnetworks.*
• compute.networkAttachments.*

宛先プロジェクトの Database Migration Service サービス アカウントの場合: compute.networkAttachments.get。

移行先プロジェクトのロールと権限

移行を実行するユーザー アカウントに、宛先データベースが存在する Google Cloud プロジェクトで次のロールを付与します。

• データベース移行管理者（roles/datamigration.admin）
• AlloyDB 管理者（roles/alloydb.admin）

これらの事前定義ロールには、Database Migration Service を使用したクイック スタート移行の一環として、移行先データベース プロジェクトに必要な移行コンポーネントを設定するために必要な権限が含まれています。必要とされる正確な権限については、「必要な権限（宛先）」セクションを開いてご確認ください。

必要な権限（宛先）

Database Migration Service で同種のクイック スタート移行を行うには、次の権限が必要です。

• datamigration.*
• alloydb.clusters.create
• alloydb.clusters.get
• alloydb.clusters.list
• alloydb.clusters.update
• alloydb.clusters.delete
• alloydb.instances.create
• alloydb.instances.get
• alloydb.instances.list
• alloydb.instances.update
• alloydb.instances.delete
• alloydb.instances.executeSql
• alloydb.operations.get
• alloydb.users.list
• alloydb.users.get
• alloydb.users.create
• alloydb.users.update
• alloydb.users.delete

ソース データベースの構成

移行元の PostgreSQL データベースを構成する手順は次のとおりです。

1. インスタンスに移行専用のユーザー アカウントを作成します。
   • Cloud SQL for PostgreSQL ソースについては、Cloud SQL ドキュメントの ユーザーを作成するをご覧ください。
   • 他のソースについては、データベース プロバイダのドキュメントまたは PostgreSQL ドキュメントの ユーザーの作成と管理をご覧ください。
2. 移行専用のユーザー アカウントに必要な権限を割り当てます。移行するデータベースごとに、次のコマンドを実行します。

   -- Grant the REPLICATION attribute
   ALTER ROLE MIGRATION_USER REPLICATION;
   
   -- Grant database-level permissions.
   -- Repeat for each database you want to migrate.
   GRANT CONNECT, CREATE ON DATABASE DATABASE_NAME TO MIGRATION_USER;
   
   -- Grant schema-level usage.
   -- Repeat for each schema in each database you want to migrate.
   GRANT USAGE ON SCHEMA SCHEMA_NAME TO MIGRATION_USER;

   次のように置き換えます。

   • MIGRATION_USER は、移行ユーザー アカウントの名前に置き換えます。
   • DATABASE_NAME は、移行するデータベースの名前に置き換えます。
   • SCHEMA_NAME は、移行するデータベースのスキーマの名前に置き換えます。
3. 移行ユーザー アカウントには、移行するテーブルに対する所有権アクセス権が必要です。このレベルのアクセス権を付与するには、次のいずれかを行います。
   • 移行アカウントに SUPERUSER PostgreSQL ロールを割り当てます。
     • Cloud SQL for PostgreSQL ソースの場合は、cloudsqlsuperuser ロールを割り当てます。
     • 他のソースについては、 SUPERUSER ロールを割り当てるか、同等の権限セットについてデータベース プロバイダのドキュメントをご覧ください。
   • 移行ユーザー アカウントを、テーブルを所有するユーザー グループに追加します。次のコマンドを実行します。

     -- Grant table ownership.
     GRANT TABLE_OWNER_GROUP_NAME TO MIGRATION_USER;

     次のように置き換えます。

     • TABLE_OWNER_GROUP_NAME は、移行する各テーブルを所有するユーザー グループの名前に置き換えます。
     • MIGRATION_USER は、移行ユーザー アカウントの名前に置き換えます。
4. 主キーのないテーブルの場合: Database Migration Service は、変更データ キャプチャ（CDC）フェーズで主キーのないテーブルの UPDATE オペレーションまたは DELETE オペレーションを複製しません。このようなオペレーションをレプリケーションに含める場合は、REPLICA IDENTITY を使用して主キーのないテーブルを変更します。

   ALTER TABLE TABLE_NAME REPLICA IDENTITY FULL;
   ALTER TABLE TABLE_NAME REPLICA IDENTITY USING INDEX INDEX_NAME;

   次のように置き換えます。

   • TABLE_NAME は、主キーのないテーブルの名前です。
   • INDEX_NAME は、主キーのないテーブルの行を追跡できる一意のインデックスです。
5. データベース フラグを使用してレプリケーション設定を構成します。

   セルフマネージド ソース

   データベース フラグの変更を保存するには、データベースの完全な再起動が必要です。次の例では、フラグ値を変更する SQL クエリを使用します。SQL クエリを直接実行できない場合は、プロバイダのドキュメントでこれらのフラグを変更する手順をご確認ください。

   1. wal_level パラメータを logical に設定します。次のコマンドを実行します。

      ALTER SYSTEM SET wal_level = 'logical';

   2. wal_sender_timeout パラメータを 0 に設定します。この値は、非アクティブなレプリケーション接続を終了するために使用するタイムアウト メカニズムを無効にします。次のコマンドを実行します。

      ALTER SYSTEM SET wal_sender_timeout = 0;
          

   3. max_replication_slots パラメータを使用して、レプリケーション スロットの最大数を構成します。このパラメータには、移行ジョブごとに移行するデータベースの数とテーブル同期用の予約分を合計した値を設定する必要があります。

      たとえば、5 つのデータベースを移行し、移行元インスタンスに 2 つの移行ジョブが作成されている場合、レプリケーション スロットの数は、すでに使用されているレプリケーション スロットの数に加えて、少なくとも 5 * 2 = 10 にする必要があります。

      このパラメータを設定するには、次のコマンドを実行します。

      ALTER SYSTEM SET max_replication_slots = NUMBER_OF_SLOTS;
          

      ここで、NUMBER_OF_SLOTS はレプリケーション スロットの最大数を表します。
   4. max_wal_senders パラメータは、max_replication_slots とインスタンスですでに使用されている送信者の数を合計した値以上に設定します。

      たとえば、max_replication_slots パラメータが 10 に設定されていて、すでに 2 つの送信者を使用している場合、同時に実行される WAL 送信者プロセスの数は 10 + 2 = 12 になります。

      このパラメータを設定するには、次のコマンドを実行します。

      ALTER SYSTEM SET max_wal_senders = NUMBER_OF_SENDERS;
          

      ここで、NUMBER_OF_SENDERS は同時に実行されている WAL 送信者プロセスの数を表します。
   5. max_worker_processes は、移行するデータベースの数と、インスタンスですでに使用されている max_worker_processes の数を合計した値以上に設定します。このパラメータを設定するには、次のコマンドを実行します。

      ALTER SYSTEM SET max_worker_processes = NUMBER_OF_PROCESSES;
          

      ここで、NUMBER_OF_PROCESSES は移行されるデータベースの数を表します。

   Cloud SQL for PostgreSQL ソース

   Cloud SQL の移行元の場合、 Google Cloud コンソールでデータベース フラグを構成します。設定を有効にするには、データベース フラグを変更した後にインスタンスを再起動する必要があります。Cloud SQL でデータベース フラグを設定する方法については、Cloud SQL ドキュメントのデータベース フラグを構成するをご覧ください。

   1. cloudsql.logical_decoding フラグを on に設定します。
   2. wal_sender_timeout パラメータを 0 に設定します。この値は、非アクティブなレプリケーション接続を終了するために使用するタイムアウト メカニズムを無効にします。
   3. max_replication_slots パラメータを使用して、レプリケーション スロットの最大数を構成します。このパラメータには、移行ジョブごとに移行するデータベースの数とテーブル同期用の予約分を合計した値を設定する必要があります。

      たとえば、5 つのデータベースを移行し、移行元インスタンスに 2 つの移行ジョブが作成されている場合、レプリケーション スロットの数は、すでに使用されているレプリケーション スロットの数に 5 * 2 = 10 を加えた数以上にする必要があります。

   4. max_wal_senders パラメータを、max_replication_slots とインスタンスですでに使用されている送信者の数を合計した値以上に構成します。

      たとえば、max_replication_slots パラメータが 10 に設定されていて、すでに 2 つの送信者を使用している場合、同時に実行される WAL 送信者プロセスの数は 10 + 2 = 12 になります。

   5. max_worker_processes は、移行するデータベースの数と、インスタンスですでに使用されている max_worker_processes の数を合計した値以上に設定します。

クイック スタート移行を作成して実行する

クイック スタートの移行を作成して実行する手順は次のとおりです。

1. Google Cloud コンソールで、[スタートガイド] ページに移動します。

   [スタートガイド] に移動

2. [移行元エンジン] メニューで、[PostgreSQL] を選択します。
3. [移行先エンジン] メニューで、[AlloyDB for PostgreSQL] を選択します。

   [クイック スタート PostgreSQL 移行の紹介] セクションが表示されます。

4. [クイック スタート PostgreSQL 移行の紹介] セクションで、[移行を開始] をクリックします。

   [AlloyDB for PostgreSQL への移行] ページが開きます。

5. [移行を構成する] セクションで、次の操作を行います。
   1. [移行先リージョン] メニューから、移行先 AlloyDB for PostgreSQL クラスタのリージョンを選択します。
   2. [移行接頭辞] ボックスに、クイック スタート移行用に作成されたすべての移行エンティティ（接続プロファイル、プライベート接続構成、ネットワーク アタッチメントとそのサブネット、移行ジョブ）の名前に追加される人間が読みやすい文字列を入力します。
   3. [構成タイプ] メニューから、次のいずれかを選択します。
      1. 既存の接続構成: Private Service Connect インターフェース メソッドを使用するネットワーク アタッチメントとプライベート接続構成がすでにある場合は、このオプションを選択します。このオプションは、以前にクイック スタート移行を使用し、同じネットワーキング リソースを再利用する場合に最適です。
      2. 新しい接続構成: このオプションを選択すると、移行元データベースの VPC ネットワークに新しいネットワーク アタッチメントとネットワーク アタッチメント サブネットが作成されます。プライベート接続構成は、宛先クラスタと同じプロジェクトに作成されます。
   [続行] をクリックします。
6. [ソースを接続] セクションで、次の操作を行います。
   1. ソース データベースのホスト名またはプライベート IP アドレスを入力します。ソース データベースのアドレスが、ソース VPC ネットワークから到達可能である必要があります。
   2. ホストへのアクセスに使用するポートを入力します。デフォルトの PostgreSQL ポートは 5432 です。
   3. 移行元データベースの移行専用アカウントのユーザー名とパスワードを入力します。
   4. [暗号化タイプ] メニューから、次のいずれかを選択します。
      • なし: 移行元データベースで SSL/TLS 暗号化接続が必要ない場合。
      • 必須: ソース データベースで SSL/TLS 暗号化接続が必要な場合。このオプションでは、証明書の検証は必要ありません。
   5. [移行するデータベース] メニューで、[カスタマイズ] をクリックします。サイドパネルを使用して、AlloyDB for PostgreSQL に移行するデータベースのみを選択します。
   [続行] をクリックします。
7. [転送先を構成] セクションで、新しい転送先クラスタを作成するか、既存のクラスタを選択できます。

   新しいクラスタ

   新しい移行先クラスタを作成する場合は、次の操作を行います。

   1. [移行先インスタンス タイプ] メニューから、[新しいクラスタ] を選択します。

      Database Migration Service は、新しいクラスタにデフォルトの AlloyDB for PostgreSQL 構成を使用します。[カスタマイズ] をクリックして、マシンタイプ、ゾーンの可用性、データ保護設定などのクラスタ機能を調整します。クラスタ構成の詳細については、AlloyDB for PostgreSQL ドキュメントの クラスタとそのプライマリ インスタンスを作成するをご覧ください。

   2. [パスワード] フィールドに、デフォルトの postgresql 管理ユーザーのパスワードを入力します。Database Migration Service は、このユーザーとして接続してデータを移行します。

   既存のクラスタ

   既存のクラスタにデータベースを移行できます。宛先クラスタで Private Service Connect が有効になっており、AlloyDB コネクタで mTLS が強制適用されていないことを確認します。手順は次のとおりです。

   1. [移行先インスタンス タイプ] メニューから、[既存のクラスタ] を選択します。
   2. [既存のクラスタ ID] メニューから、クラスタ識別子を選択します。
8. [移行を開始 ]をクリックします。

   Database Migration Service が移行ジョブを作成し、移行プロセスを開始します。AlloyDB for PostgreSQL では、移行の進行状況と移行先クラスタの健全性をモニタリングできます。詳細については、AlloyDB for PostgreSQL のドキュメントの インスタンスの詳細を表示するをご覧ください。

移行を完了する

アプリケーションを新しい AlloyDB for PostgreSQL インスタンスに切り替える場合は、次の手順で移行を完了します。

1. 移行元データベースに対するすべての書き込みオペレーションを停止します。読み取り専用モードに切り替えて、運用機能を維持できます。
2. 移行ジョブをプロモートします。
3. 省略可: 移行データの完全性を 検証する。

次のステップ

• AlloyDB for PostgreSQL の詳細。