RDS for PostgreSQL のメジャーバージョンアップグレードを実行する方法 - Amazon Relational Database Service

RDS for PostgreSQL のメジャーバージョンアップグレードを実行する方法

Amazon RDS for PostgreSQL データベースでメジャーバージョンのアップグレードを実行する場合は、以下のプロセスをお勧めします。

  1. バージョンとの互換性を持つパラメータグループの準備 - カスタムパラメータグループを使用している場合は、2 つのオプションがあります。新しい DB エンジンバージョンのデフォルトのパラメータグループを指定します。または、新しい DB エンジンバージョンの独自のカスタムパラメータグループを作成します。詳細については、「Amazon RDS のパラメータグループ」および「マルチ AZ DB クラスターの DB クラスターパラメータグループを使用する」を参照してください。

  2. サポートされていないデータベースクラスを確認する - データベースのインスタンスクラスが、アップグレード先の PostgreSQL バージョンと互換性があることを確認します。詳細については、「DB インスタンスクラスでサポートされている DB エンジン」を参照してください。

  3. サポートされていない使用の確認

    • 準備済みのトランザクション - アップグレードを実行する前に、すべての準備済みのトランザクションをコミットまたはロールバックします。

      次のクエリを使用して、開いている準備済みのトランザクションがデータベースにないことを確認します。

      SELECT count(*) FROM pg_catalog.pg_prepared_xacts;

    • Reg* データ型 - アップグレードの実施前に reg* データ型の使用をすべて削除します。regtype と regclass を除き、reg* データ型をアップグレードすることはできません。このデータ型はアップグレードで使用されているため、 pg_upgrade ユーティリティで維持することはできません。

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

      
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');

  4. 無効なデータベースがないかチェックします。

    • 無効なデータベースがないことを確認します。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

    無効なデータベースの詳細については、「無効なデータベースでの自動バキュームの動作を理解する」を参照してください。

  5. 論理レプリケーションスロットの処理 — データベースに論理レプリケーションスロットがある場合、アップグレードは実行できません。論理レプリケーションスロットは通常、データベースからデータレイク、BI ツール、およびその他のターゲットへのテーブルのレプリケートおよび AWS DMS に使用されます。アップグレードする前に、使用中の論理レプリケーションスロットの目的を確認し、削除しても問題ないことを確認してください。論理レプリケーションスロットがまだ使用されている場合は、それらを削除しないでください。また、その場合、アップグレードを続行することはできません。

    論理レプリケーションスロットが不要な場合は、次の SQL を使用して削除できます。

    SELECT * FROM pg_replication_slots;
