先日、RDS for PostgreSQL / Aurora PostgreSQL のメジャーバージョンアップグレードを実施しました。その際に実施した手順や注意点などをまとめてみました。

私にとっては今回が初めてのPostgreSQLメジャーバージョンアップグレードで、社内にも同様の経験を持つメンバーはおらず、過去の手順書やナレッジも残っていない状態からのスタートでした。そのため、一から手順を調べ、試行錯誤しながら進めることになり、正直かなり大変でした。

とはいえ、その分多くの学びや気づきも得られたので、この記事が同じような状況でアップグレードに取り組む方の一助となれば幸いです。

背景

RDS for PostgreSQL / Aurora PostgreSQL で使用中のバージョンが、まもなく標準サポート終了 (EOL)が迫っており、それらを対象にバージョンアップ対応を行う必要がありました。

期日までに対応しないと、以下のようなリスクや問題が発生します：

• 延長サポート移行による追加コストの発生
• コミュニティからのセキュリティパッチが提供されなくなり、セキュリティリスクが高まる
• 依存ライブラリやツールとの互換性問題が起きやすくなる
• 新しい機能が使えない

そのため、期日までに計画的に進める必要がありました。

進め方

対応は、以下のような流れで進めました：

1. スケジュール決め
2. 破壊的変更の有無確認、対応
3. AWS公式ドキュメントを参考に手順作成
4. メンテナンスタイム調整、ユーザーアナウンス
5. 開発環境、テスト環境でアップグレード
6. • うまくいかなかった手順を修正する
6. 本番環境でアップグレード

また、具体的な手順はAWSの公式ドキュメントを参考にしました。

• RDS for PostgreSQL のメジャーバージョンアップグレードを実行する方法
• Amazon Aurora PostgreSQL DB クラスターのアップグレード

なお、RDS と Aurora でアップグレードの手順に大きな違いはありません。

事前確認

基本的にAWSの公式ドキュメント通りに進めれば問題ないと思いますが、ドキュメントだけでは分かりにくい部分があったので補足します。

アップグレードの障壁になるオブジェクトの確認

Prepared Transaction

• 分散トランザクション等で利用されますが、一般的な運用では使用されることはほとんどないと思います。
• 念の為使用しているか確認し、使用している場合は削除または完了させましょう。

SELECT count(*) FROM pg_catalog.pg_prepared_xacts;

→ 結果が 0 であれば OK。

Reg* データ型

• regclass や regproc など、OID を扱う特殊なデータ型で、こちらも通常の運用で使うことは少ないと思います。
• 念の為使用しているか確認し、使用している場合は削除しましょう。

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');                               

→ 結果が 0 であれば OK。

メジャーバージョンのアップグレード前に特定のエクステンションを更新する

• アップグレードでメジャーバージョンをスキップする場合、メジャーバージョンのアップグレード前に以下のエクステンションを更新する必要があります。
• • address_standardizer
  • address_standardizer_data_us
  • postgis_raster
  • postgis_tiger_geocoder
  • postgis_topology

メジャーバージョンのアップグレード前の特定のエクステンションの削除

• PostgreSQL 11以降を使用している場合は対応不要です。
• メジャーバージョンをスキップして PostgreSQL 11.x にアップグレードする場合は 事前に削除が必要です。アップグレード後に再インストール可能です。
• • pgRouting
• PostgreSQL 11 以降では 非サポートのため、アップグレード前に削除する必要あります。
• • tsearch2
  • chkpass

unknown データ型の削除

• PostgreSQL バージョン9.Xを使用している場合は確認が必要ですが、バージョン10以降を使用している場合は対応不要です。

本番作業手順

スナップショット取得

万が一のトラブルに備えて、アップグレード前にスナップショットを取得しておくようにしましょう。何か問題が発生した場合でも、直前の状態にすぐに切り戻せるようにしておくことで、サービスへの影響を最小限に抑えることができます。

# RDSの場合
aws rds create-db-snapshot --db-instance-identifier XXX --db-snapshot-identifier XXX-YYYYMMDD
# Auroraの場合
aws rds create-db-cluster-snapshot --db-cluster-identifier XXX --db-cluster-snapshot-identifier XXX-YYYYMMDD

スナップショットが正しく取得されたか確認します。

