PostgreSQLのメジャーバージョンアップを計画する|最新バージョンとサポート終了日の確認から切り戻し手段の用意まで

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)Linuxtipsデーターベース管理 > PostgreSQLのメジャーバージョンアップを計画する|最新バージョンとサポート終了日の確認から切り戻し手段の用意まで
「PostgreSQL 13のサポートが終わってしまった。でも本番DBのメジャーバージョンアップ、手順を間違えたらデータが消えそうで怖い」

Linuxサーバーを自前で運用していると、こういう状況に直面する瞬間があります。PostgreSQLはメジャーバージョンごとにデータディレクトリの内部形式が変わるため、yum updateapt upgradeを実行するだけでは移行できません。マイナーアップデートとはまったく異なる専用の手順が必要です。

この記事では、PostgreSQLのメジャーバージョンアップを安全に実施するための計画手順を解説します。最新バージョンとサポート終了日の確認方法、インプレースアップグレードツールpg_upgradeの実行手順、そして万一に備えた切り戻し手段の設計まで、実務で判断が必要なポイントをひとつずつカバーします。

実行環境: RHEL 9.4 / Rocky Linux 9.4(PGDG RPM)、Ubuntu 24.04 LTS(PGDG APT)で動作確認済み

この記事のポイント

・pg_upgrade --checkで事前に互換性問題を洗い出してから本番作業に入る
・pg_dumpallで論理バックアップを取得しておけば確実な切り戻しができる
・PostgreSQL 14は2026年11月でEOL。早めの移行計画が必要
・pg_upgradeはインプレース移行のため、pg_dump/restoreより大幅に速い


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

PostgreSQLのバージョン体系とサポート終了日を確認する

PostgreSQLのバージョン番号は「メジャー.マイナー」の形式(例: 14.12)で表されます。メジャー番号が変わるとデータディレクトリの形式も変わるため、単純なパッケージ更新では移行できません。一方、マイナー番号はバグ修正・セキュリティパッチのみで、データ形式の互換性は保たれます。

サポート期間はリリースから約5年間です。以下の表で現状を確認してください。

バージョン リリース年月 EOL(サポート終了) 現状
PostgreSQL 17 2024年10月 2029年11月 現在サポート中
PostgreSQL 16 2023年9月 2028年11月 現在サポート中
PostgreSQL 15 2022年10月 2027年11月 現在サポート中
PostgreSQL 14 2021年9月 2026年11月 ⚠️ 2026年終了予定
PostgreSQL 13 2020年9月 2025年11月 EOL済み(パッチなし)
PostgreSQL 12以前 EOL済み(パッチなし)

PostgreSQLは毎年1本のメジャーバージョンをリリースしており、最新状況は公式サイトの「PostgreSQL: Versioning Policy」ページで必ず確認してください。EOL後のバージョンはセキュリティパッチが提供されないため、本番稼働での継続利用はリスクがあります。

現行バージョンは以下のコマンドで確認できます。

# バイナリのバージョン確認 $ psql -V psql (PostgreSQL) 14.12 # 起動中クラスターのバージョン確認(psqlで接続後) $ psql -U postgres -c "SELECT version();" version ----------------------------------------------------------------------------------------------------------------- PostgreSQL 14.12 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 11.4.1 20230605 (Red Hat 11.4.1-2), 64-bit (1 row)

アップグレード前のチェックリスト

メジャーバージョンアップで失敗する多くのケースは、準備不足が原因です。作業前に以下の3点を必ず確認してください。

1. 現行バージョンとインストール方法を確認する

インプレースアップグレードを使う場合、現行と新バージョンのバイナリが同一サーバー上に共存します。インストール方法(PGDGリポジトリか、OS標準リポジトリか)を先に把握しておくと、作業中の混乱を防げます。

# RHEL/Rocky Linux: インストール済みPostgreSQLパッケージを確認 $ rpm -qa | grep postgresql postgresql14-14.12-1PGDG.rhel9.x86_64 postgresql14-server-14.12-1PGDG.rhel9.x86_64 postgresql14-libs-14.12-1PGDG.rhel9.x86_64 # データディレクトリの場所を確認 $ systemctl cat postgresql-14 | grep PGDATA Environment=PGDATA=/var/lib/pgsql/14/data/

