Amazon RDS for PostgreSQL または Aurora PostgreSQL 互換のメジャーバージョンアップグレードに関する問題をトラブルシューティングする方法を教えてください。

簡単な説明

マイナーバージョンアップグレードは、同じメジャーバージョンの以前のマイナーリリースおよびそれ以降のマイナーリリースと互換性があります。ただし、メジャーバージョンのアップグレードには、既存のアプリケーションとの下位互換性のないデータベース変更が含まれています。これらのアップグレードにより、システムテーブル、データファイル、データストレージの内部形式が変更される可能性があります。Amazon RDS は pg_upgrade を使用してメジャーバージョンのアップグレードを実行します。詳細については、PostgreSQL のウェブサイトで pg_upgrade を参照してください。

メジャーバージョンのアップグレード中、Amazon RDS はアップグレードが失敗する原因となる可能性のある問題を特定する事前チェック手順を実行します。すべてのデータベースで、互換性のない条件である可能性があるものをチェックします。Amazon RDS は事前チェックプロセス中に問題を特定すると、失敗した事前チェックに関するログイベントを作成します。ログイベントには、ファイル名、タイムスタンプ、アップグレードが失敗した理由が含まれます。すべてのデータベースでの事前チェックプロセスについては、pg_upgrade_precheck.log ログを確認してください。ただし、エンジン固有の問題については、Amazon RDS for PostgreSQL または Aurora PostgreSQL のデータベースログファイルを確認する必要があります。

解決策

メジャーバージョンアップグレードを実行する pg_upgrade ユーティリティは、pg_upgrade_internal.log と pg_upgrade_server.log という 2 つのログを生成します。Amazon RDS はこれらのログのファイル名にタイムスタンプを追加します。これらのログを参照して、アップグレード中に発生した問題とエラーに関する詳細情報を確認してください。詳細については、「Amazon RDS ログファイルのモニタリング」または「Amazon Aurora ログファイルのモニタリング」を参照してください。

アップグレードに時間がかかる

保留中のメンテナンスアクティビティを確認する

Amazon RDS は、エンジンバージョンのアップグレードを自動的に使用して、RDS インスタンスのオペレーティングシステム (OS) パッチなどの保留中のメンテナンスアクティビティを適用します。Amazon RDS は保留中のアクティビティを最初に適用してから、エンジンバージョンをアップグレードします。Amazon RDS が OS のメンテナンスアクティビティを実行する必要がある場合、アップグレードに時間がかかります。

RDS インスタンスがマルチ AZ 配置にある場合、OS のメンテナンスによりフェイルオーバーが発生します。マルチ AZ でインスタンスを設定すると、Amazon RDS は通常、セカンダリインスタンスにインスタンスのバックアップを作成します。フェイルオーバーでは、Amazon RDS はアップグレード後に新しいセカンダリインスタンスにバックアップを作成します。新しいセカンダリインスタンスのこのバックアップは最新のバックアップではない可能性があるため、Amazon RDS は増分バックアップではなく完全バックアップを実行します。完全バックアップは、特にデータベースが大きい場合に時間がかかる場合があります。

この問題を回避するには、RDS DB インスタンスまたは Aurora DB インスタンスの保留中のメンテナンスアクティビティを検索してください。または、インスタンスで次の AWS コマンドラインインターフェイス (AWS CLI) コマンド describe-pending-maintenance-actions を実行します。

aws rds describe-pending-maintenance-actions --resource-identifier example-arn

注: example-arn は、お使いの DB インスタンスの ARN に置き換えます。AWS CLI のコマンドの実行時にエラーが発生する場合は、「AWS CLI でのエラーのトラブルシューティング」を参照してください。また、AWS CLI の最新バージョンを使用していることを確認してください。

データベースエンジンのバージョンをアップグレードする前に、保留中のメンテナンス作業を完了してください。

アップグレード前にスナップショットを作成する

