| PostgreSQL 9.0.4文書 | ||||
|---|---|---|---|---|
| 前のページ | 巻戻し | 第 24章バックアップとリストア | 早送り | 次のページ |
本節では、あるPostgreSQLリリースからより新しいリリースへデータベースのデータを移行する方法を説明します。 ソフトウェアのインストール手順、それ自体が本節の目的ではありませんので、詳細は第15章を参照してください。
PostgreSQLのメジャーバージョンは、例えば8.4のようにバージョン番号の最初の二つの数字の組で表されます。 PostgreSQLのマイナーバージョンは、バージョン番号の3番目の数字の組で表されます。例えば8.4.2は8.4の2番目のマイナーリリースです。 マイナーリリースでは内部データ保存形式は決して変更されず、同じメジャーバージョン番号の以前と以降のマイナーリリースと常に互換性があります。例えば8.4.2は8.4、8.4.1、8.4.6と互換性があります。 互換性のあるバージョン間での更新は、サーバが停止している間に実行ファイルを置き換えサーバを再起動するだけです。 データディレクトリはそのままです。マイナーアップグレードはそのように簡単です。
PostgreSQLのメジャーリリースでは、内部データ保存形式は変更されることがあります。そのため、アップグレードは複雑になります。 新しいメジャーバージョンへデータを移行する伝統的な方法はダンプしてリロードすることです。 他に、以下に記すように、それほどテストされていませんが実行可能な方法があります。
新しいメジャーバージョンは概してユーザから見える非互換性を導入します。そのためアプリケーションプログラムの変更が要求されます。 注意深いユーザは、完全に切り替える前に自分のクライアントアプリケーションを新しいバージョン上でテストしたいでしょう。そのため、旧バージョンと新バージョンのインストールを同時に設定するのは良い考えであることが多いです。 PostgreSQLのメジャーアップグレードをテストするとき、以下に考えられる変更の範疇を検討してください。
各メジャーリリースにおいて、サーバの監視と制御を行うために使用することができる管理者向けの機能はよく変更と改良が行われています。
通常、ここには新規SQL機能が含まれ、リリースノートに特別に記載されていない場合、動作に変更がありません。
通常、libpqのようなライブラリに、これもリリースノートに記載がないばあいに限り、新機能が追加されただけです。
システムカタログの変更は、通常データベース管理ツールのみに影響を与えます。
これはCプログラム言語で書かれるバックエンド関数API変更を伴います。これらの変更はサーバの深層部にあるバックエンド関数を参照するコードに影響を与えます。
PostgreSQLのあるメジャーバージョンからデータをダンプして、別のものにデータをリロードする場合には、pg_dumpを使用しなければなりません。 ファイルシステムレベルのバックアップ方法ではうまく動作しません。 （互換性がないバージョンのPostgreSQLのデータ領域を使用しないように適所で検査が行われますので、間違ったバージョンのサーバをデータディレクトリで起動しようとしても、大きな損害はありません。）
改良が加えられているかもしれませんので、その利点を活かすために新しいバージョンのPostgreSQLのpg_dumpプログラムやpg_dumpallプログラムを使用することを推奨します。 現在のリリースのダンプ用プログラムは7.0までのサーババージョンのデータを読み取ることができます。
サーバ停止の時間を最短とするには、新しいサーバを違ったディレクトリにインストールし、古いサーバと新しいサーバを異なったポートで並行に稼働させる方法があります。 その後、
pg_dumpall -p 5432 | psql -d postgres -p 6543
このようなコマンドでデータを転送することができます。 または、必要に応じて中間ファイルを使用することができます。 その後、古い方のサーバを停止し、新しいサーバを古いサーバが稼働していたポートで立ち上げます。 この時pg_dumpallの起動を開始した後、古いデータベースが更新されていないことを確認してください。さもないとそれらのデータは消えてしまいます。 接続を拒否する方法は第19章を参照してください。
2つのサーバを並行に稼働できなかったり稼働させたくない場合は、新しいバージョンのインストールを行う前にまずバックアップを行います。そして、古いサーバを停止してから古いバージョンをどこかに移動し、新しいバージョンをインストールします。その後、新しいサーバを立ち上げ、そしてデータをリストアしてください。以下に例を示します。
pg_dumpall > backup pg_ctl stop mv /usr/local/pgsql /usr/local/pgsql.old # テーブル空間のディレクトリの名前も変更すること cd ~/postgresql-9.0.4 gmake install initdb -D /usr/local/pgsql/data postgres -D /usr/local/pgsql/data psql -f backup postgres
サーバを起動/停止させる方法や、その他の詳細は第17章を参照してください。 インストール手順ではこれらの手順を実行する戦略場所についての推奨事項が記載されています。
注意: "古いインストレーションをどこかに移動"した場合、もはや完全に使用可能ではないかも知れません。実行プログラムの一部はインストールされた各種のプログラムやデータファイルの絶対パスを含んでいます。 これは多くの場合大した問題ではありませんが、２つのインストレーションをしばらく並行して使用する場合、構築時に異なったインストレーションディレクトリを割り当てなければなりません （インストールされたファイル一式を含む全てのサブディレクトリを移動させる限りにおいて、この問題はPostgreSQLバージョン8.0以降で修正されました。例えば、/usr/local/postgres/bin/が/usr/local/postgres.old/bin/に移動すれば、/usr/local/postgres/share/は/usr/local/postgres.old/share/に移動しなければなりません。8.0リリース以前でのこのようなインストレーションの移動は機能しません。）
contribプログラムpg_upgradeを使えばPostgreSQLのあるメジャーバージョンから次のものにインストールをその場で移行することができます。 この方法では古いバージョンと新しいものとを同時に動作させる機会は与えられないことは心に留めておいて下さい。 また、pg_upgradeはpg_dumpほど実運用でテストされていませんので、何か上手くいかなかった場合に備えて最新のバックアップを取っておくことを強く勧めます。
Slonyのようなレプリケーション手法を使って、PostgreSQLのアップデートされたバージョンでスタンバイサーバを作ることもことも可能です。 スタンバイは同じコンピュータ上にあっても構いませんし、異なるコンピュータ上にあっても構いません。 （PostgreSQLの古いバージョンが動作している）マスターサーバと一度同期すれば、マスターを切り替えてスタンバイをマスターにし、古いデータベースを停止できます。 そのような切り替えであれば、アップグレードのための停止時間はほんの数秒です。