# RDSの場合
aws rds describe-db-snapshots | jq -r '.DBSnapshots[] | select(.SnapshotType == "manual") | select(.SnapshotCreateTime >= "YYYY-MM-DDTHH:MM:SS.000000+09:00") | "\(.DBSnapshotIdentifier) \(.Status)"'
# Auroraの場合
aws rds describe-db-cluster-snapshots | jq -r '.DBClusterSnapshots[] | select(.SnapshotType == "manual") | select(.SnapshotCreateTime >= "YYYY-MM-DDTHH:MM:SS.000000+09:00") | "\(.DBClusterSnapshotIdentifier) \(.Status)"'

なお、Aurora PostgreSQLのメジャーバージョンアップグレード時には、自動的にスナップショットが取得されます。

新しいメジャーバージョンへのアップグレードプロセスを開始するとき、Aurora PostgreSQL はクラスターに変更を加える前に Aurora DB クラスターのスナップショットを取得します。このスナップショットは、メジャーバージョンのアップグレード用にのみ作成され、マイナーバージョンのアップグレードでは作成されません。

参考: メジャーバージョンアップグレードの実行

アップグレード

再現性を高めるために、アップグレードはAWS CLIを用いて実行します。これにより、本番環境と同様の条件での手順で実施できるようになります。

例えば、RDSやAuroraの場合、それぞれ以下のようなコマンドでアップグレードを実行します。

# RDSの場合 (パラメータグループを指定する)
aws rds modify-db-instance --db-instance-identifier XXX --engine-version XX.XX --db-parameter-group-name XXX --apply-immediately --allow-major-version-upgrade
# Auroraの場合 (パラメータグループを指定する)
aws rds modify-db-cluster --db-cluster-identifier XXX --engine-version XX.XX --db-cluster-parameter-group-name XXX --db-instance-parameter-group-name XXX --apply-immediately --allow-major-version-upgrade

アップグレード時のオプションで新しいパラメータグループを関連付けた場合、設定を反映させるにはアップグレード完了後にデータベースの再起動をする必要があります。アップグレードが完了しても自動で再起動は行われないため、手動で再起動を実施する必要があります。

# RDS、Auroraも同じ
aws rds reboot-db-instance --db-instance-identifier XXX

クラスタパラメータグループやインスタンスパラメータグループのステータスが「同期中」になっていることを確認してください。

ANALYZE実行

PostgreSQLでは、クエリの実行計画を決定する際に統計情報を活用します。統計情報が不正確な状態だと、実際のデータ特性に合わない非効率な実行計画が選ばれてしまい、パフォーマンスの低下を招く可能性があります。

メジャーバージョンアップ後は統計情報が初期化されるため、非効率な実行計画に基づきクエリが実行されてしまいます。そのため、アップグレード完了後には必ず ANALYZE を実行し、統計情報を最新の状態に更新する必要があります。

vacuumdb \$DATABASE_URL -j 8 --analyze-only -v

なお、ANALYZEの実行中にセッションが終了しない・長時間かかるといったケースもあるため、並列化や場合によってはセッションをキャンセルして進める必要があります。

# セッション（SELECTを実行しているものに限る）を切断するコマンド
SELECT pg_terminate_backend(pid),query,usename FROM pg_stat_activity WHERE query LIKE 'SELECT%' AND pid <> pg_backend_pid() AND usename <> 'rdsadmin'

注意点

実際に本番環境でアップグレード作業を行った際には、いくつか想定外の問題に直面し、残念ながら一度で完了させることはできませんでした。事前に十分な準備をしていたつもりでも、実際の環境では予期せぬ落とし穴があるものだと痛感しました。

実際につまづいたポイントや、どのように対応したかについては、第52回 PostgreSQL アンカンファレンスにて発表しています。詳細はスライドにまとめていますので、ご興味のある方はぜひご覧いただければと思います。

まとめ

今回、RDS for PostgreSQL / Aurora PostgreSQL のメジャーバージョンアップグレードを実施しました。過去のナレッジが存在しない状況から始めたことで、事前調査や環境検証に多くの時間を要し、大変でした。

特に、事前検証や環境差異を極力減らすといった、準備の大切さを痛感しました。準備を怠ると本番環境でのトラブルに繋がるため、慎重な確認と検証が重要だと感じました。また、弊社の今後のPostgreSQLアップグレードが簡単になるように、手順書の整備をしていきたいと思っています。