バージョンをアップグレードする前に、RDS DB インスタンスまたは Aurora DB クラスターのスナップショットを作成するのがベストプラクティスです。インスタンスのバックアップを既に有効にしている場合、Amazon RDS はアップグレードプロセスの一環として自動的にスナップショットを作成します。Amazon RDS はアップグレードの一環として増分バックアップを作成するだけで済むため、スナップショットを使用するとアップグレード処理時間を短縮できます。

リードレプリカのアップグレードを待機する

プライマリ DB インスタンスのメジャーバージョンアップグレードを実行すると、Amazon RDS は同じ AWS リージョンのすべてのリードレプリカを自動的にアップグレードします。アップグレードワークフローが開始されると、リードレプリカはプライマリ DB インスタンスで pg_upgrade が正常に完了するまで待機します。その後、プライマリ DB インスタンスのアップグレードは、リードレプリカのアップグレードが完了するまで待機します。すべてのアップグレードが完了するまで、機能停止が発生します。アップグレードのダウンタイム期間が短い場合は、レプリカインスタンスをプロモートまたは削除し、アップグレードの完了後にリードレプリカを再作成します。

Aurora DB クラスターでは、pg_upgrade は最初にライターインスタンスをアップグレードします。その後、pg_upgrade が新しいメジャーバージョンにアップグレードされると、各リーダー DB インスタンスが停止します。Aurora グローバルデータベースをアップグレードする場合、追加の要件とプロセスがあることに注意してください。

アップグレード前に実行時間の長いトランザクションや高負荷を解決する

トランザクションが長く実行していたり、ワークロードが高くなったりすると、Amazon RDS がデータベースをシャットダウンしてデータベースエンジンをアップグレードするのにかかる時間が長くなる可能性があります。

長時間実行されているトランザクションを識別するには、次のクエリを実行します。

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_cancel_backend または pg_terminate_backend を使用してクエリを終了します。これらの関数の詳細については、「9.28.2.サーバーシグナリング関数」を参照してください。

十分な計算能力があることを確認する

pg_upgrade ユーティリティでは計算負荷が高くなる場合があります。本番データベースをアップグレードする前にドライランアップグレードを実行して、十分な計算容量やメモリ容量があることを確認するのがベストプラクティスです。ドライランアップグレードでは、事前チェックエラーまたはアップグレードエラーの可能性についてもチェックされます。本番インスタンスのスナップショットを復元すると、本番データベースと同じインスタンスクラスでドライランを実行できます。

アップグレードが失敗する

サポートされていない DB インスタンスクラスを確認する

DB インスタンスのインスタンスクラスがアップグレード先の PostgreSQL バージョンと互換性がない場合、アップグレードは失敗します。エンジンバージョンと、Amazon RDS または Amazon Aurora のインスタンスクラスとの互換性を確認してください。

開いた状態の準備済みトランザクションを確認する

データベースで準備済みのトランザクションが開いている場合、アップグレードは失敗します。pg_upgrade.log ファイルに「コミットされていない準備済みトランザクションがあります」というエラーが表示されます。アップグレードを開始する前に、開いている準備済みトランザクションをすべてコミットまたはロールバックします。

インスタンスに開いた状態の準備済みトランザクションがあるかどうかを確認するには、次のクエリを実行します。

SELECT count(*) FROM pg_catalog.pg_prepared_xacts;

サポートされているデータ型を使用していることを確認する

regclass、regrole、regtype データタイプのバージョンのみをアップグレードできます。pg_upgrade ユーティリティは、reg* オブジェクト識別子 (OID) 参照タイプを使用するテーブル列を含むデータベースをアップグレードできません。regcollation、regconfig、regdictionary、regnamespace、regoper、regoperator、regproc、regprocedure データ型を使用していると、アップグレードは失敗します。

この問題を解決するには、データエンジンをアップグレードする前に、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');

論理レプリケーションスロットをチェックする

インスタンスに論理レプリケーションスロットがある場合、インスタンスをアップグレードできず、pg_upgrade.log ファイルに次のエラーが表示されます。

