クラスタのメジャーサーバーバージョンをアップグレードする

このページでは、データベースサーバーバージョンを更新する AlloyDB for PostgreSQL のプロセスと、新しいバージョンの PostgreSQL と互換性のあるクラスタにデータを移行する方法について説明します。

クラスタの作成方法の詳細については、クラスタとそのプライマリインスタンスを作成するをご覧ください。

クラスタと PostgreSQL バージョンの互換性

AlloyDB クラスタを作成するときに、クラスタ内のインスタンスと互換性のある PostgreSQL のメジャーバージョンを選択します。デフォルトは 15 です。

AlloyDB は、定期メンテナンス中にデータベースのマイナーバージョンの自動アップグレードを実行します。たとえば、メジャーバージョン 15 を選択してクラスタを作成した場合、AlloyDB はデータベースサーバーをメジャーバージョン 15 の最新のマイナーバージョンにアップグレードします。

ただし、PostgreSQL バージョンのメジャーバージョンアップグレードでは、アップグレードの計画、テスト、実行をユーザー自身で行う必要があります。

クラスタのメジャーバージョンのアップグレードを行う方法はいくつかあります。

メジャーバージョンのインプレースアップグレードを使用することをおすすめします。
ファイルベースのデータエクスポートを使用したデータの移行。
Database Migration Service の使用。

各アップグレード方法には、それぞれ異なるメリットとデメリットがあります。次の表に、シナリオに適したアプローチを選択できるように、簡単な比較を示します。

インプレースメジャーバージョンアップグレード	ファイルベースのデータエクスポート	Database Migration Service による移行
読み取りインスタンスを含むクラスタが、選択した上位のメジャーバージョンにアップグレードされます。	ファイルベースのエクスポートでは、データベースのワンタイムスナップショットが移行されます。	Database Migration Service は、移行プロセス中に継続的なレプリケーション機能を提供します。このため、新しいクラスタでデータが欠落する可能性が低くなります。
アップグレード前のステージでもクラスタでの作業を継続できます。	アプリケーションのダウンタイムが長くなります。このダウンタイムは、データのエクスポート時に開始します。新しいクラスタが完全に動作するまで、元のクラスタでデータベースの書き込みを受け入れることはできません。	アプリケーションのダウンタイムが短くなります。このダウンタイムは、アプリケーションで新しいクラスタに切り替えるときに開始します。
アップグレードプロセス中は、スキーマに応じて 20 分以上のダウンタイムが発生する可能性があります。アップグレード後、同じ IP アドレスを使用してクラスタにアクセスできます。	エクスポートするデータをより細かく制御できます。特定のテーブルやその他のエンティティを移行の対象外にすることもできます。	Database Migration Service は、インスタンス内のすべてのデータベースとクラスタ内のすべてのインスタンスを自動的に移行します。特定のテーブルまたはビューを移行対象から除外することはできません。
	クラスタで SSL 適用モードが有効になっている場合があります。	移行で Database Migration Service を使用する場合は、移行元クラスタで SSL 適用モードを無効にする必要があります。

次のセクションでは、データの移行など、メジャーバージョンのアップグレードプロセスについて詳しく説明します。

インプレースメジャーバージョンアップグレード

この方法では、追加のクラスタを設定しなくても、シームレスなアップグレードエクスペリエンスを実現できます。詳細については、データベースのメジャーバージョンをインプレースでアップグレードするをご覧ください。

ファイルベースのデータエクスポートを使用した移行

新しいメジャーバージョンの PostgreSQL と互換性のあるデータベースサーバーを使用するには、機能的に同等のクラスタを同じリージョンに作成し、そのクラスタにデータを移行する必要があります。

手順は次のとおりです。

互換性のある PostgreSQL のメジャーバージョンで構成されたクラスタを作成します。現在のクラスタと同じリージョンにクラスタを作成します。
現在のクラスタの構成に合わせて、新しいメジャーバージョンで新しいクラスタを設定します。
1. 必要に応じて読み取りプールインスタンスを追加します。
2. 必要に応じてセカンダリクラスタを作成します。
  
  セカンダリクラスタを作成する場合、PostgreSQL のメジャーバージョン番号を指定する必要はありません。AlloyDB は、プライマリクラスタの PostgreSQL バージョンをすべてのセカンダリクラスタに適用します。
