このページは Cloud Translation API によって翻訳されました。

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

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

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

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

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

クラスタのメンテナンスオペレーション中、AlloyDB はマイナーデータベースバージョンアップグレードのみを実行します。たとえば、15 互換性でクラスタを作成した場合、AlloyDB はデータベースサーバーを利用可能な 15 の最新バージョンにアップグレードし続けます。

AlloyDB が自動的に実行するマイナーバージョンアップグレードとは異なり、メジャーバージョンアップグレードでは、アップグレードの計画、テスト、実行を自分で行う必要があります。AlloyDB はデータベースのメジャーバージョンのインプレースアップグレードをサポートしていないため、このプロセスではデータをクラスタ間で移行する必要があります。

メジャーバージョンのアップグレードは、ファイルベースのデータエクスポートを使用してデータを移動するか、Database Migration Service を使用することで実行できます。各ソリューションには異なる利点があり、異なる課題が生じる可能性があります。次の表に、シナリオに適したアプローチを選択するための簡単な比較を示します。

ファイルベースのデータエクスポート	Database Migration Service を使用した移行
ファイルベースのエクスポートでは、データベースの 1 回限りのスナップショットが移動されます。	Database Migration Service は、移行プロセス中に継続的なレプリケーション機能を提供するため、新しいクラスタでデータが欠落する可能性を低減します。
データのエクスポート時にアプリケーションのダウンタイムが長くなります。新しいクラスタが完全に動作するまで、元のクラスタでデータベースの書き込みを受け入れることはできません。	アプリケーションのダウンタイムが短縮されます。ダウンタイムは、アプリケーションを新しいクラスタを使用するように切り替えるときに開始されます。
エクスポートに含めるデータをより細かく制御でき、特定のテーブルやその他のエンティティを移行しないように選択できます。	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

In the Google Cloud console, go to the IAM page.
Go to IAM
Select the project.
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.
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

In the Google Cloud console, go to the IAM page.
[IAM] に移動
プロジェクトを選択します。
[ アクセスを許可] をクリックします。
[新しいプリンシパル] フィールドに、ユーザー ID を入力します。これは通常、Google アカウントのメールアドレスです。
[ロールを選択] リストでロールを選択します。
追加のロールを付与するには、 [別のロールを追加] をクリックして各ロールを追加します。
[保存] をクリックします。
使用している 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` の数は `70` 以上（`30 * 2 + 10 + 0` として計算）にする必要があります。
`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 で移行を実行する