「1 つ以上のデータベースに論理レプリケーションスロットがあるため、インスタンスをアップグレードできませんでした。すべての論理レプリケーションスロットを削除してから、再試行してください。」

論理レプリケーションスロットは通常、AWS Database Migration Service (AMS DMS) の移行に使われます。また、データベースからデータレイク、ビジネスインテリジェンスツール、その他のターゲットにテーブルを複製するためにも使われます。使用中の論理レプリケーションスロットの目的を把握して、削除できるかどうかを確認してください。論理レプリケーションスロットが使用中の場合は、削除しないでください。論理レプリケーションスロットを削除できるようになるまで、バージョンのアップグレードを待つ必要があります。

論理レプリケーションスロットが必要ない場合は、次のクエリを実行して削除します。

SELECT * FROM pg_replication_slots;

SELECT pg_drop_replication_slot(slot_name);

注: slot_name は、論理レプリケーションスロットの名前に置き換えます。

ストレージの問題を確認する

pg_upgrade スクリプトの実行時にインスタンスの容量が不足すると、アップグレードは失敗し、次のエラーが発生します。

「pg_restore: [archiver (db)] TOC の処理中にエラーが発生しました。pg_restore: [archiver (db)] はクエリを実行できませんでした。 エラー: ファイル "base/12345/12345678" を作成できませんでした。 デバイスに空きキーワードがありません」

この問題を解決するには、アップグレードを開始する前に、インスタンスに十分な空きストレージがあることを確認してください。

unknown データ型を確認する

PostgreSQL バージョン 10 以降では、unknown データ型を使用することはできません。たとえば、PostgreSQL バージョン 9.6 のデータベースが unknown データ型を使用している場合、バージョン 10 にアップグレードすると次のエラーが表示されます。

「ユーザーテーブルで 'unknown' データ型が使用されているため、インスタンスをアップグレードできませんでした。'unknown' データ型の使用をすべて削除してから、再試行してください。」

この問題を解決するには、unknown データ型を使用する列を手動で削除するか、サポートされているデータ型に変更します。unknown データ型を使用しているデータベース内の列を見つけるには、次のクエリを実行します。

SELECT DISTINCT data_type FROM information_schema.columns WHERE data_type ILIKE 'unknown';

(RDS for PostgreSQL のみ) リードレプリカのアップグレードが失敗したかどうかを確認する

PostgreSQL インスタンスにリードレプリカがある場合、リードレプリカのアップグレードが失敗すると、プライマリインスタンスのアップグレードが停止したり失敗したりする可能性があります。Amazon RDS は、障害が発生したリードレプリカを非互換復元状態に設定し、DB インスタンスでのレプリケーションを停止します。

リードレプリカのアップグレードは、次のいずれかの理由で失敗する可能性があります。

• リードレプリカが、待機時間が経過してもプライマリ DB インスタンスに追いつくことができない。
• ストレージがいっぱいになったり、互換性がない状態で復元されたりするなど、リードレプリカがライフサイクルの終端または非互換状態になっている。
• プライマリ DB インスタンスのアップグレード開始時に、リードレプリカで別のマイナーバージョンアップグレードが実行されている。
• リードレプリカが互換性のないパラメータを使用している。
• リードレプリカがプライマリ DB インスタンスと通信してデータフォルダを同期できない。

この問題を解決するには、リードレプリカを削除します。次に、アップグレード後に、アップグレードしたプライマリインスタンスに基づいて新しいリードレプリカを再作成します。

プライマリユーザー名が正確であることを確認する

プライマリユーザー名が pg_ で始まる場合、アップグレードは失敗し、次のエラーメッセージが表示されます。

「アップグレード前のチェックに失敗しました。 1 つ以上のロール名が 'pg_' で始まるため、インスタンスをアップグレードできませんでした。名前が 'pg_' で始まるすべてのロールの名前を変更してから、再試行してください。」