データディレクトリのパスはOSやインストール方法によって異なります。RHEL/Rocky(PGDG)では/var/lib/pgsql/バージョン番号/data/、Ubuntu(PGDG APT)では/var/lib/postgresql/バージョン番号/main/が一般的です。

2. 拡張機能(Extension)の互換性を確認する

インストール済みの拡張機能が新バージョン向けのパッケージを提供していない場合、pg_upgradeは途中で失敗します。事前にインストール済み拡張機能の一覧を取得し、移行先バージョン向けのパッケージが存在するか確認しておきましょう。

# インストール済み拡張機能を一覧表示 $ psql -U postgres -c "SELECT name, default_version FROM pg_available_extensions WHERE installed_version IS NOT NULL;" name | default_version --------------------+----------------- pg_stat_statements | 1.10 plpgsql | 1.0 (2 rows)

特に注意が必要な拡張機能:
PostGIS: メジャーバージョンごとに対応パッケージが異なる。移行先バージョン向けのRPM/debが存在するか事前確認が必要
pgvector: バージョンによってソースコンパイルが必要な場合がある
pg_stat_statements: PostgreSQL標準の拡張で通常は問題なし

3. 切り戻し用の論理バックアップを取得する

pg_upgradeは新旧データディレクトリを使ったインプレース移行です。何らかの問題で新クラスターが正常に動作しない場合、旧クラスターを再起動すれば元に戻せます。しかし、それに加えてpg_dumpallによる論理バックアップを取っておくことを強く推奨します。旧クラスターのデータが完全に消えてしまった最悪の状況でも、論理バックアップがあれば復元できます。

# 全データベースの論理バックアップ(postgresユーザーで実行) $ pg_dumpall -U postgres > /backup/before_upgrade_$(date +%Y%m%d).sql # バックアップサイズと内容を確認 $ ls -lh /backup/before_upgrade_*.sql -rw-r--r-- 1 postgres postgres 1.2G Sep 05 10:23 /backup/before_upgrade_20260905.sql $ head -5 /backup/before_upgrade_20260905.sql -- -- PostgreSQL database cluster dump -- -- Dumped from database version 14.12 -- Dumped by pg_dumpall version 14.12

バックアップ取得後、サービスを停止してアップグレード作業に入ります。作業ウィンドウはデータ量によって異なりますが、pg_upgradeのインプレース移行はpg_dump/restoreの全件コピーより大幅に速く完了します(数百GBのDBでも数分~数十分程度が目安)。

pg_upgradeでインプレースアップグレードを実行する手順

pg_upgradeは新旧のバイナリとデータディレクトリを指定し、データを論理的に変換しながら新クラスターへ移行するツールです。全件コピーが不要なため、大容量DBでも比較的短時間で完了します。

1. 新バージョンのパッケージをインストールする

新旧の両バージョンを同一サーバーにインストールし、新クラスターの初期化(initdb)を行います。

# RHEL/Rocky Linux: PostgreSQL 17のパッケージをインストール $ dnf install -y postgresql17-server postgresql17 # 新クラスターを初期化(旧クラスターと文字コードを揃える) $ /usr/pgsql-17/bin/postgresql-17-setup initdb # Ubuntu 24.04 LTS: PostgreSQL 17をインストール # apt install -y postgresql-17 # Ubuntu はインストール時に自動でinitdbが実行される # 新クラスターのサービスは起動しない(pg_upgradeが直接操作するため)

新クラスターのinitdbで指定するロケール・文字コードは旧クラスターと一致させる必要があります。デフォルト設定のままinitdbした場合、RHEL/Rocky環境ではen_US.UTF-8になります。旧クラスターのロケールを事前に確認しておきましょう(psql -U postgres -c "SHOW lc_collate;"で確認できます)。

2. pg_upgrade --checkで事前検証する

