Amazon RDS for PostgreSQL および Aurora for PostgreSQL のメジャーバージョンアップグレードに関する問題をトラブルシューティングするにはどうすればよいですか?
Amazon Relational Database Service (Amazon RDS) for PostgreSQL または Amazon Aurora PostgreSQL 互換エディションのエンジンバージョンアップグレードがスタックしているか、または失敗しました。
簡単な説明
Amazon RDS が新しいバージョンのデータベースエンジンをサポートする場合、DB インスタンスを新しいバージョンにアップグレードできます。DB インスタンスのマイナーバージョングレードまたはメジャーバージョンアップグレードを実行できます。
マイナーバージョンアップグレードは、セキュリティの脆弱性にパッチを適用し、バグを修正するために使用されます。通常、これらのアップグレードによって新しい機能が追加されることはなく、内部ストレージ形式も変更されません。これらは、同じメジャーバージョンの以前のマイナーリリースおよび以降のマイナーリリースと常に互換性があります。しかし、メジャーバージョンアップグレードには、既存のアプリケーションとの下位互換性のないデータベースの変更が含まれています。これらのアップグレードにより、システムテーブル、データファイル、およびデータストレージの内部形式が変更される可能性があります。Amazon RDS は、メジャーバージョンアップグレードの実行に PostgreSQL ユーティリティ pg_upgrade を使用します。
PostgreSQL インスタンスのメジャーバージョンアップグレード中に、Amazon RDS は事前チェック手順を実行します。この手順では、アップグレードの失敗を引き起こし得る問題を特定します。これは、互換性がないかもしれない状態を、すべてのデータベースでチェックします。Amazon RDS は、事前チェックプロセス中に問題を特定すると、失敗した事前チェックのログイベントを作成します。すべてのデータベースの事前チェックプロセスの詳細については、pg_upgrade_precheck.log のアップグレードログを確認してください。Amazon RDS は、ファイル名にタイムスタンプを付加します。RDS イベントは、アップグレードの失敗の理由を提供する場合もあります。しかし、エンジン固有の問題については、データベースログファイルを確認する必要があります。
詳細については、RDS for PostgreSQL の場合は「データベースログファイルの表示とリスト化」を参照してください。または、Aurora for PostgreSQL の場合は、「データベースログファイルの表示とリスト化」を参照してください。
メジャーバージョンアップグレード中、RDS は次のステップを完了します。
- アップグレードの前にインスタンスのスナップショットを作成します。これは、DB インスタンスのバックアップ保持期間を 0 より大きい数値に設定した場合にのみ発生します。
- インスタンスをシャットダウンします。
- pg_upgrade ユーティリティを使用して、インスタンスでアップグレードジョブを実行します。
- アップグレード後にインスタンスのスナップショットを作成します。
解決方法
Amazon RDS はこれらのアップグレードを管理しますが、バージョンアップグレード中に次の問題が発生する可能性があります。
- アップグレードに通常よりも長い時間がかかる。
- アップグレードが失敗する。
アップグレードに長い時間がかかる
保留中のメンテナンスアクティビティ: 保留中のメンテナンスアクティビティは、エンジンバージョンのアップグレード時に自動的に適用されます。これには、RDS インスタンスに対するオペレーティングシステムパッチの適用が含まれる場合があります。この場合、オペレーティングシステムのパッチが最初に適用され、その後にエンジンバージョンがアップグレードされます。そのため、オペレーティングシステムのメンテナンスアクティビティを実行すると、アップグレードの完了にかかる時間が長くなります。
また、RDS インスタンスがマルチ AZ 配置にある場合、オペレーティングシステムのメンテナンスによってフェイルオーバーが発生します。マルチ AZ でインスタンスを設定すると、インスタンスのバックアップは通常、セカンダリインスタンスに作成されます。フェイルオーバーの場合、アップグレード後に新しいセカンダリインスタンスでバックアップが作成されます。新しいセカンダリインスタンスのこのバックアップは、最新のバックアップではない可能性があります。そのため、増分バックアップの代わりにフルバックアップがトリガーされる可能性があります。フルバックアップの作成には、特にデータベースが非常に大きい場合、長い時間がかかることがあります。
この問題を回避するには、RDS コンソールの [Pending maintenance] (保留中のメンテナンス) セクションで保留中のメンテナンスアクティビティを確認してください。Aurora for PostgreSQL については、「保留中のメンテナンスの表示」を参照してください。
または、インスタンスで AWS コマンドラインインターフェイス (AWS CLI) コマンド describe-pending-maintenance-actions を使用します。
aws rds describe-pending-maintenance-actions --resource-identifier example-arn
注: データベースエンジンのバージョンアップグレードを実行する前に、必ずこれらのメンテナンスアクティビティを完了してください。
アップグレード前にスナップショットが作成されない: アップグレードを実行する前に RDS または Aurora for PostgreSQL クラスタースナップショットのスナップショットを作成することがベストプラクティスです。インスタンスのバックアップを既にオンにしている場合は、アップグレードプロセスの一環としてスナップショットが自動的に作成されます。アップグレード前にスナップショットを作成しておくと、アップグレードプロセスの完了に必要な時間を短縮できます。これは、この場合にアップグレードプロセス中に作成されるのは増分バックアップのみであるためです。
RDS for PostgreSQL リードレプリカのアップグレード: プライマリ DB インスタンスのメジャーバージョンアップグレードを実行すると、同じリージョン内のすべてのリードレプリカが自動的にアップグレードされます。アップグレードワークフローが開始されると、リードレプリカはプライマリ DB インスタンスで pg_upgrade が正常に完了するまで待機します。その後、プライマリインスタンスのアップグレードは、リードレプリカのアップグレードが完了するまで待機します。すべてのアップグレードが完了するまで停止します。アップグレードのダウンタイムウィンドウが限られている場合は、レプリカインスタンスを昇格させたり、削除したりできます。その後、アップグレードの完了後にリードレプリカを再作成します。
クラスターを構成する DB インスタンスを安全にアップグレードするために、Aurora for PostgreSQL は pg_upgrade ユーティリティを使用します。ライターのアップグレードが完了すると、新しいメジャーバージョンにアップグレードする間、各リーダーインスタンスは短時間停止します。
アップグレード前に長時間実行されるトランザクションまたは高いワークロード: アップグレードの前に長時間実行されるトランザクションまたは高いワークロードによって、データベースのシャットダウンにかかる時間が長くなり、アップグレード時間が長くなる可能性があります。
次のクエリを実行して、長時間実行されるトランザクションを特定します。
SQL>SELECT pid, datname, application_name, state, age(query_start, clock_timestamp()), usename, query FROM pg_stat_activity WHERE query NOT ILIKE '%pg_stat_activity%' AND usename!='rdsadmin' ORDER BY query_start desc;
コンピューティング性能が不十分: pg_upgrade ユーティリティーはコンピューティングを多用する可能性があります。そのため、本番稼働用データベースをアップグレードする前に、ドライランアップグレードを実行することがベストプラクティスです。本番稼働用インスタンスのスナップショットを復元し、本番稼働用データベースと同じインスタンスクラスでドライランを実行できます。
アップグレードが失敗する
サポートされていない DB インスタンスクラス: DB インスタンスのインスタンスクラスが、アップグレード先の PostgreSQL バージョンと互換性がない場合、アップグレードが失敗することがあります。インスタンスクラスとエンジンバージョンの互換性を必ず確認してください。詳細については、RDS for PostgreSQL の場合は「DB インスタンスクラスでサポートされている DB エンジン」を確認してください。または、Aurora for PostgreSQL の場合は、「DB インスタンスクラスでサポートされている DB エンジン」を確認してください。
準備済みトランザクションを開く: データベースで開いている準備済みトランザクションは、アップグレードの失敗を引き起こす可能性があります。アップグレードを開始する前に、開いている準備済みトランザクションをすべてコミットまたはロールバックしてください。
次のクエリを実行して、インスタンスで開いている準備済みトランザクションがあるかどうかを確認します。
SELECT count(*) FROM pg_catalog.pg_prepared_xacts;
この場合、pg_upgrade.log ファイルのエラーは次のようになります。
------------------------------------------------------------------------ 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.*
サポートされていないデータ型: 次のようなサポートされていないデータ型でデータベースをアップグレードしようとすると、アップグレードはエラーで失敗します。
- regcollation
- regconfig
- regdictionary
- regnamespace
- regoper
- regoperator
- regproc
- regprocedure
注: regclass、regrole、および regtype のデータ型はサポートされています。
PostgreSQL アップグレードユーティリティ pg_upgrade は、reg* OID 参照システムデータ型を使用したテーブル列を含むデータベースのアップグレードをサポートしていません。アップグレードを試みる前に、regclass、regrole、および regtype を除く reg* データ型の使用をすべて削除します。
次のクエリを実行して、サポートされていない 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');
論理レプリケーションスロット: インスタンスに論理レプリケーションスロットがある場合、アップグレードは実行できません。論理レプリケーションスロットは通常、AWS Database Migration Service (AMS DMS) の移行に使用されます。また、データベースからデータレイク、ビジネスインテリジェンスツール、または他のターゲットにテーブルをレプリケートするためにも使用されます。アップグレードする前に、使用中の論理レプリケーションスロットの目的を確認し、削除してもよいことを確認してください。
論理レプリケーションスロットがまだ使用されている場合は、削除しないでください。この場合、アップグレードを続行できません。
pg_upgrade ログファイルの関連するエラーは、次の例のようになります。
"The instance could not be upgraded because one or more databases have logical replication slots. Please drop all logical replication slots and try again."
論理レプリケーションスロットが不要な場合は、次のクエリを実行して削除します。
SELECT * FROM pg_replication_slots;
SELECT pg_drop_replication_slot(slot_name);
ストレージの問題: pg_upgrade スクリプトが実行されている間、インスタンスの容量が不足する可能性があります。これにより、スクリプトが失敗し、次のようなエラーメッセージが表示されます。
pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] could not execute query: ERROR: could not create file "base/12345/12345678": No space keyword" left on device
この問題を解決するには、アップグレードを開始する前に、インスタンスに十分な空きストレージがあることを確認してください。
不明なデータ型: PostgreSQL バージョン 10 以降では、不明なデータ型はサポートされていません。PostgreSQL バージョン 9.6 のデータベースが不明なデータ型を使用する場合、バージョン 10 にアップグレードすると、次のようなエラーメッセージが表示されます。
"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."
これは PostgreSQL の制限であり、RDS オートメーションでは、不明なデータ型を使用する列は変更されません。アップグレードの前に、これらの列を手動で変更する必要がある場合があります。
次のクエリを実行して、不明なデータ型を含むデータベース内の列を検索します。
SELECT DISTINCT data_type FROM information_schema.columns WHERE data_type ILIKE 'unknown';
列を特定したら、これらの列を削除するか、サポートされているデータ型に変更できます。
リードレプリカのアップグレード失敗 (RDS for PostgreSQL のみ): PostgreSQL インスタンスにリードレプリカがあるため、リードレプリカのアップグレードが失敗すると、プライマリインスタンスのアップグレードがスタックする可能性があります。リードレプリカのアップグレードに失敗すると、プライマリインスタンスのアップグレードも失敗する可能性があります。失敗したリードレプリカは incompatible-restore 状態になり、レプリケーションは DB インスタンスで停止します。
リードレプリカのアップグレードは、次のいずれかの理由で失敗する可能性があります。
- 待機時間が経過しても、リードレプリカがプライマリ DB インスタンスに追いつくことができない。
- リードレプリカが、ターミナルまたは互換性のないライフサイクル状態 (storage-full や incompatible-restore など) である。
- プライマリ DB インスタンスのアップグレードが開始されるとき、リードレプリカで別のマイナーバージョンアップグレードが実行されている。
- リードレプリカが互換性のないパラメータを使用している。
- リードレプリカが、データフォルダを同期するためにプライマリ DB インスタンスと通信できない。
この問題を解決するには、リードレプリカを削除します。その後、プライマリインスタンスのアップグレード後に、アップグレードしたプライマリインスタンスに基づいて新しいリードレプリカを再作成します。
不正なプライマリユーザー名: プライマリユーザー名が「pg_」で始まる場合、アップグレードは失敗し、次のエラーメッセージが表示されます。
PreUpgrade checks failed: The instance could not be upgraded because one or more role names start with 'pg_'. Please rename all roles with names that start with 'pg_' and try again
この問題を解決するには、rds_superuser ロールを持つ別のユーザーを作成します。AWS サポートに問い合わせて、このユーザーを新しいプライマリユーザーとして更新できます。
互換性のないパラメータエラー: このエラーは、shared_buffer や work_memory などのメモリ関連のパラメータがより高い値に設定された場合に発生します。これにより、アップグレードスクリプトが失敗する可能性があります。この問題を解決するには、これらのパラメータの値を低くしてから、アップグレードの実行を再試行してください。
アップグレード前に拡張機能が更新されない: メジャーバージョンアップグレードでは、PostgreSQL 拡張機能はアップグレードされません。メジャーバージョンアップグレードを実行する前に拡張機能を更新しなかった場合、pg_upgrade.log ファイルに次のエラーが表示されます。
The Logs indicates that the RDS instance ''xxxx'' has older version of PostGIS extension or its dependent extensions (address_standardizer,address_standardizer_data_us, postgis_tiger_geocoder, postgis_topology, postgis_raster) installed as against the current version required for the upgrade.
このエラーメッセージは、PostGIS 拡張機能の問題を示しています。
次のクエリを実行して、PostGIS とその依存する拡張機能のデフォルトバージョンとインストールされているバージョンを確認します。
SELECT name, default_version, installed_version FROM pg_available_extensions WHERE installed_version IS NOT NULL AND name LIKE 'postgis%' OR name LIKE 'address%';
installed_version の値が default_version の値よりも小さい場合は、PostGIS をデフォルトバージョンに更新する必要があります。そのためには、次のクエリを実行します。
ALTER EXTENSION extension_name UPDATE TO 'default_version_number';
詳細については、RDS for PostgreSQL の場合は「PostgreSQL のエクステンションのアップグレード」を参照し、Aurora PostgreSQL の場合は「PostgreSQL 拡張機能のアップグレード」を参照してください。
ターゲットバージョンのシステムカタログの変更を理由とするビューの問題: 特定のビューの列は、PostgreSQL のバージョンによって異なります。
例えば、次のようなエラーメッセージが表示される場合があります。
PreUpgrade checks failed: The instance could not be upgraded because one or more databases have views or materialized views which depend on 'pg_stat_activity'. Please drop them and try again.
このエラーは、データベースをバージョン 9.5 から 9.6 にアップグレードするときに発生します。このエラーは、pg_stat_activity ビューが原因で発生します。バージョン 9.6 では、[waiting] (待機中) の列が wait_event_type 列と wait_event 列に置き換えられるためです。
pg_restore: from TOC entry xxx; xxx xxxx VIEW sys_user_constraints art pg_restore: error: could not execute query: ERROR: column c.consrc does not exist LINE 18: "c"."consrc" AS "search_condition", ^ HINT: Perhaps you meant to reference the column "c.conkey" or the column "c.conbin".
このエラーは、PostgreSQL バージョン 12 でカタログ pg_constraint の構造が変更されたために発生します。
これらの問題は、ターゲットバージョンのシステムカタログに基づいてビューを削除することで解決できます。
注: これらのビューを削除するときは注意してください。必ずデータベース管理者 (DBA) にご相談ください。
その他の考慮事項
- pg_upgrade ユーティリティは、pg_upgrade_internal.log と pg_upgrade_server.log の 2 つのログを生成します。Amazon RDS は、これらのログのファイル名にタイムスタンプを付加します。これらのログを表示して、アップグレード中に発生した問題とエラーに関する詳細情報を取得します。詳細については、RDS for PostgreSQL の場合は「Amazon RDS ログファイルのモニタリング」を参照し、Aurora for PostgreSQL の場合は「Amazon Aurora ログファイルのモニタリング」を参照してください。
- アップグレードが完了したら、すべてのユーザーデータベースで ANALYZE を実行して pg_statistics テーブルをアップグレードします。メジャーアップグレードでは、pg_statistics テーブルの内容は新しいバージョンに移動しません。このステップをスキップすると、クエリの実行速度が低下する可能性があります。
- 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;
関連情報
関連するコンテンツ
- 質問済み 6年前
- AWS公式更新しました 10ヶ月前
- AWS公式更新しました 2年前
- AWS公式更新しました 2年前
- AWS公式更新しました 1年前