3. 現在のクラスタのフラグ設定と一致するように、新しいクラスタのデータベースフラグを更新します。
4. アプリケーションで必要な拡張機能を有効にします。
psql または pg_dump を使用して、古いクラスタからファイルにデータをエクスポートします。
ファイルから新しいクラスタにデータをインポートします。

これで、アプリケーションが新しい IP アドレスで新しいクラスタのインスタンスに接続できるようになりました。

Database Migration Service を使用した移行

Database Migration Service を使用して、PostgreSQL データベースから AlloyDB クラスタにデータを移行できます。Database Migration Service には、AlloyDB データソース専用の構成はありませんが、AlloyDB は PostgreSQL と互換性があるため、汎用の PostgreSQL ソース向けの構成を使用できます。

この移行方法はインプレースアップグレードではありません。別の IP アドレスを持つ新しいクラスタを作成します。最初にクラスタのクローンを作成して、テスト移行を実施し、アプリケーションがこの方法で移行可能かどうか確認することをおすすめします。

重要な考慮事項

Database Migration Service を使用した移行の準備を進める前に、次の制限事項を慎重に検討し、この移行方法がアップグレードシナリオに適していることを確認してください。

制限事項

移行元クラスタで SSL 接続を無効にする必要があります。
Private Service Connect で構成された AlloyDB インスタンスはサポートされていません。
移行中、移行元クラスタでインスタンスの更新やフェイルオーバーリクエストは実行できません。これらのオペレーションにより、移行ジョブが失敗する可能性があります。
このシナリオには、PostgreSQL から AlloyDB への移行の標準的な制限がすべて適用されます。その他の制限事項については、Database Migration Service のドキュメントの既知の制限事項をご覧ください。

移行の忠実性

ラージオブジェクトなど、特定のデータ型は移行されません。サポートされているデータについては、Database Migration Service のドキュメントの移行の忠実度をご覧ください。

移行元データベースのロックアウトとダウンタイム

Database Migration Service は、継続的な移行によりデータを AlloyDB クラスタに移行します。このタイプの移行では、最初のデータダンプを作成するときに、移行元データベースのテーブルが 1 つずつ短時間（10 秒未満）ロックされます。

移行が完了したら、アプリケーションを新しいクラスタに切り替える前に、移行元データベースでの書き込みをすべて停止する必要があります。この方法ではダウンタイムが発生します。詳細な概要については、Database Migration Service のドキュメントの継続的な移行をご覧ください。

レプリケーションの制限事項

移行ジョブが変更データキャプチャ（CDC）フェーズに入ると、Database Migration Service は移行元データベースに書き込まれた新しいデータを継続的に複製します。

主キーのないテーブルの場合、CDC フェーズで INSERT ステートメントのみが複製されます。データの損失を回避するため、CDC フェーズ中に主キーのないテーブルに対して実行された CREATE、UPDATE、または DELETE アクションは、宛先データベースで手動で再作成する必要があります。

始める前に

Enable the Database Migration Service API.
Enable the API

Make sure that you have the following role or roles on the project:
- One of the following:
  - Cloud AlloyDB > Cloud AlloyDB admin
  - Basic > Owner
  - Basic > Editor
- You must also have the compute.networks.list permission in the Google Cloud project you are using. To gain this permission while following the principle of least privilege, ask your administrator to grant you the Compute Engine > Compute Network User role (roles/compute.networkUser).
- Database Migration admin
Check for the roles
1. In the Google Cloud console, go to the IAM page.
  Go to IAM
2. Select the project.
3. In the Principal column, find all rows that identify you or a group that you're included in. To learn which groups you're included in, contact your administrator.
4. For all rows that specify or include you, check the Role column to see whether the list of roles includes the required roles.
Grant the roles
1. In the Google Cloud console, go to the IAM page.
  [IAM] に移動
2. プロジェクトを選択します。
3. [ アクセスを許可] をクリックします。
4. [新しいプリンシパル] フィールドに、ユーザー ID を入力します。これは通常、Google アカウントのメールアドレスです。
5. [ロールを選択] リストでロールを選択します。
6. 追加のロールを付与するには、 [別のロールを追加] をクリックして各ロールを追加します。
7. [保存] をクリックします。
使用している Google Cloud プロジェクトの VPC ネットワークが、AlloyDB に対するプライベートサービスアクセス用に構成されていることを確認します。
宛先クラスタを作成するリージョンを決定します。Database Migration Service のエンティティ（接続プロファイル、移行ジョブ）はすべて、宛先クラスタと同じリージョンに作成する必要があります。
クラスタに接続し、移行元データベースで移行ステートメントを実行するデータベースユーザーを準備します。このデータベースユーザーには、特定の権限とロールが必要です。新しいデータベースユーザーを作成し、移行専用に指定することをおすすめします。

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

