他のバージョンの文書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

22.4. リリース間の移行

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

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

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

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

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

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

実際には、完全に交換する前に、新しい設定でクライアントアプリケーションのテストを行うことをお勧めします。 これが、新旧のバージョンのインストールを並存させながら設定する、もう一つの理由です。

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

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

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

注意: "古いインストレーションをどこかに移動"した場合、もはや完全には使用できません。 実行プログラムの一部はインストールされた各種のプログラムやデータファイルの絶対パスを含んでいます。 これは多くの場合大した問題ではありませんが、2つのインストレーションをしばらく並行して使用する場合、構築時に異なったインストレーションディレクトリを割り当てなければなりません。 (この問題はPostgreSQL 8.0以降で修正されましたが、古めのインストレーションを移動する場合には注意しなければなりません。)