Zenn
BABYJOB テックブログPublicationへの投稿
🐘

Amazon Aurora PostgreSQL を v13 から v15 にアップグレードする

BABYJOB 開発部
2023/12/14に公開
AWS
PostgreSQL
Database
aurora
#
アップグレード
tech

全体の流れ

弊社が利用している Amazon Aurora PostgreSQL のバージョンを v13 から v15 （作業時最新のv15.2 ）にアップグレードした時のフローをまとめます。

  1. 作業フローの把握
    • アップグレード手順
    • リストア手順
  2. 事前検証
    • v13 → v14 へのアップグレードの検証
      • 非互換性の調査
      • アップグレード（同時に作業時間を計測する）
    • v14 → v15 へのアップグレードの検証
      • v13 → v14 へのアップグレード時との違い
  3. 本番環境のアップグレード

作業フローの把握

まずはおおよそのアップグレード方法の把握から始めました。
全体的な流れは公式ドキュメントの「Aurora PostgreSQL の PostgreSQL DB エンジンのアップグレード」を参考にしています。

アップグレード手順

  1. 異なるバージョン間で互換性を持たせるためのパラメータグループを用意
    • パラメータの増減やデフォルト値の変更を比較する
  2. DB の状態を整理
    • インスタンスにアクティブなトランザクションが存在しないことを確認する
    • インスタンスの論理的なレプリケーションスロットを削除する
  3. スナップショットを取得
  4. 特定の拡張機能を利用可能な最新バージョンにアップグレード
  5. インスタンスをアップグレード
  6. PostgreSQL の拡張機能をアップグレード
  7. 統計情報を更新

リストア手順

トラブルが発生した際に備えてリストアの手順も整備しておきます。

  1. 既存のクラスタ、インスタンスの設定内容を把握
  2. スナップショットを元にクラスタを復元
  3. 動作確認
  4. 不要になったインスタンスの削除

事前検証

事前検証には本番と同等の環境であるテスト環境を利用しました。

v13 → v14 へのアップグレードの検証

最終的には v15 へのアップデードですが、やはり v14 での変更の把握をすべきという観点でまずは v14 へアップグレードします。

非互換性の調査

追加された機能や、変更の把握をし影響の有無を確認します。

参考： https://www.postgresql.org/docs/14/release-14.html#id-1.11.6.13.4

設定すべきパラメーターの確認
  • タイムゾーンなど適宜必要なものを設定します
  • このとき、v14 で追加・変更されたものの把握をします
アプリケーションの動作確認
  • ローカル環境で、v13 の postgres イメージから起動した DB コンテナでアプリを動かして、DB を pg_dump
  • コンテナイメージを v14 に変更して起動、 pg_restore を実施
  • アプリ全体の動作確認を実施し、デグレがないことを確認

アップグレード（同時に作業時間を計測する）

ここまでに問題がないかなど判断できなかったものを検証しつつ、想定手順を踏んで本番作業に向けての作業時間の把握などを行います。

  1. v14 用のパラメータグループを作成する
    • 今回は、timezone のみ変更する → Asia/Tokyo
  2. アプリをメンテナンスモードに変更する
  3. トランザクションが残っていないか確認する
SELECT count(*) FROM pg_catalog.pg_prepared_xacts;
count
-------
    0
(1 row)

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');
    count
-------
    0
(1 row)
  1. 論理的なレプリケーションスロットを削除
SELECT * FROM pg_replication_slots;
slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size
-----------+--------+-----------+--------+----------+-----------+--------+------------+------+--------------+-------------+---------------------+------------+---------------
(0 rows)
  1. バックアップを実行
    • リストア手順でも実施しているので適宜実行
  2. アップグレードを実行する前に、特定の拡張機能を、利用可能な最新バージョンにアップグレード
    • 対象の特定の拡張機能
      • pgRouting
      • postgis_raster
      • postgis_tiger_geocoder
      • postgis_topology
      • address_standardizer
      • address_standardizer_data_us
    • 以下のSQLで確認する
      • 該当はありませんでした
      • あれば、ALTER EXTENSION PostgreSQL-extension UPDATE TO 'new-version'; でアップグレードします
SELECT * FROM pg_extension;
    oid  | extname | extowner | extnamespace | extrelocatable | extversion | extconfig | extcondition
-------+---------+----------+--------------+----------------+------------+-----------+--------------
    14346 | plpgsql |       10 |           11 | f              | 1.0        |           |
(1 row)
  1. インスタンスをアップグレード
    • マネジメントコンソール上で、DBエンジンバージョンを変更するバージョン、用意しておいたクラスタのパタメータグループを設定アップグレードを実行する
    • ステータスが「利用可能」になれば完了
  2. ログインして ANALYZE を実行する
    • 確認用に select * from pg_statistic; を実行することが可能ですが、結果が膨大になる可能性があり
    • 既存データの確認など
  3. メンテナンスモードを解除する
  4. 動作確認をする

途中で少し迷うことがありましたが、1時間半ほどで完了しました。

v14 → v15 へのアップグレードの検証

基本的には v14 での手順と同様です。冗長になってしまうので詳細は割愛して違う点のみここには記載します。

作業時間については、やはり1時間半ほどかかりました。

v13 → v14 へのアップグレード時との違い

公式ドキュメントに以下のような一文があり調査が必要でした。

Remove PUBLIC creation permission on the public schema.

調査の結果以下の通りでした。

  • 仕様の理解
    • publicスキーマに対するCREATE権限が付与されなくなる
    • 既存のデータベースクラスターのアップグレードやデータベースダンプの復元では、publicスキーマの既存の権限が維持される
  • 現状の確認方法
    • \dn+ public
      • Owner は違えど付与されている権限が以前のものとおなじであることを確認する
  • 影響の有無
    • 新しいデフォルトの権限設定と同じであり、特に変更する必要はない

本番アップグレード作業

実施した作業的には前述のテスト環境でやったことと違いがありませんのでここでも詳細は割愛しますが、事前にパラメータグループやもろもろのチェックリスト等を用意し万全な状態で臨みました。

結果として、検証時と同様に1時間半ほどで無事完了しました。

最後に

本番作業前にじっくり準備をしていたおかげで本番作業時には書くことがないような状態になってしまいましたが、これはあるべき姿なのではないかと思います。

本番作業ではメンバーと相談しペア作業を実施しました。作業の本質ではないところで少しトラブルもありましたがペア作業で同伴してくれたメンバーのおかげで助かりました。感謝です！

リモート勤務だったメンバーも勤務時間をずらしてくれてリモートで立ち会って（？）くれました。心強かったです。みなさんありがとうございました！！！

参考にさせてもらった記事・サイト

BABYJOB テックブログ
BABYJOB テックブログPublication

「すべての人が子育てを楽しいと思える社会」の実現を目指すスタートアップ BABY JOB のテックブログです。

Discussion