実際の移行前に--checkオプションで互換性を検証します。この段階では実データを変更しないため、何度でも安全に実行できます。

# postgresユーザーで実行(pg_upgradeはOSユーザーがpostgresである必要がある) $ sudo -u postgres /usr/pgsql-17/bin/pg_upgrade --old-datadir=/var/lib/pgsql/14/data --new-datadir=/var/lib/pgsql/17/data --old-bindir=/usr/pgsql-14/bin --new-bindir=/usr/pgsql-17/bin --check Performing Consistency Checks ----------------------------- Checking cluster versions ok Checking database user is the install user ok Checking database connection settings ok Checking for prepared transactions ok Checking for system-defined composite types in user tables ok Checking for reg* data types in user tables ok Checking for contrib/isn with bigint-passing mismatch ok Checking for tables WITH OIDS ok Checking for presence of required libraries ok Checking for running databases ok Checking for postgresql.conf file ok Checking for pg_hba.conf file ok *Clusters are compatible*

「Clusters are compatible」と表示されれば事前検証をクリアしています。エラーが表示された場合はそのメッセージに従って対処してから再実行してください(後述のトラブルシュートを参照)。

3. PostgreSQLを停止してpg_upgradeを実行する

事前検証をクリアしたら、旧クラスターを停止して本番移行を実行します。--checkを除いたコマンドで実際の移行が始まります。

# 旧クラスターを停止 $ systemctl stop postgresql-14 # 旧クラスターが停止していることを確認 $ systemctl is-active postgresql-14 inactive # pg_upgradeを実行(--checkなし=本番移行) $ sudo -u postgres /usr/pgsql-17/bin/pg_upgrade --old-datadir=/var/lib/pgsql/14/data --new-datadir=/var/lib/pgsql/17/data --old-bindir=/usr/pgsql-14/bin --new-bindir=/usr/pgsql-17/bin Performing Consistency Checks ----------------------------- Checking cluster versions ok ... Performing Upgrade ------------------ Analyzing all rows in the new cluster ok Freezing all rows on the new cluster ok Deleting files from new pg_xact ok Copying old pg_xact to new server ok Setting oldest XID for new cluster ok Setting next multixact ID and offset for new cluster ok Resetting WAL archives ok Setting frozenxid and minmxid counters in new cluster ok Restoring global objects in the new cluster ok Restoring database schemas in the new cluster ok Copying user relation files ok Setting next OID for new cluster ok Sync data directory to disk ok Creating script to analyze new cluster ok Creating script to delete old cluster ok Upgrade Complete ---------------- Optimizer statistics are not transferred by pg_upgrade so, once you start the new server, consider running: ./analyze_new_cluster.sh Running this script will delete the old cluster's data files: ./delete_old_cluster.sh

「Upgrade Complete」が表示されればインプレース移行完了です。

4. 新バージョンでの動作確認と旧クラスターの削除

新クラスターを起動し、バージョンとデータを確認してから旧クラスターを削除します。

# 新クラスター(PostgreSQL 17)を起動 $ systemctl enable postgresql-17 $ systemctl start postgresql-17 # バージョンを確認 $ psql -U postgres -c "SELECT version();" version ----------------------------------------------------------------------------------------------------------------- PostgreSQL 17.0 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 11.4.1 20230605 (Red Hat 11.4.1-2), 64-bit (1 row) # データベース一覧を確認 $ psql -U postgres -l List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges -----------+----------+----------+-------------+-------------+----------------------- myapp_db | appuser | UTF8 | en_US.UTF-8 | en_US.UTF-8 | postgres | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres template1 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres (4 rows) # 統計情報を再収集(pg_upgradeは統計を移行しないため必須) $ sudo -u postgres ./analyze_new_cluster.sh # アプリケーションの動作確認を終えた後に旧クラスターを削除 $ sudo -u postgres ./delete_old_cluster.sh

analyze_new_cluster.shはpg_upgradeが生成するスクリプトで、新クラスターのすべてのテーブルに対してANALYZEを実行します。統計情報が空の状態ではクエリプランナーが最適な実行計画を選べないため、必ず実行してください。アプリケーションの動作確認が完了するまで旧クラスターのデータディレクトリを削除しないでおくと、万一の際に旧クラスターをそのまま再起動できます。

