Amazon RDS を PostgreSQLのメジャーバージョンとマイナーバージョンにアップグレードするためのベストプラクティス

オープンソースの PostgreSQL は、頻繁に発生するバグ、セキュリティの問題、データ破損の問題の修正を含む新しいマイナーバージョンとメジャーバージョンをリリースすることがあります。一般的に、Amazon RDS は、新しいエンジンバージョンが利用できるようになってから 5 か月以内にサポートすることを目指しています。また、特定のバージョンがサポートされなくなった場合、RDS PostgreSQL インスタンスをアップグレードする必要があります。この場合、RDS は、データベースインスタンスのアップグレードを提案するメールを送信します。RDS コンソールまたは AWS CLI コマンド modify-db-instance を使用して、インスタンスをアップグレードできます。Auto Minor Version Upgrades を有効にすることで、インスタンスを適切なマイナーバージョンにアップグレードすることもできます。

RDS はアップグレードを管理しますが、一般的な問題、関連する手順、それにビジネスへの影響を最小限に抑えてアップグレードするためのベストプラクティスを把握しておく必要があります。この記事では、次のトピックを含む RDS PostgreSQL データベースエンジンのアップグレードについて説明します。

メジャーバージョンとマイナーバージョンのアップグレード中に起こること
アップグレード中の一般的な問題
Auto Minor Version Upgrades 機能の理解
アップグレードの準備

メジャーバージョンとマイナーバージョンのアップグレード

PostgreSQL 10 以降、たとえば 10 から 11 など、バージョン番号の最初の数字が増加することで、新しいメジャーバージョンにアップグレードしたことを示しています。2 番目の数字が、たとえば 10.4 から 10.9 に変わった場合、マイナーバージョンのアップグレードがあったことを示します。PostgreSQL 10 以前では、9.5 から 9.6 など 2 桁目の数字がメジャーバージョンを示し、9.6.5 から 9.6.10 など 3 桁目の数字がマイナーバージョンを示していました。

マイナーバージョンはセキュリティの脆弱性にパッチを当て、バグを修正するもので、通常は新しい機能を追加しません。マイナーリリースは内部ストレージ形式を変更することはなく、同じメジャーバージョン番号の以前のマイナーリリースと後続のマイナーリリースと常に互換性があります。たとえば、バージョン 10.4 はバージョン 10.1 とバージョン 10.6 と互換性があります。同様に、9.5.3 は 9.5.0、9.5.1、9.5.6 と互換性があります。互換性のあるバージョン間で更新するために、RDS はサーバーがダウンしている間にバイナリを置き換え、サーバーを再起動します。データディレクトリは変更されません。これが、マイナーアップグレードがメジャーアップグレードに比べて速い理由です。

PostgreSQL のメジャーリリースでは、システムテーブルの内部形式、データファイル、および内部データストレージ形式も変更されます。これにより、アップグレードが複雑になります。RDS は、メジャーアップグレードの実行に PostgreSQL ユーティリティ pg_upgrade を使用します。

マイナーバージョンとメジャーバージョンの両方のアップグレードで、RDS は次の手順を実行します。

アップグレード前のスナップショットを作成します (バックアップ用に設定されている場合) 。このスナップショットをロールバックに使用できます。
インスタンスをシャットダウンし、アップグレードの準備をします。
pg_upgrade ユーティリティを使用して、インスタンスでアップグレードジョブを実行します。
アップグレード後のスナップショットを取得します。これで、インスタンスでネットワークが再設定されました。

RDS が手順 1 を開始すると、インスタンスのステータスが Available から Upgrading に変わります。手順 4 の後、Available に戻ります。

次の表は、マイナーアップグレードとメジャーアップグレードの手順の大きな違いをまとめたものです。

	マイナーアップグレード	メジャーアップグレード
レプリカをアップグレード可能	はい	いいえ
アップグレードされたインスタンスに新しいカスタムパラメータグループが必要	いいえ	はい
自動的にアップグレード (Auto Minor Version Upgrades が RDS で設定されている場合)	はい	いいえ
データベースデータファイルを更新する	いいえ	はい
アップグレードされたインスタンスにテーブル統計をコピーする	はい	いいえ
アップグレードの一部として `VACUUM` を実行する	いいえ	はい
常に下位互換性がある	はい	いいえ

アップグレード中の一般的な問題