Database Migration Service で移行元クラスタから新しい宛先クラスタに接続してデータをコピーできるようにするには、特定の構成が必要です。

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

移行元クラスタ内のすべてのインスタンスでデータベースフラグを構成します。次の値を使用します。

フラグ	値
`alloydb.logical_decoding`	`on` に設定します。
`alloydb.enable_pglogical`	`on` に設定します。
`max_replication_slots`	このフラグは、移行元インスタンスがサポートできるレプリケーションスロットの最大数を定義します。このフラグの最小値は `50` です。最小値は次の式で計算します。 `(the number of databases in your instance) * (the number of simultaneous migration jobs you want to perform) + (slots reserved for table synchronization) + (the number of replication slots you currently use for your read replicas)` 次のような例について考えてみましょう。移行元にリードレプリカがない。プライマリソースインスタンスに 30 個のデータベースがある。移行元クラスタに 2 つの移行ジョブを作成したい。テーブルレプリケーションに 10 個のスロットを使用したい。このような場合、`max_replication_slots` の数は `30 * 2 + 10 + 0` として計算される `70` 以上にする必要があります。
`max_wal_senders`	このフラグは、`max_replication_slots` の値とインスタンスですでに使用されている送信者の数を合計した値より 10 以上大きい値に設定します。たとえば、`max_replication_slots flag` を `70` に設定し、すでに 2 つの送信者を使用している場合、`max_wal_senders` は少なくとも `82` にする必要があります（`70 + 10 + 2 = 82` として計算）。
`max_worker_processes`	このフラグは、インスタンス内のデータベース数と、すでに使用している `max_worker_processes` の数の合計以上に設定します。たとえば、移行元インスタンスに 30 個のデータベースがあり、ワーカープロセスを使用しない場合は、このフラグを `30` に設定します。

移行元クラスタ内のすべてのインスタンスで SSL 適用モードを無効にします。

移行元データベースを構成する

pglogical 拡張機能をインストールし、インスタンス内のすべてのデータベースで移行ユーザーとして指定したデータベースユーザーに必要な権限を付与する必要があります。

データベースの構成手順は次のとおりです。

psql クライアントを使用して、デフォルトの postgres データベースに接続します。
次のコマンドを実行して pglogical 拡張機能をインストールします。
```
CREATE EXTENSION IF NOT EXISTS pglogical;
```
information スキーマと名前が pg_ 接頭辞で始まるスキーマを除き、すべてのスキーマに対する権限を移行データベースユーザーに付与します。次のステートメントを実行します。
```
GRANT USAGE on SCHEMA SCHEMA_NAME to USER_NAME;
GRANT SELECT on ALL TABLES in SCHEMA SCHEMA_NAME to USER_NAME;
GRANT SELECT on ALL SEQUENCES in SCHEMA SCHEMA_NAME to USER_NAME;
```
次のように置き換えます。
- SCHEMA_NAME: データベースにあるスキーマの名前
- USER_NAME: 始める前にで準備したデータベースユーザーの名前
information スキーマと名前が pg_ 接頭辞で始まるスキーマを除き、データベース内のすべてのスキーマに対してこの手順を繰り返します。すべてのデータベーススキーマの一覧を取得するには、\dn メタコマンドを使用します。
残りの必要な権限を付与します。次のステートメントを実行します。
```
GRANT USAGE on SCHEMA pglogical to PUBLIC;
GRANT SELECT on ALL TABLES in SCHEMA pglogical to USER_NAME;
ALTER USER USER_NAME with REPLICATION;
```
USER_NAME は、始める前にで準備したデータベースユーザーの名前に置き換えます。
インスタンス内の残りのすべてデータベースに接続し、手順 2、3、4 を繰り返します。
- インスタンス内のすべてのデータベースの一覧を取得するには、\list メタコマンドを使用します。
- psql のクライアント接続をリセットせずに別のデータベースに切り替えるには、\connect {database_name_here} コマンドを使用します。
移行元の AlloyDB クラスタ内のすべてのインスタンスに対してこの手順を繰り返します。

Database Migration Service で移行を実行する