17.6. PostgreSQLクラスタのアップグレード処理

本節ではPostgreSQLリリースからより新しいリリースにデータベースデータをアップグレードする方法を説明します。

PostgreSQLメジャーバージョンはバージョン番号の最初の2つの数字の組み合わせ、例えば8.4で表されます。 PostgreSQLのマイナーバージョンはバージョンを表す数字の3つの組み合わせで表されます。 例えば8.4.2は8.4リリースにおける2番目のマイナーリリースです。 マイナーリリースでは内部格納書式が変わることは決してありませんので、同じメジャーバージョンにおける前後のマイナーリリースとの間で常に互換性があります。 例えば8.4.2は8.4、8.4.1、8.4.6との間で互換性があります。 互換性があるバージョンとの間で更新するためには、サーバを停止させ、実行ファイルを置き換え、サーバを再起動させるだけです。 データディレクトリはまったく変更されません。 マイナーリリースのアップグレードは簡単です。

PostgreSQLメジャーリリースでは、内部データ格納書式は変更されがちです。 したがって、アップグレードは複雑になります。 新しいメジャーバージョンにデータを移行する伝統的な方法は、遅くなることがありますが、データベースをダンプしてリロードすることです。より速い方法については、pg_upgradeを参照してください。以下で説明するようにレプリケーションを使用する方法もあります。

新しいメジャーバージョンは通常、ユーザにも影響する非互換性がいくつか導入されます。 このためアプリケーションのプログラム変更が必要になる可能性があります。 ユーザに影響する変更はすべてリリースノート(付録E リリースノート)に列挙されています。 「移行」という名前の節に特に注意してください。 複数のメジャーバージョンをまたいでアップグレードする場合は、関連するバージョンそれぞれのリリースノートを確認してください。

用心深いユーザは、完全に切り替える前に新しいバージョンにおける自身のクライアントアプリケーションを試験したいと考えるでしょう。 このため古いバージョンと新しいバージョンを並行してインストールさせるというのは、よく良い考えとなります。 PostgreSQLメジャーアップグレードを試験する時、以下に示す変更があり得る分野を検討してください。

管理

各メジャーリリースにおいて、管理者が利用できるサーバの監視、制御機能はよく変更、向上されます。

SQL

通常、これには新しいSQLコマンド機能が含まれます。 リリースノートに特に記載がない限りその動作には変更はありません。

ライブラリAPI

繰り返しになりますが、リリースノートに記載がない場合のみですが、通常libpqのようなライブラリには新しい機能が追加されるだけです。

システムカタログ

システムカタログの変更は通常データベース管理用ツールにのみ影響します。

サーバC言語API

ここには、Cプログラム言語で作成されたバックエンド関数APIにおける変更が含まれます。 こうした変更は、サーバ内部深くにあるバックエンド関数を参照するコードに影響します。

17.6.1. pg_dumpallを介したデータのアップグレード

PostgreSQLのアップグレードの一つの方法は、PostgreSQLの1メジャーバージョンからデータをダンプし、別のバージョンにリロードすることです - これを行うには、pg_dumpallのような論理バックアップツールを使用しなければなりません。 ファイルシステムレベルのバックアップ方法は動作しません。 (あるデータディレクトリ間違ったバージョンのサーバを起動しようとして、大きな損害が起こることがないように、適所に互換性がないバージョンのPostgreSQLのデータディレクトリが使用されないようにするための検査があります。)

新しいバージョンのPostgreSQLpg_dumppg_dumpallを使用することを勧めます。 これらのプログラムで拡張された機能を利用する可能性があるためです。 現在のリリースのダンププログラムは7.0以降のバージョンのサーバからデータを読み取ることができます。