RDS Postgres のアップグレードで問題が発生する場合があります。これらの問題は、サポートされていないデータ型とデータベースオブジェクトに関連しています。データベースログファイル pg_upgrade.log には、これらの問題の詳細が含まれています。問題の一部を以下に示します。

INCOMPATIBLE_PARAMETER

このエラーは、shared_buffer や work_memory などのメモリ関連のパラメータが大きすぎるため、pg_upgrade スクリプトが失敗した場合に発生します。この問題を修正するには、値を減らしてアップグレードを再試行する必要があります。

STORAGE_FULL

pg_upgrade スクリプトの実行中に、インスタンスのスペースが不足する可能性があります。これにより、スクリプトが失敗します。次のようなエラーメッセージが表示されます。

pg_restore: [archiver (db)] Error while PROCESSING TOC: 
pg_restore: [archiver (db)] クエリが実行できませんでした: ERROR: "base/12345/12345678" ファイルの作成に失敗しました: デバイスに空きスペースがありません

この問題を解決するには、データベースとデータファイルの数に応じて、インスタンスに十分な空きストレージがあることをアップグレード中に確認してください。

論理複製スロット

データベースが論理複製スロットを使用している場合、メジャーバージョンのアップグレードは失敗し、次のメッセージが表示されます。

PreUpgrade チェックが失敗しました: 1 つ以上のデータベースに論理複製スロットがあるため、インスタンスをアップグレードできませんでした。すべての論理複製スロットを削除して、もう一度試してください。

この問題を解決するには、実行中の DMS または論理複製ジョブを停止し、既存の複製スロットをすべて削除します。次のコードを参照してください。

SELECT * FROM pg_replication_slots;
SELECT pg_drop_replication_slot(slot_name);

リリース日の依存性

ターゲットバージョンのリリース日が現在のバージョンのリリース日よりも古い場合、インスタンスをアップグレードできません。次のようなエラーメッセージが表示されます。

postgres を 9.5.12 から 9.6.6 にアップグレードできません (サービス: AmazonRDS; 状態コード: 400; エラーコード: InvalidParameterCombination; リクエスト ID: 12345ab-12345ab-12345-ab)

上記の例では、9.5.12 のリリース日は 2018 年 3 月 1 日で、9.6.6 のリリース日は 2017 年 11 月 9 日です。この問題を修正するには、PostgreSQL 公式リリースノートでリリース日を確認し、利用可能な最新のマイナーバージョンを見つけてください。

マスターユーザー名

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

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

これを解決するには、rds_superuser ロールを持つ別のユーザーを作成します。また、AWS プレミアムサポートに連絡して、このユーザーを新しいマスターユーザーに更新する必要があります。

Auto Minor Version Upgrades 機能の理解

RDS PostgreSQL インスタンスを Auto Minor Version Upgrades に設定できます。これにより、RDS があるバージョンを自動アップグレードできるようにするたびに自動的にマイナーアップグレードされます。たとえば、RDS PostgreSQL インスタンスが現在バージョン 10.5 で、Auto Minor Version Upgrades を有効にすると、次のメンテナンスウィンドウ中に 10.6 バージョンに自動的にアップグレードされます。RDS が自動的にアップグレードできるようにしない限り、それ以降のマイナーバージョンに自動的にアップグレードされることはありません。

すべてのマイナーバージョンが自動アップグレードを利用できるわけではありません。自動アップグレードを利用できるバージョンを見つけるには、次の CLI コマンドを入力します。

[ec2-user@ip- ~]$ aws rds describe-db-engine-versions --engine postgres | grep -A 1 AutoUpgrade| grep -A 2 true |grep PostgreSQL | sort --unique | sed -e 's/"Description": "//g' | sed -e 's/",//g'
PostgreSQL 10.6-R1
PostgreSQL 9.4.20-R1
PostgreSQL 9.5.15-R1
PostgreSQL 9.6.11-R1

マイナーバージョンのアップグレードの準備

マイナーバージョンのアップグレードの場合は、事前に以下の手順を完了してください。

