F.32. pg_upgrade

古いクラスタの移動（省略可能）

バージョンに関連したインストーレーションディレクトリ(例えば/opt/PostgreSQL/8.4)を使用しているのであれば、古いクラスタを移動する必要はありません。 この1クリックで済むインストーラはすべて、バージョンに関連したインストレーションディレクトリを使用します。

インストーレーションディレクトリがバージョンに関連していない（例えば/usr/local/pgsql）のであれば、新しいPostgreSQLのインストレーションに干渉しないように、現在のPostgreSQLインストレーションディレクトリを移動しなければなりません。 一度現在のPostgreSQLサーバを停止させていれば、PostgreSQLのインストレーションの名前を変更しても安全です。 古いディレクトリが/usr/local/pgsqlであれば、以下のようにディレクトリ名を変更します。

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

ソースからのインストールの場合の新しいバージョンの構築

古いクラスタと互換性を持つようなconfigureオプションを付けて新しいPostgreSQLソースを構築してください。 pg_upgradeは更新を始める前にすべての設定が互換性を持っていることを確認するためにpg_controldataを検査します。

新しいPostgreSQLのバイナリのインストール

新しいサーバのバイナリとサポートファイルをインストールしてください。 古いクラスタと新しいクラスタが同時に稼動することはありませんので、両クラスタで同じポート番号(通常5432)を使用することができます。

ソースからインストールする場合、独自の場所に新しいサーバをインストールしたければ、以下のようにprefixを使用してください。

gmake prefix=/usr/local/pgsql.new install

pg_upgradeおよびpg_upgrade_supportのインストール

新しいPostgreSQLクラスタにpg_upgradeおよびpg_upgrade_supportをインストールしてください。

新しいPostgreSQLクラスタを初期化

initdbを使用して新しいクラスタを初期化してください。 繰り返しますが、古いクラスタに合うように互換性があるinitdbのオプションを使用してください。 あらかじめ組み込まれたインストーラの多くは、この手順を自動的に実施します。 新しいクラスタを起動する必要はありません。

独自の共有オブジェクトファイル(またはDLL)をインストール

例えば、pgcrypto.so、contribや何らかのその他のソースからインストールしたものなど、古いクラスタで使用していた独自の共有オブジェクトファイル(またはDLL)をすべて、新しいクラスタにインストールしてください。 例えばpgcrypto.sqlなどのスキーマ定義はインストールしないでください。 これらは古いクラスタから移行されるためです。

認証の調整

pg_upgradeは古いサーバと新しいサーバに複数回接続します。 このため、パスワードの問い合わせが繰り替えされることを防ぐために、pg_hba.conf内でtrust認証に設定、あるいは、md5を使用しているのであれば~/.pgpassファイル(項31.14参照)の使用するようにした方が良いかもしれません。

両サーバの停止

両サーバが停止していることを確実にしてください。 例えばUnixでは以下を使用します。

pg_ctl -D /opt/PostgreSQL/8.4 stop
pg_ctl -D /opt/PostgreSQL/9.0 stop

Windowsでは以下

NET STOP postgresql-8.4
NET STOP postgresql-9.0

または以下をを適切なサービス名で使用します。

NET STOP pgsql-8.3  (PostgreSQL 8.3以前では異なるサービス名が使用されていました。)

pg_upgradeの実行

古いサーバのものではなく、常に新しいサーバのpg_upgradeバイナリを実行してください。 pg_upgradeは古いクラスタおよび新しいクラスタのデータと実行形式ファイルの格納ディレクトリ（bin）の指定を要求します。 また、別のユーザやポート番号の指定や、コピー(デフォルト)ではなくデータリンクを使用するかどうかを指定することができます。 リンクを使用する場合、移行は非常に高速になります(データのコピーを伴いません)が、更新後に新しいクラスタを一度でも実行してしまうと、古いクラスタにアクセスすることができなくなります。 すべてのオプションリストを参照するためにはpg_upgrade --helpを使用してください。