SELECT pg_drop_replication_slot(slot_name);

    pglogical 拡張機能を使用する論理レプリケーション設定でも、メジャーバージョンアップグレードを正常に行うには、スロットを削除する必要があります。pglogical 拡張機能を使用して作成されたスロットを識別して削除する方法については、「RDS for PostgreSQL 用ロジカルレプリケーションスロットの管理」を参照してください。

  6. リードレプリカの処理 - シングル AZ DB インスタンスまたはマルチ AZ DB インスタンス配置のアップグレードでは、プライマリ DB インスタンスと共にリージョン内リードレプリカもアップグレードされます。Amazon RDS は、マルチ AZ DB クラスターのリードレプリカをアップグレードしません。

    リードレプリカを個別にアップグレードすることはできません。個別にアップグレードできるとすると、プライマリインスタンスとレプリカデータベースの PostgreSQL メジャーバージョンが一致しないという状況が生じる可能性があります。ただし、リードレプリカをアップグレードすると、プライマリ DB インスタンスのダウンタイムが増加する場合があります。リードレプリカのアップグレードを防ぐには、レプリカをスタンドアロンインスタンスに昇格させるか、アップグレードプロセスをスタートする前にレプリカを削除します。

    アップグレードプロセスでは、リードレプリカの現在のパラメータグループに基づいて、リードレプリカのパラメータグループが再作成されます。アップグレードの完了後にのみ、リードレプリカを変更してカスタムパラメータグループをリードレプリカに適用できます。リードレプリカの詳細については、「Amazon RDS for PostgreSQL でのリードレプリカの使用」を参照してください。

  7. バックアップの実行 - データベースの復元ポイントを認識できるように、メジャーバージョンアップグレードを実行する前にはバックアップを実行しておくことをお勧めします。バックアップ保持期間を 0 より大きい値に設定すると、アップグレードプロセスにおいて、アップグレード前後にデータベースの DB スナップショットが作成されます。バックアップ保持期間を変更するには、「Amazon RDS DB インスタンスを変更する」と「Amazon RDS のマルチ AZ DB クラスターの変更」を参照してください。

    手動でバックアップを実行するには、「Amazon RDS のシングル AZ DB インスタンスの DB スナップショットの作成」と「Amazon RDS のマルチ AZ DB クラスターのスナップショットの作成」を参照してください。

  8. メジャーバージョンのアップグレード前に特定のエクステンションを更新する - アップグレードでメジャーバージョンをスキップする場合、メジャーバージョンのアップグレード前に特定のエクステンションを更新する必要があります。例えば、バージョン 9.5.x または 9.6.x からバージョン 11.x 以降へのアップグレードでは、メジャーバージョンがスキップされます。更新する拡張機能には、空間データを処理するための PostGIS および関連する拡張機能が含まれます。

    • address_standardizer

    • address_standardizer_data_us

    • postgis_raster

    • postgis_tiger_geocoder

    • postgis_topology

    使用している拡張機能ごとに以下のコマンドを実行します。

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

    詳細については、「RDS for PostgreSQL データベースでの PostgreSQL 拡張機能のアップグレード」を参照してください。PostGIS のアップグレードの詳細については、「ステップ 6: PostGIS 拡張機能を更新する」を参照してください。

  9. メジャーバージョンのアップグレード前の特定のエクステンションの削除 - メジャーバージョンをバージョン 11.x にスキップするアップグレードは、pgRouting エクステンションの更新をサポートしていません。バージョン 9.4.x、9.5.x、または 9.6.x からバージョン 11.x へのアップグレードでは、メジャーバージョンがスキップされます。pgRouting エクステンションを削除し、アップグレード後に互換性のあるバージョンに再インストールできます。更新できるエクステンションのバージョンについては、サポートされている PostgreSQL 拡張機能バージョン をご覧ください。

    tsearch2 および chkpass のエクステンションは、PostgreSQL バージョン 11 以降では現在サポートされていません。バージョン 11.x にアップグレードする場合は、アップグレードの前に、tsearch2 および chkpass エクステンションを削除します。

  10. unknown データ型の削除 - ターゲットのバージョンに応じて、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 DISTINCT data_type FROM information_schema.columns WHERE data_type ILIKE 'unknown';

  11. リハーサル更新の実行 - プロダクションデータベースのアップグレードを行う前に、プロダクションデータベースの複製でメジャーバージョンアップグレードをテストすることを強くお勧めします。複製されたテストデータベースの実行計画を監視して、実行計画のリグレッションが発生していないかどうかを確認し、そのパフォーマンスを評価できます。テストインスタンスの複製を作成するには、データベースを最新スナップショットから復元するか、ポイントインタイムの復元を実行して復元可能な直近の時間でデータベースを復元します。

    詳細については、「スナップショットからの復元」または「Amazon RDS の DB インスタンスを特定の時点に復元する」を参照してください。マルチ AZ DB クラスターについては、「スナップショットからマルチ AZ DB クラスターへの復元」または「マルチ AZ DB クラスターを指定の時点の状態に復元する」を参照してください。

    アップグレードの実施の詳細については、「エンジンバージョンの手動アップグレード」を参照してください。

    バージョン 9.6 のデータベースをバージョン 10 にアップグレードする場合、PostgreSQL 10 では、デフォルトで並列クエリが有効になることに注意してください。テストデータベースの max_parallel_workers_per_gather パラメータを 2 に変更することで、アップグレードする前に並列処理による影響をテストできます。

    注記

    default.postgresql10 DB パラメータグループでは、max_parallel_workers_per_gather パラメータのデフォルト値は 2 です。

    詳細については、「PostgreSQL ドキュメント」の「Parallel Query」(並列クエリ) を参照してください。バージョン 10 で並列処理を無効にするには、max_parallel_workers_per_gather パラメータを 0 に設定します。

    メジャーバージョンのアップグレード中、public データベースと template1 データベース、およびすべてのデータベースの public スキーマは、一時的に名前が変更されます。これらのオブジェクトは、元の名前とランダム文字列を組み合わせた名前でログに表示されます。この文字列は、メジャーバージョンアップグレード時に locale や owner などのカスタム設定が保持されるように追加されます。アップグレードが完了したら、これらのオブジェクト名は元の名前に戻ります。

    注記

    メジャーアップグレードのプロセス中に、DB インスタンスまたはマルチ AZ DB クラスターのポイントインタイムの復元を実行することはできません。Amazon RDS でアップグレードが完了すると、データベースの自動バックアップが実施されます。ポイントインタイムの復元を実行できるのは、アップグレードのスタート前およびデータベースの自動バックアップ完了後です。

  12. 事前チェック手順エラーでアップグレードが失敗した場合、問題を解決します - メジャーバージョンのアップグレードプロセス中に、Amazon RDS for PostgreSQL は初期に事前チェック手順を実行して、アップグレードの失敗の原因となる可能性のある問題を特定します。事前チェック手順は、インスタンス内のすべてのデータベースにわたって潜在的な互換性のない条件をすべてチェックします。

    事前チェックで問題が発生した場合、アップグレード事前チェックが失敗したことを示すログイベントが作成されます。事前確認プロセスの詳細は、データベースのすべてのデータベースの pg_upgrade_precheck.log と名前が付けられたアップグレードログにあります。Amazon RDS では、ファイル名にタイムスタンプが追加されます。ログの表示の詳細については、「Amazon RDS ログファイルのモニタリング」を参照してください。

    リードレプリカのアップグレードが事前チェックで失敗した場合、失敗したリードレプリカのレプリケーションは中断され、リードレプリカは終了状態になります。リードレプリカを削除し、アップグレードしたプライマリ DB インスタンスに基づいて、新しいリードレプリカを再作成します。

    事前チェックログで特定されたすべての問題を解決してから、メジャーバージョンのアップグレードを再試行します。事前チェックログの例は次のようになります。

    ------------------------------------------------------------------------