公式リリースノートを確認して、新しいバージョンで導入された変更を理解します。
アップグレードパスに従って、現在のマイナーバージョン以降の適切なマイナーバージョンを見つけます。
AWS CLI コマンドを使用して、利用できるより上位の RDS PostgreSQL マイナーバージョンを見つけることができます。たとえば、現在 9.5.12 のバージョンにあるインスタンスの上位マイナーバージョンを検索するには、次の CLI コマンドを入力します。
```
[ec2-user@ip-~]$ aws rds describe-db-engine-versions --engine postgres --engine-version 9.5.12 | grep -A 500 "ValidUpgradeTarget"| grep "EngineVersion"| grep 9.5| sed -e 's/"//g' |sed -e 's/EngineVersion: /PostgreSQL /g'
PostgreSQL 9.5.13
PostgreSQL 9.5.14
PostgreSQL 9.5.15
PostgreSQL 9.5.16
PostgreSQL 9.5.18
PostgreSQL 9.5.19 
```
新しいマイナーバージョンでアプリケーションとワークロードをテストして、予想される停止とパフォーマンスを推定します。
アップグレードをテストするには、本稼働インスタンスのスナップショットを作成し、テスト環境で復元して、新しいマイナーバージョンにアップグレードします。アップグレード中の停止の可能性を制限するには、アップグレードを実行する前に、既存のすべての接続を閉じて手動スナップショットを作成し、アップグレード前のスナップショットがより速くなるようにします。
リードレプリカを使用して、マイナーバージョンアップグレード中の停止を最小限に抑えることもできます。リードレプリカを作成し、レプリカをマイナーアップグレードする必要があります。レプリカがソースインスタンスと同期している場合は、レプリカを昇格させ、アプリケーションを新しいマスターに向けます。

メジャーバージョンアップグレードの準備

メジャーバージョンのアップグレードについては、事前に以下の手順を完了してください。

PostgreSQL の公式リリースノートを確認し、ターゲットバージョンの変更に精通してください。
RDS アップグレードパスに従って、適切なターゲットメジャーバージョンを見つけます。
たとえば、現在バージョン 9.6.12 のインスタンスでは、次の CLI コマンドを使用します。
```
[ec2-user@ip-~]$ aws rds describe-db-engine-versions --engine postgres --engine-version 9.6.12 | grep -A 200 "ValidUpgradeTarget"|grep "EngineVersion"|  sed -e 's/"//g' |sed -e 's/EngineVersion: /PostgreSQL /g'
PostgreSQL 9.6.14
PostgreSQL 9.6.15
PostgreSQL 10.7
PostgreSQL 10.9
PostgreSQL 10.10
PostgreSQL 11.2
```
RDS PostgreSQL は、一度に複数のメジャーバージョンアップグレードをサポートするようになりました。
ターゲットバージョンのシステムカタログに応じて、VIEW を削除します。
たとえば、pg_stat_activity に依存する VIEW は、待機列が wait_event_type と wait_event に置き換えられたため、9.5 から 9.6 へのアップグレードに失敗します。

ターゲットバージョンに応じて、unknown データ型を削除します。
同様に、バージョン 10 は unknown データ型のサポートを停止しました。9.6 の unknown データ型は、9.6 から 10.6 へのアップグレードに失敗し、次のエラーメッセージが表示されます。

データベースインスタンスはアップグレードできない状態です: アップグレード前のチェックに失敗しました: 「unknown」データ型がユーザーテーブルで使用されているため、インスタンスをアップグレードできませんでした。「unknown」データ型の使用をすべて削除して、もう一度やり直してください」 以下はお客様の事例の一例です

データベースで unknown データ型を見つけて、問題の列を削除するか、次のコードを使用してサポートされているデータ型に変更します。

SELECT DISTINCT data_type FROM information_schema.columns where data_type ilike 'unknown';

