Auroraメジャーアップグレードの流れをまとめてみた
はじめに
こんにちは、SHIFTでインフラコンサルタントをしている大竹です。
Aurora PostgreSQLのバージョン10のサポート終了が迫る中、担当案件でAuroraをメジャーアップグレードするというテーマを実施しました。アップグレードまでの流れや留意点について、ざっくりとではありますが特定バージョンによらない形でまとめてみたいと思います。
バージョンごとのサポート状況
Auroraの公式ドキュメントによると、Aurora PostgreSQLのサポート終了予定日（正しくはドキュメントではアップグレード予定日と記載）は2022年12月現在、下の表のようになっています。終了を迎えた後、しばらくすると強制アップグレードとなります。
またPostgreSQL本体の各バージョンのリリースも、毎年の秋に行われるというのが近年の傾向のようです。ちなみに9.6まではドットの次の数字までの部分がメジャーバージョンでしたが、バージョン10からは一般的なセマンティックバージョニングとなっています。
※ 9.6までは「x.y」の部分がメジャーバージョン
長期サポートリリースの活用
RDSには、長期サポートリリース（LTS）なるものが用意されています。
通常のRDSは年に数回マイナーバージョンのサポート終了が発生するため、その度にマイナーアップグレードを考慮しなければなりません。基本的にはメンテナンスウインドウで実施されるのに任せておけば良いですが、システムによっては計画的に実施する方針の場合もあるため、年に数回のアップグレードはそれなりの負担になります。
長期サポートリリースを利用した場合は、そのマイナーバージョンはリリースされてから、少なくとも3年間利用することが可能と定義されています。もちろん重要なパッチがある場合は、その適用が発生する場合があります。ですがマイナーバージョンが数年間固定できるのは、アップグレードによる非互換や影響を気にする頻度や度合いが減るので、かなりの負荷軽減になります。
ただしすべてのメジャーバージョンに上記サポートリリースが定義されているわけではなく、2022年12月現在では11.9と12.9のみが長期サポートリリースとして定義されています。
注意点
ここで注意したいのが、メジャーアップグレード前のマイナーバージョンが新しすぎる場合、長期サポートリリースとして定義されているマイナーバージョンにアップグレードができないと言うことです。
例えば11.16からは12.11以上にしかアップグレードできないため、長期サポートリリースである11.9や12.9にすることはできません。この場合、インプレースアップグレードをするのではなく、長期サポートリリースのRDSを新規作成して、ダンプしたデータを取り込むなどの対応が必要になるでしょう。
なお「+」とあるものは、それ以上のマイナーバージョンに直接または段階的にアップグレードすることができることを示します。
アップグレード実施の流れ
それでは次に、実際のアップグレードの流れについて紹介していきます。
カスタムパラメータグループの作成
事前に実施しておくのがおすすめの作業があります。アップグレードの際に新しいカスタムパラメータグループを指定するため、旧バージョンでカスタムパラメータグループを利用していた場合は、あらかじめ新しいバージョン用のカスタムパラメータグループを作成しておきます。 もちろん、アップグレード後にあらためてカスタムパラメータグループを作成し、変更画面で指定しても大丈夫です。
イベントサブスクリプションをオフ
次に、イベントサブスクリプションを定義している場合は、アップグレード中にアラートが発生する可能性があるため、これを無効にしておきます。
アップグレード
以上の事前準備ができたら、実際に変更画面でアップグレードを実施します。この時、事前に作成しておいたカスタムパラメータグループを指定します。 アップグレードが開始すると、まずアップグレード前の自動スナップショットを作成してくれます。これでもしアップグレードが失敗したり、アップグレード後に重大な問題が発生したとしても、アップグレード前の状態に復元することができます。
しばらく待つとアップグレードが完了します。ここでの注意点として、カスタムパラメータグループを指定した場合は、インスタンスを再起動する静的パラメータが反映されません。カスタムパラメタグループを利用していない場合は問題ありませんが、利用している場合は、コンソールからライターインスタンスの再起動を実行しておきましょう。
拡張機能のバージョンアップ
次に、拡張機能を利用していた場合は、拡張機能をバージョンアップしましょう。何の拡張機能を利用しているかは、データベースごとに以下のコマンドで確認できます。
SELECT * FROM pg_extension;調査の段階で、利用している拡張機能についてアップグレード後に利用できるバージョンがあることを、以下のドキュメントで確認しておきます。
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/PostgreSQLReleaseNotes/postgresql-extensions.html
拡張機能をバージョンアップするコマンドは以下のようになります。
ALTER EXTENSION 拡張機能 UPDATE TO 'バージョン'監査機能としてpgauditなどはよく使われると思いますが、これのバージョンアップでは利用中のバージョンからアップグレードできるパスがないというエラーが出てしまいました。対処として一度削除して再インストールすることにしました。その際のコマンドは以下のようになります。
ALTER EXTENSION pgaudit UPDATE TO '1.7';
# これがだめだったので、下記で実施
DROP EXTENSION pgaudit;
CREATE EXTENSION pgaudit;統計情報の更新
また、バージョン10 以前からアップグレードする場合は、統計情報を更新する必要があるようです。データベースごとに以下のコマンドを実行して統計情報を更新しておきましょう。
ANALYZE VERBOSE;最後に、イベントサブスクリプションを無効にしていた場合は、これを有効に戻して作業は完了です。
おわりに
利用していたバージョンによっては、reg* データ型の廃止や、インデックスの更新などの影響を受ける場合があります。主だったものは下記のAWSドキュメントにまとめられているので、まずは導入ページを一読してみましょう。
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.html
上記で挙げられている以外にも、PostgreSQL自体の非互換は大小様々あります。確認の上、検証環境でのリグレッションテストはしっかり行いましょう。
《そのほかの記事》
執筆者プロフィール：大竹 一毅
国内大手システムインテグレーターにて技術支援部門に所属し、アプリケーション領域やクラウドインフラ領域のアーキテクトとして従事した後、SHIFTにジョイン。主にコンテナ技術を活用する案件を扱う。
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/