はじめに

メリークリスマス！この記事は Qiita AWS ADVENT Calendar 2の25日目の記事です。

qiita.com

最近、Postgres 9.6を 13.3 にアップグレードしました。マネジメントコンソールからポチポチするだけで簡単に上がるだろうと思っていましたが、思っていた以上に色々ハマったので記事として残します。

アップグレードの経緯

今年の3月に Postgres 9.6 がサポート終了されるというアナウンスがされました。

aws.amazon.com

また、 Management Console 上でも、2022年1月18日に PostgreS 9.6を、強制的に 12にアップグレードするという警告メッセージが表示されていました。

f:id:yokoyantech:20211224144530p:plain

いつかやろうやろうと思っていたものもあっという間に年末になってしまいました。締め切り直前にバタバタするのも嫌だったので、重い腰を上げて、現在利用している PostgreS 9.6をアップグレードすることにしました。

結論

RDS のインスタンスタイプは定期的に最新化しておくのが良い

私がアップグレードした環境

マルチ AZ の環境で以下のとおり、アップグレードを実施しました。

	アップグレード前	アップグレード後
エンジンバージョン	9.6.22	13.3
インスタンスクラス	db.t2.medium	db.t3.medium

公式のアップグレード手順

AWS 公式で確認することができます。基本的には公式の手順に従っていくことになります。

Amazon RDS の PostgreSQL DB エンジンのアップグレード

実施した手順

アップグレードできるバージョンの確認

まずはじめに、アップグレードすることができるバージョンの確認を行います。

Postgres 9.6.x 系を使用していたとしても、細いバージョンが違うと、アップグレードできるターゲットが異なるので注意が必要です。

9.6.20 の場合は、 13.1 にアップグレードすることができますが、 9.6.19 を使用している場合は、 12.4 がアップグレードターゲットになります。

Amazon RDS の PostgreSQL DB エンジンのアップグレード

私の環境では、 9.6.22 でしたので、 13.3 にアップグレードできることがわかりました。

Postgres13用のパラメータグループを作成

独自のパラメータグループを設定している場合、Postgres13用のパラメータグループを作成する必要があります。

現行のRDSのパラメータグループをデフォルトに戻す

私の環境では、パラメータグループをデフォルトから変更しています。大したパラメーター修正は行なっていないのですが、互換性がないためか、そのままアップグレードすることができませんでした。

ちなみに修正していたパラメータグループのパラメーターは以下の2つです。

tcp_keepalives_idle
tcp_keepalives_interval:30

アップグレードを行う前に一旦、現行の RDS のパラメータグループをデフォルトのものに戻しました。

現行のインスタンスクラスを更新する

古いインスタンスタイプを使っている場合、インスタンスタイプの変更と同時にデータベースのバージョンをアップグレードすることができませんでした。

私の環境は4年くらい前に作成したため、利用しているインスタンスクラスが、 db.t2.medium と古いです。Postgres13にアップグレードする際に、インスタンスクラスを db.t4g.medium に変更しようと試みましたが、以下のエラーが発生してしまいました。

DB インスタンス hoge-db の変更のリクエストが失敗しました。RDS does not support creating a DB instance with the following combination: DBInstanceClass=db.t2.medium, Engine=postgres, EngineVersion=13.3, LicenseModel=postgresql-license. For supported combinations of instance class and database engine version, see the documentation.

ひとまず、Postgres のアップグレード作業は中断し、インスタンスクラスだけを db.t3.medium に変更しました。

アップグレード前の現行 DBチェック

インスタンスクラスを変更後に、RDSのアップグレード作業に取り掛かりました。

まず初めに準備済みのトランザクションがいないことを確認します。

SELECT count(*) FROM pg_catalog.pg_prepared_xacts;

サポートされていない 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');

地理情報やUSの住所最適化モジュールなどの特定の拡張機能を使用している場合は個別に更新する必要があります。私の環境では使用していなかったため、この作業はスキップしました。

address_standardizer
address_standardizer_data_us
postGIS
postgis_tiger_geocoder
postgis_topology

続いて、データベース内の unknown データ型を検索します。私の環境ではこちらも特に問題はありませんでした。

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

DBバージョンとパラメータグループを変更する

マネジメントコンソールから、Postgres 13 へのアップグレードと、パラメータグループをPostgres 13 用に変更しました。

アップグレード後の作業

CPUが100%になるという話をいろんなところで聞いていたため、 pg_statistic テーブルを更新する ANALYZE 操作を実行しました。

ANALYZE VERBOSE;

アップグレードの所要時間

シングル AZ の環境で検証したところ、約20分のダウンタイムが発生しました。

実際のアップグレード環境は、マルチ AZ だったため、ダウンタイムは発生しないのではないかと期待していましたが、結構ガッツリ止まりました。アップグレードが完了するまでデータベースに接続することができず、なんだかんだで利用可能のステータスになるまで24分ほどかかりました。

プロダクション環境などのアプリケーションで RDS を使用している場合は、事前の告知とメンテナンス画面の表示などのケアが必要だと思います。

まとめ

Postgres 13 にアップグレードした後は特に大きな問題は発生していません。2022年1月18日に強制的にアップグレードされてしまうため、今回の記事が誰かのお役に立てば幸いです。

紙一重の積み重ね

アラフォーのエンジニアがなれる最高の自分を目指して、学んだことをこつこつ情報発信するブログです。

AWS RDS PostgreSQL 9.6から13.3にアップグレードしたときにハマったことまとめ