24.5. リリース間の移行

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

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

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

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

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

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

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

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

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

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

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