[11/15開催: PostgreSQL Conference Japan 2019 参加受付中] 
他のバージョンの文書 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

24.5. リリース間の移行

本節では、あるPostgreSQLリリースからより新しいリリースへデータベースのデータを移行する方法を説明します。 ソフトウェアのインストール手順、それ自体が本節の目的ではありませんので、詳細は第15章を参照してください。

一般的な規則として、PostgreSQL のメジャーリリース(最初のドットの後の番号の変更)間では内部データ保存形式は変更の対象となっています。 これは、同一メジャーリリースでのマイナーリリースの違い(2番目のドットの後の番号)には当てはまりません。 これらは常に互換性のある保存形式となっています。 例えばリリース8.1.1と8.2.3、そして8.3とでは互換性がありませんが、8.2.3と8.2.4には互換性があります。 互換性のあるバージョン間での更新を行う場合、ただ単に実効ファイルを置き換え、ディスク上のデータ領域を再使用するだけで問題ありません。 さもなくば、データをバックアップして、それを新しいサーバでリストアしなければなりません。 この作業はpg_dumpを使用して行う必要があります。 明らかに、ファイルシステムレベルのバックアップ方法ではうまく動作しません。 互換性がないバージョンのPostgreSQLのデータ領域を使用しないように適所で検査が行われますので、間違ったバージョンのサーバをデータディレクトリで起動しようとしても、大きな損害はありません。

改良が加えられているかもしれませんので、その利点を活かすために新しいバージョンのPostgreSQLpg_dumpプログラムやpg_dumpallプログラムを使用することを推奨します。 現在のリリースのダンプ用プログラムは7.0までのサーババージョンのデータを読み取ることができます。

サーバ停止の時間を最短とするには、新しいサーバを違ったディレクトリにインストールし、古いサーバと新しいサーバを異なったポートで並行に稼働させる方法があります。 その後、

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

このようなコマンドでデータを転送することができます。 または、必要に応じて中間ファイルを使用することができます。 その後、古い方のサーバを停止し、新しいサーバを古いサーバが稼働していたポートで立ち上げます。 この時pg_dumpallの起動を開始した後、古いデータベースが更新されていないことを確認してください。さもないとそれらのデータは消えてしまいます。 接続を拒否する方法は第19章を参照してください。

最新版のPostgreSQLでは、スレーブサーバを作成するのにSlonyのようなレプリケーション手法を使うことも可能です。スレーブは同じコンピュータ上でも、異なったコンピュータ上でも構いません。ひとたびそれが(より以前のバージョンが稼動しているPostgreSQL)マスターサーバと同期すると、マスターを切り替え、スレーブをマスターにして以前のデータベースインスタンスを停止することが可能です。このような切り替えはアップグレードのための停止時間をたった数秒で終わらせます。

2つのサーバを並行に稼働できなかったり稼働させたくない場合は、新しいバージョンのインストールを行う前にまずバックアップを行います。そして、サーバを停止してから古いバージョンをどこかに移動し、新しいバージョンをインストールします。その後、新しいサーバを立ち上げ、そしてデータをリストアしてください。以下に例を示します。

pg_dumpall > backup
pg_ctl stop
mv /usr/local/pgsql /usr/local/pgsql.old
cd ~/postgresql-8.4.4
gmake install
initdb -D /usr/local/pgsql/data
postgres -D /usr/local/pgsql/data
psql -f backup postgres

サーバを起動/停止させる方法や、その他の詳細は第17章を参照してください。 インストール手順ではこれらの手順を実行する戦略場所についての推奨事項が記載されています。

注意: "古いインストレーションをどこかに移動"した場合、もはや完全に使用可能ではないかも知れません。実行プログラムの一部はインストールされた各種のプログラムやデータファイルの絶対パスを含んでいます。 これは多くの場合大した問題ではありませんが、2つのインストレーションをしばらく並行して使用する場合、構築時に異なったインストレーションディレクトリを割り当てなければなりません (インストールされたファイル一式を含む全てのサブディレクトリを移動させる限りにおいて、この問題はPostgreSQL 8.0以降で修正されました。例えば、/usr/local/postgres/bin//usr/local/postgres.old/bin/に移動すれば、/usr/local/postgres/share//usr/local/postgres.old/share/に移動しなければなりません。8.0リリース以前でのこのようなインストレーションの移動は機能しません。)

実行上、完全に切り替える以前に新バージョンでクライアントアプリケーションをテストしたいことがあります。これが、旧バージョンと新バージョンの同時にインストールを設定するもう一つの理由です。PostgreSQLのメジャーアップグレードをテストするとき、以下に考えられる変更の範疇を検討してください。

管理

各メジャーリリースにおいて、サーバの監視と制御を行うために使用することができる管理者向けの機能はよく変更と改良が行われています。

SQL

通常、ここには新規SQL機能が含まれ、リリースノートに特別に記載されていない場合、動作に変更がありません。

API ライブラリ

通常、libpqのようなライブラリに、これもリリースノートに記載がないばあいに限り、新機能が追加されたことのみです。

システムカタログ

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

サーバの C-言語 API

これはCプログラム言語で書かれるバックエンド関数API変更を伴います。これらの変更はサーバの深層部にあるバックエンド関数を参照するコードに影響を与えます。