この問題を解決するには、先頭が pg_ ではなく、rds_superuser ロールを持つ別のユーザーを作成します。

互換性のないパラメータを確認する

互換性のないパラメータエラーは、shared_buffer や work_memory などのメモリ関連のパラメータの値が設定に対して高すぎる場合に発生します。このエラーにより、アップグレードスクリプトが失敗します。問題を解決するには、これらのパラメータの値を減らしてから、アップグレードを再実行します。

アップグレード前に拡張機能を更新する

メジャーバージョンをアップグレードしても PostgreSQL の拡張機能はアップグレードされません。メジャーバージョンアップグレードの前に拡張機能を更新しないと、pg_upgrade.log ファイルに次の例のようなエラーが表示されます。

"ログは、RDS インスタンス ''abcd'' に古いバージョンの PostGIS 拡張または、その依存拡張 (address_standardizer,address_standardizer_data_us, postgis_tiger_geocoder, postgis_topology, postgis_raster) がインストールされていることを示しています。アップグレードには現在のバージョンが必要です。"

上記のエラー例は、PostGIS 拡張に問題があることを示しています。この問題を解決するには、次のクエリを実行して、PostGIS とその依存拡張のデフォルトバージョンとインストールバージョンを確認します。

SELECT name, default_version, installed_versionFROM pg_available_extensions WHERE installed_version IS NOT NULL AND
name LIKE 'postgis%' OR name LIKE 'address%';

注: postgis% は実際の拡張に置き換えます。

installed_version の値が default_version の値よりも低い場合は、PostGIS をデフォルトバージョンに更新する必要があります。拡張機能をアップグレードするには、次のクエリを実行します。

ALTER EXTENSION extension_name UPDATE TO 'default_version_number';

注: default_version_number を default_version の値に置き換えます。

詳細については、「RDS for PostgreSQL DB エンジンのアップグレード」または「Amazon Aurora PostgreSQL DB クラスターのアップグレード」を参照してください。

対象バージョンのシステムカタログの変更が原因でビューに問題が発生していないかを確認する

一部のビューの列は、PostgreSQL のバージョンによって異なります。たとえば、次の例のようなエラーが表示される場合があります。

「アップグレード前のチェックに失敗しました。 1 つ以上のデータベースに 'pg_stat_activity' に依存するビューまたはマテリアライズドビューがあるため、インスタンスをアップグレードできませんでした。それらを削除してから、再試行してください。」

このエラーは、データベースをバージョン 9.5 から 9.6 にアップグレードしたときに発生します。上記の例では、pg_stat_activity ビューが問題の原因となっています。バージョン 9.6 では、PostgreSQL の waiting 列が wait_event_type 列と wait_event 列に置き換えられました。

または、次のようなエラーが表示される場合があります。

"pg_restore: from TOC entry abc; abc abcd VIEW sys_user_constraints art pg_restore: error: クエリを実行できませんでした。 エラー: 列 c.consrc は存在しません。LINE 18: "c"."consrc" AS "search_condition", ^ HINT: おそらく "c.conkey" 列または "c.conbin" 列の参照が試みられました。"

この例では、PostgreSQL バージョン 12 で pg_constraint カタログの構造が変更されたためにエラーが発生します。

これらの問題を解決するには、ターゲットバージョンのシステムカタログに基づいてビューを削除してください。

重要: pgdump を使用してビューをバックアップするか、ビューを削除する前にビューの定義をキャプチャするのがベストプラクティスです。ビューを削除する場合、バージョンアップグレード後に手動でビューを再作成する必要があります。データベース管理者と連携する必要がある場合があります。

アップグレード後

アップグレードが完了したら、すべてのユーザーデータベースで ANALYZE を実行し、pg_statistics テーブルをアップグレードします。メジャーアップグレードでは、pg_statistics テーブルのコンテンツは新しいバージョンに移動されません。コンテンツを移動しないと、クエリの実行速度が遅くなる可能性があります。

関連情報

Aurora PostgreSQL のアップグレードプロセスの概要