RDSのPostgresを9.6.22から13.4へアップグレードまとめ

なかなか大変なPostgresアップグレード

RDSでは、大分前からPostgresの9.6のサポート切れるので、自動でアップグレードされちゃうようになるから、早めに自分たちでアップグレードしてねーというような旨の通知が出ていたのですが、いよいよその自動アップグレードの日にちが近づいて来たので、重い腰を上げてアップグレードに取り組みました。

前提

当方のRDSの環境

早速テスト環境を作りアップグレードを試みるも…

まずは、本番環境からスナップショットを取り、それを復元させて本番と同等のものを用意してアップグレードさせてみることにしてみました。

9.6.22から13.4へ直でアップグレードさせてみる

最初に試みたこととして、9.6.22から13.4へ直接アップグレードしてみました。

しかし、アップグレードは出来ず、エラーログが吐かれました。因みにエラーログはconsoleのログとイベントタブから見ることが出来ます。名前でソートされているので、最終書き込みでソートするようにしましょう。

エラーの内容的には、当方が使用しているextensionで引っかかっているとのことでした。

extensionを使用していないのであれば、もしかしたらすんなり13.4までアップグレード出来ていたのかもしれません。。

9.6.22から9.6.23へのアップグレード

ここで、気になることが。マイナーバージョンの自動アップグレードはONにしてあるのに、9.6.23へのアップグレード選択があります。

9.6.22から9.6.23へのアップグレードってマイナーバージョンのアップグレードではないのかなぁとは思いつつ、まず9.6.23へアップグレードさせることにしました。

9.6.23から10.18へのアップグレード

10.18にアップグレードをする前に、9.6.23でPostgisをアップデートしました。

ALTER EXTENSION postgis UPDATE;

これによって、とりあえず次の10.18へアップグレードが出来るようになりました。

10.18から13.4へのアップグレード

10.18から13.4にアップグレードを試みると、またエラーが発生しました。エラーの内容を確認すると、Postgisに関連するextesionで問題が起きているとのことでした。

Postgres10.18では、postgis_extensions_upgrade(); という関数が用意されていて、これを実行することでPostgisに関連するextensionもアップデートされるようです。なので、13.4にアップグレードする前に、関連extesionをアップデートしました。

SELECT postgis_extensions_upgrade();

これによって、11系・12系を飛ばし、一気に13.4へアップグレードが出来るようになりました。

最新にしたものの全然スピードが出ない…

一応、上記の通りで、最新のversionへのアップグレードでは出来たのですが、いざ接続してみると全然スピードが出なかったのです…。

そこで色々と調査をして以下のことをすることで、元のスピード以上の応答速度にすること出来ました。

REINDEXする

良く書かれているのですが、VACUUMと並べて出てくることの多いREINDEXを行いました。そして、結論として、VACUUMよりも先にREINDEXを行った方が良いのではないかと思っています。

理由としては、REINDEXし終わった後であれば、VACUUMが圧倒的に早く終わったからです。VACUUM→REINDEXの順でやると、VACUUMも時間掛かるし、REINDEXも時間掛かったので…。

REINDEX DATABASE DB名;

途中経過を表示したいのであれば、(VERBOSE)を入れます。

REINDEX (VERBOSE) DATABASE DB名;

書き込みロックを掛けずに、同時にREINDEXを行う。ただし、通常よりも時間が掛かってしまうようなので、本番では自分は使用しませんでした。CONCURRENTLYも試しましたが、結局、REINDEXが終わるまで、応答速度のスピードが全然でなかったので…。

REINDEX CONCURRENTLY DATABASE DB名;

VACUUMする

VACUUM FULLするのは流石にしんどいので、単純なVACUUM ANALYZEを使用しました。

VACUUM ANALYZE;

パラメーターをチューニングする

9.6系でも既にあったeffective_cache_sizeやwork_memはチューニング済みでしたが、10から追加されたパラレルワーカー系のパラメーターを少し弄りました。

max_parallel_workers = 16;
max_parallel_workers_per_gather = 4;

まとめ

上記を一通りやることで、元のスピード以上の応答速度が出ました！

シミュレーションも含め、結構時間が掛かって大変でしたが、Postgresへの知識が少し増えたような気がします。