# メジャーバージョンアップグレードの実行
<a name="USER_UpgradeDBInstance.PostgreSQL.MajorVersion"></a>

メジャーバージョンのアップグレードには、以前のバージョンのデータベースと下位互換性のないデータベースの変更が含まれる可能性があります。新しいバージョンの新機能により、既存のアプリケーションが適切に動作しなくなることがあります。問題を回避するため、Amazon Aurora では、メジャーバージョンアップグレードは自動的に適用されません。むしろ、次の手順を実行して、メジャーバージョンのアップグレードを慎重に計画することをお勧めします。

1. 使用可能なターゲットのリストから必要なメジャーバージョンを、テーブル内のバージョンにリストされているターゲットから選択します。AWS CLI を使うことにより現在のバージョンの AWS リージョン で利用可能なバージョンの正確なリストを入手できます。詳細については、「[AWS リージョン で使用可能なバージョンのリストを取得します。](USER_UpgradeDBInstance.PostgreSQL.UpgradeVersion.md)」を参照してください。

1. 新しいバージョンのトライアルデプロイで、アプリケーションが正常に動作することを確認します。完全なプロセスの詳細については、「[本番稼働用の DB クラスターの新しいメジャーバージョンへのアップグレードをテストする](#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary)」を参照してください。

1. トライアルデプロイでアプリケーションが正常に動作することを確認したら、クラスターをアップグレードできます。詳細については、「[Aurora PostgreSQL エンジンを新しいメジャーバージョンにアップグレードする](#USER_UpgradeDBInstance.Upgrading.Manual)」を参照してください。

**注記**  
13.6 以降の Babelfish for Aurora PostgreSQL 13 ベースのバージョンから 14.6 以降の Aurora PostgreSQL 14 ベースのバージョンへのメジャーバージョンアップグレードを実行できます。Babelfish for Aurora PostgreSQL 13.4 と 13.5 は、メジャーバージョンアップグレードをサポートしていません。

次のように、[describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) AWS CLI コマンドを使用して AWS リージョン をクエリすることにより、Aurora PostgreSQL DB クラスターのメジャーバージョンアップグレードターゲットとして利用可能なエンジンバージョンのリストを取得できます。

Linux、macOS、Unix の場合:

```
aws rds describe-db-engine-versions \
  --engine aurora-postgresql \
  --engine-version version-number \
  --query 'DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`].{EngineVersion:EngineVersion}' \
  --output text
```

Windows の場合:

```
aws rds describe-db-engine-versions ^
  --engine aurora-postgresql ^
  --engine-version version-number ^
  --query "DBEngineVersions[].ValidUpgradeTarget[?IsMajorVersionUpgrade == `true`].{EngineVersion:EngineVersion}" ^
  --output text
```

場合によっては、アップグレードするバージョンが現行のバージョンのターゲットではない場合があります。そのような場合は、[versions table](USER_UpgradeDBInstance.PostgreSQL.UpgradeVersion.md#versions-table) の情報を使用して、クラスターがターゲットの行に選択したターゲットを持つバージョンになるまで、マイナーバージョンのアップグレードを実行します。

## 本番稼働用の DB クラスターの新しいメジャーバージョンへのアップグレードをテストする
<a name="USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary"></a>

各新しいメジャーバージョンには、パフォーマンスを向上させるために設計されたクエリオプティマイザの機能強化が含まれています。ただし、ワークロードには、新しいバージョンでプランの実行を低下させるクエリが含まれる場合があります。そのため、本番環境でアップグレードする前に、パフォーマンスをテストして確認することをお勧めします。[メジャーバージョンのアップグレード後の計画の安定性の確保](AuroraPostgreSQL.Optimize.BestPractice.md#AuroraPostgreSQL.Optimize.BestPractice.MajorVersionUpgrade) で説明されているように、クエリプラン管理 (QPM) 拡張機能を使用して、バージョン間でクエリプランの安定性を管理できます。

本番稼働用の Aurora PostgreSQL DB クラスターを新しいメジャーバージョンにアップグレードする前に、アップグレードをテストして、アプリケーションが正常に動作することを確認することを強く推奨します。

1. バージョン互換のパラメータグループを準備します。

   カスタム DB インスタンスまたは DB クラスターパラメータグループを使用している場合は、2 つのオプションから選択できます。

   1. 新しい DB エンジンバージョンのデフォルト DB インスタンス、DB クラスターパラメータグループ、またはその両方を指定します。

   1. 新しい DB エンジンバージョンの独自のカスタムパラメータグループを作成します。

1. 無効なデータベースがないか確認し、存在するデータベースをすべて削除します。

   `pg_database` カタログの `datconnlimit` 列には、`DROP DATABASE` オペレーション中に中断されたデータベースを無効としてマークする `-2` という値が含まれています。次のクエリを使用して、無効なデータベースがあるかどうかをチェックします。

   ```
   SELECT
       datname
   FROM
       pg_database
   WHERE
       datconnlimit = - 2;
   ```

   クエリがデータベース名を返す場合、これらのデータベースは無効です。`DROP DATABASE invalid_db_name` ステートメントを使用して、無効なデータベースを削除します。次の動的ステートメントを使用して、無効なデータベースをすべて削除できます。

   ```
   SELECT
       'DROP DATABASE ' || quote_ident(datname) || ';'
   FROM
       pg_database
   WHERE
       datconnlimit = -2 \gexec
   ```

1. サポートされていない使用の確認
   + アップグレードを試みる前に、すべての準備済みのトランザクションをコミットまたはロールバックします。次のクエリを使用して、開いている準備済みのトランザクションがインスタンスにないことを確認します。

     ```
     SELECT count(*) FROM pg_catalog.pg_prepared_xacts;
     ```
   + アップグレードを試みる前に、使用されているすべての *reg\$1* データ型を削除します。`regtype` と `regclass` を除き、*reg\$1* データ型をアップグレードすることはできません。このデータ型は、pg\$1upgrade ユーティリティ (Amazon Aurora でアップグレードに使用される) で保持することはできません。このユーティリティの詳細については、PostgreSQL のドキュメントの「[pg\$1upgrade](https://www.postgresql.org/docs/current/pgupgrade.html)」を参照してください。

     サポートされていない *reg\$1* データ型が使用されていないことを確認するには、データベースごとに次のクエリを使用します。

     ```
     SELECT count(*) FROM pg_catalog.pg_class c, pg_catalog.pg_namespace n, pg_catalog.pg_attribute a 
       WHERE c.oid = a.attrelid 
           AND NOT a.attisdropped 
           AND a.atttypid IN ('pg_catalog.regproc'::pg_catalog.regtype, 
                              'pg_catalog.regprocedure'::pg_catalog.regtype, 
                              'pg_catalog.regoper'::pg_catalog.regtype, 
                              'pg_catalog.regoperator'::pg_catalog.regtype, 
                              'pg_catalog.regconfig'::pg_catalog.regtype, 
                              'pg_catalog.regdictionary'::pg_catalog.regtype) 
           AND c.relnamespace = n.oid 
           AND n.nspname NOT IN ('pg_catalog', 'information_schema');
     ```
   + `pgRouting` 拡張機能がインストールされている Aurora PostgreSQL バージョン 10.18 以上の DB クラスターをアップグレードする場合には、バージョン 12.4 以上にアップグレードする前に拡張機能を削除してください。

     拡張子 `pg_repack` バージョン 1.4.3 がインストールされている Aurora PostgreSQL 10.x バージョンをアップグレードする場合には、より高いバージョンにアップグレードする前に拡張子を削除してください。

1. template1 と template0 のデータベースを確認してください。

   アップグレードを成功させるには、テンプレート 1 とテンプレート 0 のデータベースが存在し、テンプレートとしてリストされている必要があります。これをチェックするには、次のコマンドを使用します。

   ```
   SELECT datname, datistemplate FROM pg_database; 
                           
   datname    | datistemplate
   -----------+---------------
   template0  | t
   rdsadmin   | f
   template1  | t
   postgres   | f
   ```

   コマンド出力では、template1 データベースと template0  データベースの `datistemplate` 値は、`t` でなければなりません。

1. 論理的なレプリケーションスロットを削除します。

   Aurora PostgreSQL DB クラスターがいずれかの論理レプリケーションスロットを使用している場合は、アップグレードプロセスを続行できません。論理レプリケーションスロットは通常、AWS DMS を使用したデータの移行、またはデータベースからデータレイク、BI ツール、およびその他のターゲットへのテーブルのレプリケートなどの短期のデータの移行タスクに使用されます。アップグレードする前に、既存の論理レプリケーションスロットの目的を確認し、削除しても問題ないことを確認してください。次のクエリを使用して論理レプリケーションスロットを確認できます。

   ```
   SELECT * FROM pg_replication_slots;
   ```

   論理レプリケーションスロットがまだ使用されている場合は、それらを削除しないでください。また、その場合、アップグレードを続行することはできません。ただし、論理レプリケーションスロットが不要な場合は、次の SQL を使用して削除できます。

   ```
   SELECT pg_drop_replication_slot(slot_name);
   ```

   `pglogical` 拡張機能を使用するロジカルレプリケーションシナリオでも、パブリッシャーノードでメジャーバージョンアップグレードを正常に行うには、パブリッシャーノードからスロットを削除する必要があります。ただし、アップグレード後にサブスクライバーノードからレプリケーションプロセスを再開できます。詳細については、「[メジャーアップグレード後の論理レプリケーションの再確立](Appendix.PostgreSQL.CommonDBATasks.pglogical.recover-replication-after-upgrade.md)」を参照してください。

1. バックアップを実行します。

   アップグレードプロセスでは、アップグレード中に DB クラスターのスナップショットが作成されます。アップグレードプロセスの前に手動でもバックアップを行う場合の詳細については、「[DB クラスタースナップショットの作成](USER_CreateSnapshotCluster.md)」を参照してください。

1. メジャーバージョンアップグレードを実行する前に、特定の拡張機能を、利用可能な最新バージョンにアップグレードします。更新する拡張機能は以下のとおりです。
   + `pgRouting`
   + `postgis_raster`
   + `postgis_tiger_geocoder`
   + `postgis_topology`
   + `address_standardizer`
   + `address_standardizer_data_us`

   現在インストールされている拡張機能ごとに以下のコマンドを実行します。

   ```
   ALTER EXTENSION PostgreSQL-extension UPDATE TO 'new-version';
   ```

   詳細については、「[PostgreSQL 拡張機能のアップグレード](USER_UpgradeDBInstance.Upgrading.ExtensionUpgrades.md)」を参照してください。PostGIS のアップグレードの詳細については、「[ステップ 6: PostGIS 拡張機能を更新する](Appendix.PostgreSQL.CommonDBATasks.PostGIS.md#Appendix.PostgreSQL.CommonDBATasks.PostGIS.Update)」を参照してください。

1. バージョン 11.x にアップグレードする場合は、メジャーバージョンアップグレードを実行する前に、サポートされていない拡張機能を削除してください。削除する拡張機能は以下のとおりです。
   + `chkpass`
   + `tsearch2` 

1. ターゲットバージョンに応じて、`unknown` データ型を削除します。

   PostgreSQL バージョン 10 では、`unknown` データ型をサポートしていません。バージョン 9.6 のデータベースで `unknown` データ型を使用している場合、バージョン 10 にアップグレードすると次のようなエラーメッセージが表示されます。

   ```
   Database instance is in a state that cannot be upgraded: PreUpgrade checks failed: 
   The instance could not be upgraded because the 'unknown' data type is used in user tables. 
   Please remove all usages of the 'unknown' data type and try again."
   ```

   データベース内の `unknown` データ型を検索して、対象の列を削除したり、サポートされているデータ型に変更したりするには、各データベースに次の SQL コードを使用します。

   ```
   SELECT n.nspname, c.relname, a.attname
       FROM pg_catalog.pg_class c,
       pg_catalog.pg_namespace n,
       pg_catalog.pg_attribute a
       WHERE c.oid = a.attrelid AND NOT a.attisdropped AND
       a.atttypid = 'pg_catalog.unknown'::pg_catalog.regtype AND
       c.relkind IN ('r','m','c') AND
       c.relnamespace = n.oid AND
       n.nspname !~ '^pg_temp_' AND
       n.nspname !~ '^pg_toast_temp_' AND n.nspname NOT IN ('pg_catalog', 'information_schema');
   ```

1. リハーサルのアップグレードを実行します。

   プロダクションデータベースのアップグレードを試みる前に、プロダクションデータベースの複製でメジャーバージョンアップグレードをテストすることを強くお勧めします。複製されたテストインスタンスの実行計画を監視して、実行計画のリグレッションが発生していないかどうかを確認し、そのパフォーマンスを評価できます。テスト用の複製のインスタンスを作成するには、最新のスナップショットからデータベースを復元するか、データベースのクローンを作成します。詳細については、「[スナップショットからの復元](aurora-restore-snapshot.md#aurora-restore-snapshot.Restoring)」または「[Amazon Aurora DB クラスターのボリュームのクローン作成](Aurora.Managing.Clone.md)」を参照してください。

   詳細については、「[Aurora PostgreSQL エンジンを新しいメジャーバージョンにアップグレードする](#USER_UpgradeDBInstance.Upgrading.Manual)」を参照してください。

1. プロダクションインスタンスをアップグレードします。

   リハーサルのメジャーバージョンアップグレードが成功したら、安心してプロダクションデータベースをアップグレードできます。詳細については、「[Aurora PostgreSQL エンジンを新しいメジャーバージョンにアップグレードする](#USER_UpgradeDBInstance.Upgrading.Manual)」を参照してください。

   
**注記**  
Aurora PostgreSQL は、アップグレードプロセス中に DB クラスターのスナップショットを取得します。このプロセス中、クラスターのポイントインタイム復元を実行することはできません。アップグレードのスタート前およびインスタンスの自動スナップショットの完了後に、後からポイントインタイムの復元を実行できます。ただし、以前のマイナーバージョンのポイントインタイム復元を実行することはできません。

   進行中のアップグレードについては、Amazon RDS を使用して、pg\$1upgrade ユーティリティで生成される 2 つのログを表示することができます。表示できるのは `pg_upgrade_internal.log` および `pg_upgrade_server.log` です。これらのログのファイル名には、Amazon Aurora によりタイムスタンプが追加されます。これらのログも、他のログと同様、表示できます。詳細については、「[Amazon Aurora ログファイルのモニタリング](USER_LogAccess.md)」を参照してください。

1. PostgreSQL の拡張機能をアップグレードします。PostgreSQL のアップグレードプロセスでは、PostgreSQL の拡張機能はアップグレードされません。詳細については、「[PostgreSQL 拡張機能のアップグレード](USER_UpgradeDBInstance.Upgrading.ExtensionUpgrades.md)」を参照してください。

## アップグレード後の推奨事項
<a name="USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.postupgrade"></a>

メジャーバージョンアップグレードが完了したら、以下のことをお勧めします。
+ `ANALYZE` 操作を実行して `pg_statistic` テーブルを更新します。これは、すべての PostgreSQL DB インスタンスのすべてのデータベースに対して行う必要があります。Optimizer の統計情報はメジャーバージョンのアップグレード中には転送されないため、パフォーマンスの問題を回避するためにすべての統計情報を再生成する必要があります。次のようにパラメータを指定せずにコマンドを実行して、現在のデータベース内のすべての標準テーブルの統計情報を生成します。

  ```
  ANALYZE VERBOSE;
  ```

  `VERBOSE` フラグはオプションですが、使用することで進行状況を表示できます。詳細については、「PostgreSQL ドキュメント」の「[ANALYZE](https://www.postgresql.org/docs/10/sql-analyze.html)」を参照してください。

  ANALYZE VERBOSE を使用する代わりに特定のテーブルを分析する場合は、次のようにテーブルごとに ANALYZE コマンドを実行します。

  ```
  ANALYZE table_name;
  ```

  パーティションテーブルの場合は、常に親テーブルを分析します。このプロセスでは、以下の操作を行います。
  + すべてのパーティションにわたって行を自動的にサンプリングする
  + パーティションごとに統計を再帰的に更新する
  + 重要な計画統計を親レベルで維持する

  親テーブルには実際のデータは保存されませんが、クエリの最適化には親テーブルの分析が不可欠です。個々のパーティションに対してのみ ANALYZE を実行すると、効率的なパーティション間計画に必要な包括的な統計をオプティマイザで利用できないため、クエリパフォーマンスが低下する可能性があります。
**注記**  
パフォーマンスの問題を回避するため、アップグレード後にシステムで ANALYZE を実行してください。
+ PostgreSQL バージョン 10 にアップグレードした場合は、使用しているハッシュインデックスで `REINDEX` を実行してください。ハッシュインデックスはバージョン 10 で変更されたため、再構築する必要があります。無効なハッシュインデックスを見つけるには、ハッシュインデックスを含む各データベースに対して次の SQL を実行します。

  ```
  SELECT idx.indrelid::regclass AS table_name, 
     idx.indexrelid::regclass AS index_name 
  FROM pg_catalog.pg_index idx
     JOIN pg_catalog.pg_class cls ON cls.oid = idx.indexrelid 
     JOIN pg_catalog.pg_am am ON am.oid = cls.relam 
  WHERE am.amname = 'hash' 
  AND NOT idx.indisvalid;
  ```
+ アップグレードしたデータベースで同様のワークロードでアプリケーションをテストして、すべてが期待どおりに機能することを確認することをお勧めします。アップグレードが確認されたら、このテストインスタンスを削除できます。

## Aurora PostgreSQL エンジンを新しいメジャーバージョンにアップグレードする
<a name="USER_UpgradeDBInstance.Upgrading.Manual"></a>

新しいメジャーバージョンへのアップグレードプロセスを開始するとき、Aurora PostgreSQL はクラスターに変更を加える前に Aurora DB クラスターのスナップショットを取得します。このスナップショットは、メジャーバージョンのアップグレード用にのみ作成され、マイナーバージョンのアップグレードでは作成されません。アップグレードプロセスが完了すると、このスナップショットは、RDS コンソールの**スナップショット**にリストされている手動スナップショットの中に表示されています。次の例のように、スナップショット名には、プレフィックス、Aurora PostgreSQL DB クラスターの名前、ソースバージョン、ターゲットバージョン、日付とタイムスタンプとして `preupgrade` が含まれます。

```
preupgrade-docs-lab-apg-global-db-12-8-to-13-6-2022-05-19-00-19
```

アップグレードの完了後、Aurora が作成して手動スナップショットリストに保存したスナップショットを使用して、必要に応じて DB クラスターを以前のバージョンに復元できます。

**ヒント**  
一般に、スナップショットは Aurora DB クラスターをさまざまな時点に復元するためのさまざまな方法を提供します。詳細については、「[DB クラスタースナップショットからの復元](aurora-restore-snapshot.md)」および「[DB クラスターを指定の時点の状態に復元する](aurora-pitr.md)」を参照してください。ただし、Aurora PostgreSQL は、以前のマイナーバージョンに復元するためのスナップショットを使用をサポートしていません。

メジャーバージョンのアップグレードプロセス中には、Aurora によってボリュームが割り当てられ、ソース Aurora PostgreSQL DB クラスターのクローンが作成されます。アップグレードが何らかの理由で失敗した場合、Aurora PostgreSQL はクローンを使用してアップグレードをロールバックします。ソースのボリュームのクローンが 15 個より多く割り当てられた後、後続のクローンはフルコピーになり、時間がかかります。これにより、アップグレードプロセスにかかる時間が延びる場合があります。Aurora PostgreSQL でアップグレードがロールバックされる場合は、次の点に注意してください。
+ アップグレード中に割り当てられたクローンボリューム、およびその元となったボリュームの両方について、請求情報とメトリクスが表示される可能性があります。クラスターのバックアップ保持期間がアップグレードの時間を超えた時点で、Aurora PostgreSQL は余分なボリュームをクリーンアップします。
+ そのクラスターの次のクロスリージョンスナップショットコピーは、増分コピーではなく、フルコピーになります。

クラスターを構成する DB インスタンスを安全にアップグレードするために、Aurora PostgreSQL では pg\$1upgrade ユーティリティを使用します。ライターのアップグレードが完了すると、各リーダーインスタンスは新しいメジャーバージョンにアップグレードされている間、短時間停止します。この PostgreSQL ユーティリティの詳細については、PostgreSQL のドキュメントの「[pg\$1upgrade](https://www.postgresql.org/docs/current/pgupgrade.html)」を参照してください。

AWS マネジメントコンソール、AWS CLI、または RDS API を使用することにより、Aurora PostgreSQL DB クラスターを新しいバージョンにアップグレードできます。

### コンソール
<a name="USER_UpgradeDBInstance.Upgrading.Manual.Console"></a>

**DB クラスターのエンジンバージョンを変更するには**

1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。

1. ナビゲーションペインで、[**データベース**] を選択して、アップグレードする DB クラスターを選択します。

1. [**Modify**] を選択します。[**DB クラスターの変更**] ページが表示されます。

1. [**Engine version**] (エンジンバージョン) で、新しいバージョンを選択します。

1. [**続行**] を選択して、変更の概要を確認します。

1. 変更をすぐに反映させるには、[**Apply immediately**] を選択します。このオプションを選択すると、停止状態になる場合があります。詳細については、「[Amazon Aurora DB クラスターの変更](Aurora.Modifying.md)」を参照してください。

1. 確認ページで、変更内容を確認します。正しい場合は、[**クラスターの変更**] を選択して変更を保存します。

   または、[**戻る**] を選択して変更を編集するか、[**キャンセル**] を選択して変更をキャンセルします。

### AWS CLI
<a name="USER_UpgradeDBInstance.Upgrading.Manual.CLI"></a>

DB クラスターのエンジンバージョンをアップグレードするには、CLI の [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) AWS CLI コマンドを使用します。以下のパラメータを指定します。
+ `--db-cluster-identifier` - DB クラスターの名前。
+ `--engine-version` - アップグレード先のデータベースエンジンのバージョン番号です。有効なエンジンバージョンの詳細については、AWS CLI の [describe-db-engine-versions](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-engine-versions.html) コマンドを参照してください。
+ `--allow-major-version-upgrade` - `--engine-version` パラメータが DB クラスターの現在のメジャーバージョンとは異なるメジャーバージョンである場合に必須のフラグです。
+ `--no-apply-immediately` ​- 次のメンテナンス時間中に変更を適用します。今すぐ変更を適用するには、`--apply-immediately` を使用します。

**Example**  
Linux、macOS、Unix の場合:  

```
1. aws rds modify-db-cluster \
2.     --db-cluster-identifier mydbcluster \
3.     --engine-version new_version \
4.     --allow-major-version-upgrade \
5.     --no-apply-immediately
```
Windows の場合:  

```
1. aws rds modify-db-cluster ^
2.     --db-cluster-identifier mydbcluster ^
3.     --engine-version new_version ^
4.     --allow-major-version-upgrade ^
5.     --no-apply-immediately
```

### RDS API
<a name="USER_UpgradeDBInstance.Upgrading.Manual.API"></a>

DB クラスターのエンジンのバージョンをアップグレードするには、[ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) オペレーションを使用します。以下のパラメータを指定します。
+ `DBClusterIdentifier` - DB クラスターの名前、例えば *`mydbcluster`* です。
+ `EngineVersion` - アップグレード先のデータベースエンジンのバージョン番号です。有効なエンジンバージョンについては、[DescribeDBEngineVersions](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBEngineVersions.html) オペレーションを使用します。
+ `AllowMajorVersionUpgrade` - `EngineVersion` パラメータが DB クラスターの現在のメジャーバージョンとは異なるメジャーバージョンである場合に必須のフラグです。
+ `ApplyImmediately` - 変更をすぐに適用するか、次のメンテナンスウィンドウ中に適用するかを指定します。今すぐ変更を適用するには、値を `true` に設定します。次のメンテナンスウィンドウ中に変更を適用するには、値を `false` に設定します。

### グローバルデータベースのメジャーアップグレード
<a name="USER_UpgradeDBInstance.PostgreSQL.GlobalDB"></a>

Aurora グローバルデータベースクラスターの場合、アップグレードプロセスは Aurora グローバルデータベースを構成するすべての DB クラスターを同時にアップグレードします。これは、それぞれが同じ Aurora PostgreSQL バージョンを実行するようにするためです。また、システムテーブル、データファイル形式などの変更が、すべてのセカンダリクラスターに自動的にレプリケートされます。

グローバルデータベースクラスターを Aurora PostgreSQL の新しいメジャーバージョンにアップグレードするには、「[本番稼働用の DB クラスターの新しいメジャーバージョンへのアップグレードをテストする](#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary)」で説明されているように、アップグレードされたバージョンでアプリケーションをテストすることをお勧めします。[本番稼働用の DB クラスターの新しいメジャーバージョンへのアップグレードをテストする](#USER_UpgradeDBInstance.PostgreSQL.MajorVersion.Upgrade.preliminary) の [step 1.](#step-1) に詳述されているとおり、アップグレードの前に、Aurora グローバルデータベースの各 AWS リージョン に対して DB クラスターパラメータグループと DB パラメータグループの設定を必ず準備してください。

Aurora PostgreSQL グローバルデータベースクラスターに、`rds.global_db_rpo` パラメータに目標復旧時点 (RPO) が設定されている場合、アップグレードする前にパラメータをリセットしてください。RPO がオンになっている場合、メジャーバージョンのアップグレードプロセスは機能しません。デフォルトでは、このパラメータがオフになっています。Aurora PostgreSQL グローバルデータベースおよび RPO の詳細については、「[Aurora PostgreSQL- ベースのグローバルデータベースの RPO (目標復旧時点) 管理](aurora-global-database-disaster-recovery.md#aurora-global-database-manage-recovery)」を参照してください。

新しいバージョンの試用版デプロイでアプリケーションが正常に実行できることを確認した場合は、アップグレードプロセスを開始できます。これを行うには、「[Aurora PostgreSQL エンジンを新しいメジャーバージョンにアップグレードする](#USER_UpgradeDBInstance.Upgrading.Manual)」を参照してください。次の画像のように、RDS コンソールの **[Databases]** (データベース) リストから最上位の項目 **[Global database]** (グローバルデータベース) を必ず選択してください。

![\[Aurora グローバルデータベース、Aurora Serverless DB クラスターおよび別の Aurora PostgreSQL DB クラスターを示すコンソール画像\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-database-plus-other.png)


他の変更と同様に、プロンプトが表示されたらプロセスの続行を確認できます。

![\[Aurora PostgreSQL DB クラスターのアップグレードプロセスを確認するためのプロンプトを示すコンソール画像\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-db-apg-upgrade-2.png)


アップグレードプロセスの開始には、コンソールの代わりに AWS CLI または RDS API を使用できます。コンソールと同様、次のように、Aurora グローバルデータベースクラスターの構成要素ではなく、Aurora グローバルデータベースクラスターを操作します。
+ [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) AWS CLI コマンドを使用し、AWS CLI を使うことにより、Aurora グローバルデータベースのアップグレードを開始します。
+ [ModifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalCluster.html) API を使用して、アップグレードを開始します。