0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

IBM Cloud Databases for PostgreSQL インプレースでのアップグレード

0
Last updated at Posted at 2026-07-24

はじめに

IBM Cloud の Cloud Databasesを利用している方にとって、避けて通れない運用作業のひとつが DBMS のメジャーバージョンアップです。

これまでは IBM Cloud Databases の多くのデータベースでメジャーバージョンアップを行う場合、

  • バックアップから新規デプロイメントへリストアする
  • Read Replica を作成し、Promotion 時に新バージョンへアップグレードする

といった「新しいデプロイメントへ移行する」方式が中心でした。アップグレード後は接続先情報が変わるため、アプリケーション側の設定変更も必要でした

それらを解説くださっている記事もあります。

2025 年の年末より Cloud Databasesのうちいくつかのサービスでは In-Place Upgrade がサポートされました。これにより既存インスタンスを維持したままメジャーバージョンアップが可能になり、運用上の負荷が大きく軽減されています。

本稿では Cloud Databasesの一つである Databases for PostgreSQLを対象にインプレースでのアップグレードについて説明し、実施した結果をお示しします。

インプレースでのアップグレード

従来の方式でのチャレンジ

これまで PostgreSQL のメジャーバージョンアップを実施してきましたが、最大の課題は「新旧環境の切り替え」でした。

バックアップ・リストア方式では、

  • 新しい PostgreSQL バージョンでデプロイメント作成
  • バックアップからリストア
  • アプリケーション停止
  • 接続先変更
  • 動作確認
  • 本番切替

という流れになります。

また Read Replica を活用する方法でも、最終的には新しいデプロイメントへ切り替える必要があります。

そのため、

  • 接続文字列の変更
  • 構成情報 (Secrets や ConfigMap) の更新
  • セキュリティ設定 (Firewall や ACL) 設定の見直し
  • アプリケーション再デプロイ
  • 切り戻し手順の準備

など、データベース以外の領域にも対応が必要でした。技術的なアップグレードよりも、周辺システムの変更や運用調整に工数が掛かるケースが少なくありません。

インプレースで実施できるメリット

インプレースでのアップグレードには以下のような価値があると考えられます。

  • 接続情報を維持できる
    アップグレード後も接続パラメーターが保持されます。アプリケーション側で接続先変更が不要になるため、運用リスクを抑えられます。
  • より短時間でアップグレードできる
    新規デプロイメント作成やデータコピーを伴う方式よりもシンプルなため、アップグレード作業を短縮できます。
  • スケジュール管理が容易
    運用チームの都合に合わせて実施タイミングを計画できます。
  • 運用手順がシンプルになる
    接続先変更や資産棚卸しが不要となり、変更管理の範囲を大幅に削減できます。

特に企業システムでは、

  • アプリ
  • ETL
  • BI ツール
  • 監視製品
  • バッチ

など複数の接続元があるため、その恩恵は非常に大きいと感じられると思います。

インプレースの場合でも引き続き残る考慮事項

インプレースアップグレードは非常に便利ですが、すべての課題が解消されるわけではありません。

PostgreSQL の互換性確認は必要

メジャーバージョンアップである以上、

  • 廃止された機能の確認と対応
  • SQL の互換性
  • Extension の対応状況

などは事前確認が必要です。

一部 Extension は事前対応が必要

IBM Cloudの Docs では、以下の項目について事前確認が推奨されています。

pg_repack
old_snapshot
wal2json
anon
PostGIS
Logical Replication Slot

など。

例えば pg_repack はアップグレード前に削除し、アップグレード後に再作成する必要があります。

ダウンタイムはゼロではない

接続先変更が不要になったとしても、メジャーバージョンアップ処理中はサービス停止時間が発生します。

そのため、

メンテナンス時間の確保
アプリケーション停止計画
ロールバック方針

は引き続き必要になります。

アップグレードの手順

IBM Cloudにログインし、アップグレードしたいサービスインスタンスのページを開きます。「デプロイメントの詳細」の「バージョン」に「メジャーバージョンのアップグレード」という項目が表示されるのでクリックします。
image.png

画面右側「ガイダンス」が表示されるので、内容を確認し、チェックを入れて「次へ」をクリックします
image.png

次の画面ではアップグレードを待機する時間を指定して「アップグレード」をクリックします。
ジョブを開始する有効期限を設定しますが、これは長時間実行するようなジョブがアップグレードの開始を妨げる可能性があり、どれ位の時間待つのかというところを指定します。私の環境は長時間実行するようなジョブが無いので最小の5分のままとしました。
image.png

アップグレードが始めると「バージョン」の部分に進行中であることが表示されます。
image.png

同じくアップグレードが始めると「最近のタスク」の部分に進行状況が表示されます。
image.png

時間の経過とともに進行状況もすすみます。
image.png

ほとんどデータが入っていない私の環境では約15分くらいでバージョンアップが終わる「バージョン」は最新版の「18」に、「最近のタスク」は完了状態になりました。
image.png

バージョンが変わったことはコンソール上で確認できますが、必要なら実際にデータベースに接続して確認するようにします。

まとめ

今後ほかの Cloud Databases サービスでも対応が広がっていく予定と聞いているので、運用がさらに楽になりそうですね。

「メジャーバージョンアップかぁ…」と少し身構えていた方も、一度検証環境で試してみると意外とあっさり終わるようになるかもしれません。

参考文献

IBM Cloud Docs - Upgrading to a new major version

IBM Cloud Docs - Managing PostgreSQL Extensions

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?