以下の手順では、既存のインストレーションが/usr/local/pgsql以下にあり、そのデータ領域が/usr/local/pgsql/dataにあることを前提としています。 使用しているパスに適切に置き換えてください。

  1. バックアップを作成する場合、使用しているデータベースが確実に更新されないようにしてください。 これはバックアップの整合性には影響しませんが、当然ながら変更されたデータがバックアップに含まれません。 必要に応じて、/usr/local/pgsql/data/pg_hba.conf(またはこれと等価なファイル)における権限を変更して、バックアップを行うユーザ以外からのアクセスを禁止してください。 アクセス制御に関する情報は19章クライアント認証を参照してください。

    データベースインストレーションをバックアップするためには以下を入力してください。

    pg_dumpall > outputfile

    バックアップを作成するために、現在起動中のバージョンのpg_dumpallコマンドを使用することができます。詳細は24.1.2. pg_dumpallの使用 を参照してください。 しかし最善の結果を得るためには、PostgreSQL 9.5.3のpg_dumpallコマンドを試してください。 このバージョンでは、過去のバージョンに対して、不具合の修正や改良が含まれているからです。 新しいバージョンをまだインストールしていませんので、この勧告は奇異に思えるかもしれませんが、古いバージョンと並行して新しいバージョンをインストールすることを計画しているのであれば、これに従うことを推奨します。 この場合、インストールを普通に完了させてからデータを移行することができます。 これは同時に停止時間を短縮します。

  2. 古いサーバを停止します。

    pg_ctl stop

    起動時にPostgreSQLを実行させるようにしているシステムではおそらく、同じことを達成する起動ファイルがあります。 例えばRed Hat Linuxシステムでは、以下が動作することが分かります。

    /etc/rc.d/init.d/postgresql stop

    サーバの起動と停止については17章サーバの準備と運用を参照してください。

  3. バックアップからリストアする場合、名前を変更、またはバージョン固有でない場合は古いインストレーションディレクトリを削除してください。 問題があった場合に戻さなければならない場合に備え、削除するよりディレクトリの名前を変更する方を勧めます。 このディレクトリが多くのディスク容量を占めている可能性があることに注意してください。 ディレクトリの名前を変更するためには、以下のようなコマンドを使用してください。

    mv /usr/local/pgsql /usr/local/pgsql.old

    (相対パスが維持されるように確実にディレクトリ単位で移動してください。)

  4. 概要を 15.4. インストール手順.で示すように、新しいバージョンのPostgreSQLをインストールしてください。

  5. 必要に応じて新しいデータベースクラスタを作成してください。 (アップグレードの場合はすでに存在している)特別なデータベースユーザアカウントでログインして、このコマンドを実行しなけれならないことに注意してください。

    /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data

  6. 以前のpg_hba.confpostgresql.confに加えた何らかの変更を戻してください。

  7. 繰り返しになりますが、特別なデータベースユーザアカウントを使用して、データベースサーバを起動してください。

    /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data

  8. 最後に、新しいpsqlを用いて、バックアップからデータをリストアしてください。

    /usr/local/pgsql/bin/psql -d postgres -f outputfile

新しいサーバを異なるディレクトリにインストールし、古いサーバと新しいサーバを別のポートで並行して実行させることで、停止時間を最小にすることができます。 この場合、データを移行するために以下のようなコマンドを使用することができます。

pg_dumpall -p 5432 | psql -d postgres -p 5433

17.6.2. pg_upgradeを使用したアップグレード方法

pg_upgradeモジュールにより、PostgreSQLのあるバージョンから次のバージョンにインストレーションをその場で移行することができます。 特に--linkオプションを使用することで、アップグレードは数分で行うことができます。 これは、pg_dumpallと同様の工程を必要とします。 例えば、initdbを実行し、サーバの起動/停止をおこないます。 pg_upgrade ドキュメントで必要な手順を説明します。

17.6.3. レプリケーション経由のアップグレード

更新対象のバージョンのPostgreSQLをスタンバイサーバとして作成して、Slonyなどの特定のレプリケーション方式を使用することもできます。 Slonyが異なるメジャーバージョンのPostgreSQLとの間でレプリケーションすることができるため、これが実現できます。 スタンバイは同じコンピュータで作成することも異なるコンピュータで作成することもできます。 (古いバージョンのPostgreSQLで実行している)マスタサーバと同期した後、マスタを切り替え、スタンバイをマスタにし、古いデータベースインスタンスを停止することができます。 このようなスイッチオーバの結果、数秒の停止時間でアップグレードされます。