[option...]説明pg_upgrade(これまではpg_migratorと呼ばれていました)を使用して、メジャーバージョンへのアップグレード、例えば、8.4.7から現時点のメジャーリリースのPostgreSQL、に通常必要とされたデータのダンプ/リストアを行うことなく、PostgreSQLデータファイル内に格納されたデータをより最新のPostgreSQLメジャーバージョンに移行することができます。これは、例えば9.0.1から9.0.4などマイナーバージョンへのアップグレードでは必要ありません。PostgreSQLのメジャーリリースでは通常、システムテーブルのレイアウトをよく変更する、多くの機能が追加されます。内部データの格納書式はまれにしか変更されません。pg_upgradeはこの事実を使用して、システムテーブルを新しく作成し、古いユーザデータファイルを単に再利用することで、高速なアップグレードを実施します。将来のメジャーリリースでついに古いデータ書式を読み取ることができなくなるようにデータ格納書式を変更した場合、pg_upgradeではこうしたアップグレードを扱うことができません。(コミュニティはこうした状況を防ごうと考えています。)pg_upgradeは古いクラスタと新しいクラスタとの間で、例えばコンパイル時の設定に互換性があるかどうか、32ビットバイナリか64ビットバイナリかなど、バイナリ互換性があることを確実にするために最善を尽くします。任意の外部モジュールがバイナリ互換であることも重要ですが、これはpg_upgradeでは検査することができません。pg_upgradeは8.4.X以降から現時点のPostgreSQLのメジャーリリース(スナップショット版やαリリースを含む)へのアップグレードをサポートします。オプションpg_upgradeは以下のコマンドライン引数を受け付けます。bindir--old-bindir=bindir古いPostgreSQLの実行ファイル格納ディレクトリ。bindir--new-bindir=bindir新しいPostgreSQLの実行ファイル格納ディレクトリ。PGBINNEW環境変数-c--checkクラスタの検査のみを行い、データの変更を行いません。datadir--old-datadir=datadir古いクラスタのデータディレクトリ。datadir--new-datadir=datadir新しいクラスタのデータディレクトリ。PGDATANEW環境変数-j--jobs使用する同時実行プロセスまたはスレッド数。-k--link新しいクラスタにファイルをコピーするのではなく、ハードリンクを使用します。options古いpostgresコマンドに直接渡すオプションです。複数の起動オプションが追加されます。options新しいpostgresコマンドに直接渡すオプションです。複数の起動オプションが追加されます。port--old-port=port古いクラスタのポート番号。port--new-port=port新しいクラスタのポート番号。PGPORTNEW環境変数-r--retain正常に完了した場合であってもSQLファイルとログファイルを保持します。username--username=usernameクラスタのインストールユーザの名称。PGUSER環境変数-v--verbose冗長な内部ログを有効にします。-V--versionバージョン情報を表示し、終了します。-?--help使用方法を表示し、終了します。使用方法pg_upgradeを用いたアップグレードを行う手順を示します。古いクラスタの移動(省略可能)バージョンに関連したインストレーションディレクトリ(例えば/opt/PostgreSQL/9.1)を使用しているのであれば、古いクラスタを移動する必要はありません。グラフィカルインストーラはすべて、バージョンに関連したインストレーションディレクトリを使用します。インストレーションディレクトリがバージョンに関連していない(例えば/usr/local/pgsql)のであれば、新しいPostgreSQLのインストレーションに干渉しないように、現在のPostgreSQLインストレーションディレクトリを移動しなければなりません。一度現在のPostgreSQLサーバを停止させていれば、PostgreSQLのインストレーションの名前を変更しても安全です。古いディレクトリが/usr/local/pgsqlであれば、以下のようにディレクトリ名を変更します。古いクラスタと互換性を持つようなconfigureオプションを付けて新しいPostgreSQLソースを構築してください。pg_upgradeはアップグレードを始める前にすべての設定が互換性を持っていることを確認するためにpg_controldataを検査します。新しいPostgreSQLのバイナリのインストール新しいサーバのバイナリとサポートファイルをインストールしてください。pg_upgradeはデフォルトのインストレーションに含まれています。ソースからインストールする場合、独自の場所に新しいサーバをインストールしたければ、以下のようにprefixを使用してください。install新しいPostgreSQLクラスタを初期化initdbを使用して新しいクラスタを初期化してください。繰り返しますが、古いクラスタに合うように互換性があるinitdbのオプションを使用してください。組み込まれたインストーラの多くは、この手順を自動的に実施します。新しいクラスタを起動する必要はありません。独自の共有オブジェクトファイルをインストール例えば、pgcrypto.so、contribや何らかのその他のソースからインストールしたものなど、古いクラスタで使用していた独自の共有オブジェクトファイル(またはDLL)をすべて、新しいクラスタにインストールしてください。pgcryptoなどのスキーマ定義はインストールしないでください。これらは古いクラスタからアップグレードされるためです。ストップワード)も新しいクラスタにコピーしなければなりません。認証の調整pg_upgradeは古いサーバと新しいサーバに複数回接続します。パスワードファイル参照)を使用するようにした方が良いかもしれません。両サーバが停止していることを確実にしてください。Unixでは以下を使用します。postgresql-9.0ストリーミングレプリケーションおよびログシッピングのスタンバイサーバは、後のステップまで実行中のまま残すことができます。10の節で示した手順で)アップグレードする場合は、pg_controldataを実行して、古いスタンバイサーバが、古いプライマリ及びスタンバイのクラスタに同期していることを確認してください。location」(最終チェックポイント位置)の値が一致することを確認してください。(古いスタンバイサーバが、古いプライマリより先にシャットダウンされた場合は一致しないでしょう。)また、スタンバイサーバをアップグレードする場合は、新しいマスタークラスタ上のpostgresql.confファイル内でwal_levelの設定をreplicaに変更してください。古いサーバのものではなく、常に新しいサーバのpg_upgradeバイナリを実行してください。pg_upgradeは古いクラスタおよび新しいクラスタのデータと実行形式ファイルの格納ディレクトリ(bin)の指定を要求します。ユーザやポート番号の指定や、コピー(デフォルト)ではなくデータリンクを使用するかどうかを指定することができます。リンクモードを使用する場合、アップグレードは非常に高速になり(ファイルのコピーがありません)、ディスク容量が少なくなりますが、アップグレード後に新しいクラスタを一度でも実行してしまうと、古いクラスタにアクセスすることができなくなります。リンクモードはまた、古いクラスタと新しいクラスタのデータディレクトリが同じファイルシステムにあることが必要です。(テーブル空間およびpg_xlogは異なるファイルシステムに置くことができます。--helpを使用してください。--jobsオプションにより複数のCPUコアを使用して、並行してファイルのコピー・リンク、データベーススキーマのダンプと再ロードを行うことができます。この値の最大値として検討を始める際には、CPUコア数またはテーブル空間数を勧めます。このオプションはマルチプロセッサを持つマシンで実行している複数のデータベースサーバをアップグレードする時間を大きく減らします。Windowsユーザの場合、管理者アカウントでログオンしなければなりません。postgresユーザとしてシェルを起動し、適切なパスを設定してください。Files\PostgreSQL\9.0\bin;そして、以下の例のように、引用符でくくったディレクトリを付けてpg_upgradeを実行してください。Files/PostgreSQL/9.0/bin"起動後、pg_upgradeは2つのクラスタに互換性があるかどうか検証し、その後、アップグレードを行います。--checkを使用することができます。この場合は古いサーバは稼動中であっても構いません。--checkは、アップグレード後に手作業で行わなければならない調整作業があればその概要を示します。リンクモードを使用する予定であれば、リンクモード固有の検査を有効にするために--checkを付けて--linkを使用すべきです。pg_upgradeは現在のディレクトリに対する書き込み権限を必要とします。言うまでもありませんが、アップグレード中はクラスタにアクセスしてはいけません。意図しないクライアント接続を防ぐために、デフォルトではpg_upgradeは50432ポートでサーバを稼働します。古いクラスタと新しいクラスタが同時に稼動することはありませんので、両クラスタで同じポート番号を使用することができます。実行中の古いクラスタを検査する時には、新旧で異なるポート番号でなければなりません。16で示すように古いクラスタに戻さなければなりません。pg_upgradeを試すためには、pg_upgradeによるスキーマのリストアが成功するように古いクラスタを変更しなければなりません。問題がcontribモジュールであれば、そのモジュールがユーザデータを格納するために使用されていないことが前提ですが、古いクラスタからそのcontribモジュールをアンインストールし、アップグレードした後に新しいクラスタにそれをインストールする必要があるかもしれません。ログシッピングスタンバイサーバ)のスタンバイサーバがある場合、以下の手順に従ってそれらをアップグレードしてください。スタンバイサーバではpg_upgradeは使わず、代わりにrsyncを使います。どのサーバも起動しないでください。PostgreSQLの新しいバイナリをスタンバイサーバにインストールすべてのスタンバイサーバで新しいバイナリとサポートファイルがインストールされていることを確実にしてください。新しいスタンバイのデータディレクトリが存在しないか空であることを確実にしてください。initdbが実行されている場合は、スタンバイサーバのデータディレクトリを削除してください。カスタム共有オブジェクトファイルのインストール新しいマスタのクラスタにインストールしたのと同じカスタム共有オブジェクトファイルを新しいスタンバイにインストールしてください。スタンバイサーバの停止スタンバイサーバがまだ実行中なら、上記の手順に従って停止してください。設定ファイルの保存スタンバイの設定ファイルで保持する必要のあるもの、例えばpostgresql.confやrecovery.confを保存してください。これらは次のステップで上書きあるいは削除されるからです。古いデータベースクラスタおよび新しいデータベースクラスタのディレクトリの上位のディレクトリで、各スレーブに対して、以下を実行してください。remote_dirここでold_pgdataおよびnew_pgdataはカレントディレクトリからの相対パス、remote_dirはスタンバイサーバ上の古いクラスタと新しいクラスタのディレクトリの上位のディレクトリです。古いクラスタと新しいクラスタの相対パスは、マスターサーバとスタンバイサーバで一致しなければなりません。リモートディレクトリの指定、例えばstandbyhost:/opt/PostgreSQL/の詳細についてはrsyncのマニュアルを参照してください。pg_upgradeの--linkモードを使用すると、リモートサーバでユーザデータを転送する代わりにハードリンクを作成するので、rsyncが高速になります。残念ながら、rsyncは一時テーブルおよびログを取らないテーブルに関連付けられたファイルについて不要な複製をします。テーブル空間を使用している場合は、各テーブル空間のディレクトリについて、同様のrsyncコマンドを実行する必要があります。pg_xlogをデータディレクトリの外側に移動している場合は、そのディレクトリについてもrsyncを実行しなければなりません。ストリーミングレプリケーションおよびログシッピングのスタンバイサーバの設定ログシッピングのためにサーバを設定します。(スレーブはまだマスターと同期されているので、pg_start_backup()とpg_stop_backup()を実行したり、ファイルシステムのバックアップを取得したりする必要はありません。)pg_hba.confの復旧pg_hba.confを変更している場合は、元の認証設定に戻してください。新しいクラスタにおけるこの他の設定ファイル、例えばpostgresql.conf、も古いクラスタに合わせるように調整する必要があります。新しいサーバの起動ここで新しいサーバが安全に起動できます。それからrsyncしたすべてのスタンバイサーバを起動できます。移行後の処理アップグレード後の処理が必要な場合、pg_upgradeはその終了時に警告を発します。管理者として実行しなければならないスクリプトファイルを生成します。このスクリプトファイルは、アップグレード後の処理を必要とするデータベースそれぞれに接続します。各スクリプトは以下を使用して実行しなければなりません。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接尾辞を取り除きます。その後、古いクラスタを再起動することができます。注釈pg_upgradeは次のOIDを参照するreg*システムデータ型を含むデータベースのアップグレードをサポートしません。regproc、regprocedure、regoper、regoperator、regconfig、regdictionary。(regtypeはアップグレード可能です。インデックス再作成はすべてpg_upgradeにより報告されます。テーブルおよびインデックスを再構築するアップグレード後処理スクリプトは自動的に生成されます。すべてのクラスタのアップグレードにおいて同一のデータベーススキーマを持つクラスタが同じアップグレード後処理を必要とすることが分かるはずです。これはアップグレード後処理がデータ自体ではなくデータベーススキーマに基づいているためです。展開試験を行うのであれば、古いクラスタのスキーマのみをコピーしたものを作成し、ダミーデータを挿入してから、アップグレードを行ってください。/configuration-directory'のように、実際のデータディレクトリの場所をpg_upgradeに通知しなければならず、さらに設定用ディレクトリの場所をサーバに通知しなければなりません。デフォルト以外のUnixドメインソケットディレクトリを使用する、または新しいクラスタのデフォルトとは異なるデフォルトを使用する9.1より前の古いサーバを使用している場合、古いサーバのソケット位置を指し示すようにPGHOSTを設定してください。(これはWindowsでは関係ありません。)リンクモードを使用したいが、新しいクラスタを起動した時に古いクラスタを変更させたくない場合は、古いクラスタのコピーを取得してからリンクモードでアップグレードを行ってください。--checksumを再度実行して一貫性を保つために何らかの変更をコピーに反映させます。(rsyncはファイル更新時刻の粒度が1秒しかないので--checksumが必要です。低レベルAPIを使用したベースバックアップの作成で説明したpostmaster.pidなど、一部のファイルを除外したいと考えるかもしれません。スナップショットやコピーは同時、もしくはデータベースサーバが停止しているときに作らなければなりませんが、ファイルシステムがファイルシステムのスナップショットやコピーオンライトファイルコピーをサポートしているのなら、それを古いクラスタとテーブル空間のバックアップをするのに使うことができます。pg_xlogdump。