Upgrade could not be run on Wed Apr 4 18:30:52 2018
-------------------------------------------------------------------------
The instance could not be upgraded from 9.6.11 to 10.6 for the following reasons.
Please take appropriate action on databases that have usage incompatible with the requested major engine version upgrade and try the upgrade again.

* There are uncommitted prepared transactions. Please commit or rollback all prepared transactions.* One or more role names start with 'pg_'. Rename all role names that start with 'pg_'.

* The following issues in the database 'my"million$"db' need to be corrected before upgrading:** The ["line","reg*"] data types are used in user tables. Remove all usage of these data types.
** The database name contains characters that are not supported by RDS for PostgreSQL. Rename the database.
** The database has extensions installed that are not supported on the target database version. Drop the following extensions from your database: ["tsearch2"].

* The following issues in the database 'mydb' need to be corrected before upgrading:** The database has views or materialized views that depend on 'pg_stat_activity'. Drop the views.

  13. データベースのアップグレード中にリードレプリカのアップグレードが失敗した場合は、問題を解決します - 失敗したリードレプリカは incompatible-restore 状態になり、レプリケーションはデータベースで終了します。リードレプリカを削除し、アップグレードしたプライマリ DB インスタンスに基づいて、新しいリードレプリカを再作成します。

    注記

    Amazon RDS は、マルチ AZ DB クラスターのリードレプリカをアップグレードしません。マルチ AZ DB クラスターのメジャーバージョンアップグレードを実行すると、リードレプリカのレプリケーション状態が終了に変わります。

    リードレプリカのアップグレードは、次の理由で失敗することがあります。

    • 待機時間が経過してもプライマリ DB インスタンスにキャッチアップできなかった。

    • ストレージ不足、互換性のない復元など、最終状態または互換性のないライフサイクル状態であった。

    • プライマリ DB インスタンスのアップグレードのスタート時に、リードレプリカで別のマイナーバージョンのアップグレードが実行されていた。

    • リードレプリカで互換性のないパラメータを使用していた。

    • リードレプリカがプライマリ DB インスタンスと通信できず、データフォルダを同期できなかった。

  14. 本番稼働用データベースのアップグレード - リハーサルのメジャーバージョンアップグレードに成功すれば、自信を持って本番稼働用のプロダクションデータベースをアップグレードできます。詳細については、「エンジンバージョンの手動アップグレード」を参照してください。

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

    ANALYZE VERBOSE;

    VERBOSE フラグはオプションですが、使用することで進行状況を表示できます。詳細については、「PostgreSQL ドキュメント」の「ANALYZE」を参照してください。

    注記

    パフォーマンスの問題を回避するため、アップグレード後にシステムで ANALYZE を実行してください。

メジャーバージョンのアップグレードが完了したら、次のことをお勧めします。

  • PostgreSQL アップグレードでは、PostgreSQL エクステンションはアップグレードされません。エクステンションをアップグレードするには、「RDS for PostgreSQL データベースでの PostgreSQL 拡張機能のアップグレード」を参照してください。

  • オプションで、Amazon RDS を使用して、pg_upgrade ユーティリティによって作成される 2 つのログを表示できます。表示できるのは pg_upgrade_internal.log および pg_upgrade_server.log です。Amazon RDS では、これらのログのファイル名にタイムスタンプが追加されます。これらのログも、他のログと同様、表示できます。詳細については、「Amazon RDS ログファイルのモニタリング」を参照してください。

    Amazon CloudWatch Logs にアップグレードログをアップロードすることもできます。詳細については、「Amazon CloudWatch Logs への PostgreSQL ログの発行」を参照してください。

  • すべてが期待どおりに機能することを確認するには、同様のワークロードでアップグレードされたデータベースでアプリケーションをテストします。アップグレードが確認されたら、このテストインスタンスを削除できます。