セキュリティ診断で「EOLバージョンを使用」と指摘された、RDSから延長サポートの課金通知が届いた。PostgreSQLのサポート終了が課題として浮上するのは、たいていこのタイミングです。EOL日を過ぎてもデータベースは止まりません。クエリもレプリケーションも動き続け、止まるのは修正パッチの提供だけです。だから放置されやすく、期限が迫ってから移行計画を立て始めることになります。
この記事は要約版です。pg_upgrade --linkの事前チェック4点と論理レプリケーションによる切り替え手順、EOL後の緊急度の判断基準の一覧は、ブログの完全版にまとめています: PostgreSQL EOL対応｜確認手順と移行の判断基準
結論は3択、ただし確認の順番を崩さない
コミュニティ版の各メジャーバージョンは、初回リリースから約5年でサポートが終わります。期間中は四半期ごとにマイナーリリースが出ますが、終了後は重大な脆弱性が見つかってもそのバージョン向けの修正版は出ません。
対応は3つに絞れます。メジャーバージョンがサポート内なら、最新マイナーへ追随するだけで済みます。16.2から16.10への更新のような作業で、ダウンタイムは再起動分だけです。移行が間に合わない場合は、RDS／AuroraのExtended Supportのような延長サポートで時間を買う手があり、追加課金が発生します。期限そのものに対処するなら、pg_upgradeか論理レプリケーションでメジャーアップグレードを実施します。
判断の順番は固定です。稼働バージョンを正確に取り、そのバージョンのEOL日を公式の「Versioning Policy」ページで確認し、マネージドかセルフホストかで選択肢を絞ります。逆から入ると、延長サポートを検討したら対象外だった、マイナー更新で足りたのに大掛かりな移行を計画していた、といった手戻りが起きます。
もう一点、どのレイヤのサポートが切れているのかを先に確定させてください。PostgreSQL本体のコミュニティ期限、OSディストリビューションのパッケージ提供、マネージドサービス側の標準サポート終了日の3つがあり、これらは一致しません。診断レポートはOSパッケージのバージョン文字列を見ていることが多く、本体はサポート内というケースもあります。
最初に取るのはサーバ側のバージョン
psql --versionはクライアント側の値です。サーバが返すバージョンを次のSQLで確認してください。
-- 人が読む用（ビルド情報込み）
SELECT version();
-- 比較・スクリプト判定用（例: 160010 = 16.10）
SHOW server_version_num;
-- データファイルの実体がどこか（複数クラスタ混在の切り分け）
SHOW data_directory;
SHOW config_file;
server_version_numが同じメジャーの最新マイナーより小さければ、EOL以前にマイナー更新の対象です。マネージドサービスやセルフホストで複数クラスタが同居している場合は、data_directoryまで見て対象を特定します。
完全版で扱っている内容
- 切り分け手順の詳細。
rpm -qaやpg_lsclustersでのバイナリ同居の確認、aws rds describe-db-engine-versionsでの移行先候補の列挙とdeprecated判定、保留メンテナンスアクションの確認まで。 - EOL後の緊急度の判断基準。インターネットからの到達可能性、PCI DSSなどサポート対象ソフトウェアを求める基準、自動アップグレード設定の有無を軸にした高・中の切り分け表。
-
pg_upgrade --linkの手順と、事前チェックで引っかかりやすい4点。チェックサム設定の不一致、論理レプリケーションスロットの残存、拡張の未インストール、削除された型の利用と、実行後に旧クラスタを起動してはいけない理由。 - 論理レプリケーションでの移行手順。パブリケーション作成から
pg_subscription_relでの初期コピー進捗確認、切り替えの7ステップ、シーケンスやDDLが複製されない制約の扱い。 - OSを跨いだ移行でのglibc照合順序の変更と
REINDEX、アップグレード後に性能が落ちたときの確認順、そしてserver_version_numの収集と四半期ごとのマイナー更新による再発防止の運用。