アップグレード後のトラブルシュートと切り戻し手順

pg_upgrade --checkでエラーが出る場合
よくあるエラーとその対処をまとめます。

「publicスキーマの権限」エラー(PostgreSQL 15以降へのアップグレード時): PostgreSQL 15以降ではpublicスキーマの権限モデルが変更されました。pg_upgradeは実行できますが、アップグレード後にアプリケーションからCREATE TABLEできない場合はGRANT CREATE ON SCHEMA public TO アプリユーザー;を実行してください
「There are incompatible pg_catalog columns」エラー: 旧バージョンで追加したカスタム関数がシステムカタログと競合しています。エラーに記載されたオブジェクトを削除してから再実行してください
拡張機能のライブラリが見つからないエラー: 移行先バージョン向けのパッケージ(例: postgresql17-pgvector)をインストールしてから--checkを再実行してください

新クラスターが起動しない場合の切り戻し手順
pg_upgradeは旧クラスターのデータディレクトリを変更しません(ファイルを移動するのではなくハードリンクで新クラスターに展開します)。新クラスターで問題が発生した場合、旧クラスターをそのまま再起動できます。

# 新クラスターを停止 $ systemctl stop postgresql-17 # 旧クラスターを起動(旧データディレクトリはそのまま残っている) $ systemctl start postgresql-14 $ systemctl is-active postgresql-14 active # バージョンを確認して旧クラスターに戻ったことを確認 $ psql -U postgres -c "SELECT version();"

pg_upgradeで--linkオプション(ハードリンクモード)を使った場合は、新クラスターを起動した時点で旧クラスターのデータが変更されるため、旧クラスターへの切り戻しはできなくなります。--linkオプションを使う場合は、事前のpg_dumpallバックアップがより重要です。

論理バックアップからの完全復元が必要な場合は、新規にinitdbしてからバックアップを流し込みます。

# 新規クラスターにpg_dumpallバックアップを復元(最終手段) $ psql -U postgres -f /backup/before_upgrade_20260905.sql postgres

本記事のまとめ

PostgreSQLのメジャーバージョンアップの計画手順をまとめます。

フェーズ やること コマンド例
バージョン確認 現行バージョンとEOL日を調べる psql -V
準備① 拡張機能の互換性を確認する SELECT name FROM pg_available_extensions WHERE installed_version IS NOT NULL
準備② 論理バックアップを取得する pg_dumpall -U postgres > backup.sql
インストール 新バージョンのパッケージをインストールしinitdbする dnf install postgresql17-server
事前検証 pg_upgrade --checkで互換性を確認する pg_upgrade --check --old-bindir=... --new-bindir=...
移行 旧クラスターを停止してpg_upgradeを実行する systemctl stop postgresql-14 && pg_upgrade ...
確認 新クラスターの起動・バージョン・データを確認する psql -U postgres -c "SELECT version();"
後処理 analyze_new_cluster.shを実行して旧クラスターを削除する ./analyze_new_cluster.sh && ./delete_old_cluster.sh

メジャーバージョンアップは計画と事前検証が8割です。pg_upgrade --checkでエラーを潰しておき、pg_dumpallで論理バックアップを確保してから本番作業に入れば、切り戻しを含めて安全に完了できます。PostgreSQL 14を運用中の方は2026年11月のEOLを見据えて、早めに移行計画を立てることをお勧めします。

PostgreSQLのメジャーバージョンアップを自信を持って実施するには、Linuxサーバー運用の「型」が基礎になります

pg_upgradeの実行やクラスター管理は、OSレベルのサービス管理・ファイルシステム・ユーザー権限の知識があると、トラブル時の判断が格段に速くなります。独学で断片的に覚えるより、現場で実際に使われる設計パターンを一度体系的に身につけることで、PostgreSQLも含めたミドルウェア全体の安定運用ができるようになります。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。

「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。