Windowsユーザの場合、管理者アカウントでログオンしなければなりません。 また、postgresユーザとしてシェルを起動し、適切なパスを設定してください。

RUNAS /USER:postgres "CMD.EXE"
SET PATH=%PATH%;C:\Program Files\PostgreSQL\9.0\bin;

そして、以下の例のように、引用符でくくったディレクトリを付けてpg_upgradeを実行してください。

pg_upgrade.exe
        --old-datadir "C:/Program Files/PostgreSQL/8.4/data"
        --new-datadir "C:/Program Files/PostgreSQL/9.0/data"
        --old-bindir "C:/Program Files/PostgreSQL/8.4/bin"
        --new-bindir "C:/Program Files/PostgreSQL/9.0/bin"

起動後、pg_upgradeは2つのクラスタに互換性があるかどうか検証し、その後、移行を行います。 検査のみを行うpg_upgrade --checkを使用することができます。 この場合は古いサーバは稼動中であっても構いません。 またpg_upgrade --checkは、移行後に手作業で行わなければならない調整作業があればその概要を示します。 pg_upgradeは現在のディレクトリに対する書き込み権限を必要とします。

言うまでもありませんが、移行中はクラスタにアクセスしてはいけません。

データベーススキーマのリストア中にエラーが発生した場合、pg_upgradeは終了しますので、後述のステップ14で示すように古いクラスタに戻さなければなりません。 再びpg_upgradeを試すためには、pg_upgradeによるスキーマのリストアが成功するように古いクラスタを変更しなければなりません。 問題がcontribモジュールであれば、そのモジュールがユーザデータを格納するために使用されていないことが前提ですが、古いクラスタからそのcontribモジュールをアンインストールし、移行した後に新しいクラスタにそれをインストールする必要があるかもしれません。

pg_hba.confの復旧

pg_hba.confをtrustを使用するように変更している場合は、元の認証設定に戻してください。

移行後の処理

移行後の処理が必要な場合、pg_upgradeはその終了時に警告を発します。 また、管理者として実行しなければならないスクリプトファイルを生成します。 このスクリプトファイルは、移行後の処理を必要とするデータベースそれぞれに接続します。 各スクリプトは以下を使用して実行しなければなりません。

psql --username postgres --file script.sql postgres

スクリプトは任意の順番で実行することができ、また、実行が終わったら削除することができます。

統計情報

オプティマイザの統計情報はpg_upgradeにより転送されませんので、移行後に統計情報を再生成するコマンドを実行するように指示されます。

古いクラスタの削除

更新処理が満足いくものであれば、pg_upgradeの終了時に示されたスクリプトを使用して、古いクラスタのデータディレクトリを削除することができます。 （bin、shareなど）古いインストレーションディレクトリは削除することもできます。

古いクラスタへの復旧

pg_upgradeを実行した後に古いクラスタに戻したい場合、いくつかの選択肢があります。

• --checkを付けたpg_upgradeを実行した場合、古いクラスタには変更はまったくなされていませんので、いつでも再使用することができます。

• --linkを付けたpg_upgradeを実行した場合、データファイルは古いクラスタと新しいクラスタとで共有されます。 もし新しいクラスタを起動していた場合、新しいサーバはこの共有されたファイルに書き出しを行いますので、古いクラスタで使用することは危険です。

• --linkを付けずにpg_upgradeを実行した場合、あるいは、新しいサーバを起動していない場合、$PGDATA/global/pg_controlとおそらくテーブル空間ディレクトリに.old接尾辞が追加される点を除き、古いクラスタは変更されません。 古いクラスタを再度使用するためには、$PGDATA/global/pg_controlから.oldを取り除きます。 もし8.4以前に移行する場合は、移行処理で生成されたテーブル空間ディレクトリを削除し、テーブル空間ディレクトリ名から.old接尾辞を取り除きます。 その後、古いクラスタを再起動することができます。