ターゲットメジャーバージョンの新しい RDS インスタンスを作成し、pg_dump/ pg_restore を実行して、下位バージョンから上位バージョンにデータをコピーします。
メジャーバージョンアップグレードの一部として、pg_upgrade プログラムはデータファイルをコピーし、新しいバージョンをサポートするために必要な変更を復元します。この手順により、前述の問題を回避できます。
このテスト中にエラーが発生した場合、アップグレードでも同じエラーが発生する可能性があります。スムーズにアップグレードするには、これらの問題を解決する必要があります。
セッションで maintenance_work_mem の値を増やして手動 VACUUM を実行します。次のコードを参照してください。
```
psql -U postgres -h pg1001.abc1abc1.us-west-2.rds.amazonaws.com -U master_user -d pgbench << EOF
SET maintenance_work_mem TO '512 MB';
VACUUM;
EOF
```
pg_upgrade スクリプトの一部として、VACUUM はすべてのデータベースで実行されます。データベースで VACUUM が長時間適切に実行されていない場合、このプロセスには時間がかかる可能性があります。
アップグレードの前に、既存の接続をすべて閉じて、手動スナップショットを作成します。
メジャーアップグレードの一部として、停止中にスナップショットが作成されます。EBS スナップショットは増分であるため、アップグレードの前にスナップショットを作成すると、全体的な停止が減少します。CLI create-db-snapshot を使用して、RDS インスタンスのスナップショットを取得できます。
アップグレード中にカスタムパラメータグループを用意します。
カスタムパラメータグループを使用している場合、ターゲットバージョンの新しいパラメータグループが必要です。カスタムパラメータグループを適用するには、インスタンスを再起動する必要があります。
ALTER EXTENSION UPDATE コマンドで拡張機能をアップグレードします。
メジャーバージョンのアップグレードでは、PostgreSQL 拡張機能はアップグレードされません。次のコード例は、インスタンスを 9.4 から 9.5 にアップグレードするときに PostGIS 拡張機能をアップグレードします。
```
ALTER EXTENSION POSTGIS UPDATE TO '2.2.5';
```
レプリカインスタンスを昇格または削除します。
RDS Postgres では、リードレプリカを異なるメジャーバージョンにすることはできません。ソースインスタンスでメジャーアップグレードを準備する場合は、この手順を完了してください。

必要に応じて、スケールストレージを実行して、メジャーバージョン用に 15%～20% の空きストレージを用意します。
または、RDS ストレージの自動スケーリングを有効にして、予期しないスペースの問題を軽減します。

rds.logical_replication パラメータを 0 に設定して、アップグレードする RDS インスタンスに依存する DMS タスクを停止します。
アップグレードが完了したら、すべてのユーザーデータベースで ANALYZE を実行して pg_statistics テーブルをアップグレードします。メジャーアップグレードでは、pg_statistics テーブルのコンテンツは新しいバージョンに移動しません。この手順をスキップすると、SQL クエリが遅くなる可能性があります。
本番環境のデータベースをアップグレードする前に、予行アップグレードを実行することもできます。本稼働インスタンスのスナップショットを復元して、予行アップグレードを実行できます。アップグレードされたデータベースで同様のワークロードを使用してアプリケーションをテストし、すべてが期待どおりに機能することを確認することをお勧めします。アップグレードの検証後、このテストインスタンスは削除しても構いません。
マルチ AZ 設定は、データベースエンジンのアップグレード中の停止を回避するのに役立ちません。マルチ AZ は、インスタンススケールのコンピューティング中の停止時間を短縮しますが、データベースエンジンのアップグレード中にストレージレベルの変更が必要になるため、両方のインスタンスが同時にアップグレードされます。
データベースが停止の影響を受けやすい場合は、AWS DMS、logical replication、または pglogical 拡張を使用して、2 つの異なるメジャーバージョン間のレプリケーションをセットアップできます。両方のインスタンスが同期されたら、カットオーバーして、アプリケーションを新しいマスター RDS インスタンスに向けます。アプリケーションが変更を必要としないように、同じリージョンとアカウントのインスタンスの名前を変更することもできます。

まとめ

AWS は、データベースのアップグレードエクスペリエンスの信頼性と効率をこれからも向上させていきます。RDS PostgreSQL のバージョンアップグレードにより、高度なデータセキュリティ、新機能、より良いパフォーマンスが得られます。RDS はシングルクリックのマイナーアップグレードとメジャーアップグレードを管理しますが、ワークロードへの予想される変更、潜在的な停止を把握し、ターゲットバージョンでアプリケーションをテストするのはお客様の責任です。

以下の関連リソースは、RDS Postgres のアップグレードについてより深く理解するのに役立ちます。

この記事に関する質問または提案などがありましたら、ぜひコメントを残してください。

著者について

Vivek Singh は、RDS/Aurora PostgreSQL エンジンを専門とする AWS のシニアデータベーススペシャリストです。Vivek はエンタープライズカスタマーと連携して、PostgreSQL の運用パフォーマンスに関する技術的なサポートを提供し、データベースのベストプラクティスをもたらしています。

Amazon Web Services ブログ