無料スクリプト配布のPHP.TO   PHPの実用的なtips PHPマニュアル MySQLマニュアル Apacheマニュアル PostgreSQLマニュアル マニュアル検索    

17.6. PostgreSQL クラスタのアップグレード処理

本節では PostgreSQL リリースからより新しいリリースにデータベースデータをアップグレードする方法を説明します。

PostgreSQL メジャーバージョンはバージョン番号の最初の2つの数字の組み合わせ、例えば8.4で表されます。 PostgreSQL のマイナーバージョンはバージョンを表す数字の3つの組み合わせで表されます。 例えば8.4.2は8.4リリースにおける2番目のマイナーリリースです。 マイナーリリースでは内部格納書式が変わることは決してありませんので、同じメジャーバージョンにおける前後のマイナーリリースとの間で常に互換性があります。 例えば8.4.2は8.4、8.4.1、8.4.6との間で互換性があります。 互換性があるバージョンとの間で更新するためには、サーバを停止させ、実行ファイルを置き換え、サーバを再起動させるだけです。 データディレクトリはまったく変更されません。 マイナーリリースのアップグレードは簡単です。

PostgreSQL メジャー リリースでは、内部データ格納書式は変更されがちです。 したがって、アップグレードは複雑になります。 新しいメジャーバージョンにデータを移行する伝統的な方法はデータベースをダンプしてリロードすることです。 以下で説明しますが、他の方法もあります。

新しいメジャーバージョンは通常、ユーザにも影響する非互換性がいくつか導入されます。 このためアプリケーションのプログラム変更が必要になる可能性があります。 ユーザに影響する変更はすべてリリースノート( 付録E )に列挙されています。 「移行」という名前の節に特に注意してください。 複数のメジャーバージョンをまたいでアップグレードする場合は、関連するバージョンそれぞれのリリースノートを確認してください。

用心深いユーザは、完全に切り替える前に新しいバージョンにおける自身のクライアントアプリケーションを試験したいと考えるでしょう。 このため古いバージョンと新しいバージョンを並行してインストールさせるというのは、よく良い考えとなります。 PostgreSQL メジャーアップグレードを試験する時、以下に示す変更があり得る分野を検討してください。

管理

各メジャーリリースにおいて、管理者が利用できるサーバの監視、制御機能はよく変更、向上されます。

SQL

通常、これには新しいSQLコマンド機能が含まれます。 リリースノートに特に記載がない限りその動作には変更はありません。

ライブラリAPI

繰り返しになりますが、リリースノートに記載がない場合のみですが、通常 libpq のようなライブラリには新しい機能が追加されるだけです。

システムカタログ

システムカタログの変更は通常データベース管理用ツールにのみ影響します。

サーバC言語API

ここには、Cプログラム言語で作成されたバックエンド関数APIにおける変更が含まれます。 こうした変更は、サーバ内部深くにあるバックエンド関数を参照するコードに影響します。

17.6.1. pg_dump を介したデータのアップグレード

あるメジャーバージョンの PostgreSQL のデータをダンプし、他のバージョンにリロードするためには、 pg_dump を使用しなければなりません。 ファイルシステムレベルのバックアップ方法は動作しません。 (あるデータディレクトリ間違ったバージョンのサーバを起動しようとして、大きな損害が起こることがないように、適所に互換性がないバージョンの PostgreSQL のデータディレクトリが使用されないようにするための検査があります。)

より新しいバージョンの PostgreSQL pg_dump pg_dumpall を使用することを勧めます。 これらのプログラムになされた可能性がある改良点という利点があるからです。 現在のリリースのダンププログラムは7.0以降のバージョンのサーバからデータを読み取ることができます。

以下の手順では、既存のインストレーションが /usr/local/pgsql 以下にあり、そのデータ領域が /usr/local/pgsql/data にあることを前提としています。 使用しているパスに適切に置き換えてください。

  1. バックアップを作成する場合、使用しているデータベースが確実更新されないようにしてください。 これはバックアップの一貫性には影響しませんが、当然ながら変更されたデータがバックアップに含まれません。 必要に応じて、 /usr/local/pgsql/data/pg_hba.conf (またはこれと等価なファイル)における権限を変更して、バックアップを行うユーザ以外からのアクセスを禁止してください。 アクセス制御に関する情報は 第19章 を参照してください。

    データベースインストレーションをバックアップするためには以下を入力してください。

    
    pg_dumpall > 
    
    outputfile
    
    
    

    (外部キーとしてOIDを使用している場合など)OIDを保持する必要があれば、 pg_dumpall を実行する時に -o オプションを使用してください。

    バックアップを作成するために、現在起動中のバージョンの pg_dumpall コマンドを使用することができます。 しかし最善の結果を得るためには、 PostgreSQL 9.3.2の pg_dumpall コマンドを試してください。 このバージョンでは、過去のバージョンに対して、不具合の修正や改良が含まれているからです。 新しいバージョンをまだインストールしていませんので、この勧告は奇異に思えるかもしれませんが、古いバージョンと並行して新しいバージョンをインストールすることを計画しているのであれば、これに従うことを推奨します。 この場合、インストールを普通に完了させてからデータを移行することができます。 これは同時に停止時間を短縮します。

  2. 古いサーバを停止します。

    
    pg_ctl stop
    

    起動時に PostgreSQL を実行させるようにしているシステムではおそらく、同じことを達成する起動ファイルがあります。 例えば Red Hat Linux システムでは、以下が動作することが分かります。

    
    /etc/rc.d/init.d/postgresql stop
    

    サーバの起動と停止については 第17章 を参照してください。

  3. バックアップからリストアする場合、古いインストレーションディレクトリを変名または削除してください。 問題があった場合に戻さなければならない場合に備え、削除するよりディレクトリの名前を変更する方を勧めます。 このディレクトリが多くのディスク容量を占めている可能性があることに注意してください。 ディレクトリの名前を変更するためには、以下のようなコマンドを使用してください。

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

    (相対パスが維持されるように確実にディレクトリ単位で移動してください。)

  4. 概要を 項15.4 .で示すように、新しいバージョンの PostgreSQL をインストールしてください。

  5. 必要に応じて新しいデータベースクラスタを作成してください。 (アップグレードの場合はすでに存在している)特別なデータベースユーザアカウントでログインして、このコマンドを実行しなけれならないことに注意してください。

    
    /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
    

  6. 以前の pg_hba.conf postgresql.conf に加えた何らかの変更を戻してください。

  7. 繰り返しになりますが、特別なデータベースユーザアカウントを使用して、データベースサーバを起動してください。

    
    /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
    

  8. 最後に、 新しい psql を用いて、バックアップからデータをリストアしてください。

    
    /usr/local/pgsql/bin/psql -d postgres -f 
    
    outputfile
    
    
    

新しいサーバを異なるディレクトリにインストールし、古いサーバと新しいサーバを別のポートで並行して実行させることで、停止時間を最小にすることができます。 この場合、データを移行するために以下のようなコマンドを使用することができます。

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

17.6.2. ダンプを使用しないアップグレード方法

pg_upgrade モジュールにより、 PostgreSQL のあるバージョンから次のバージョンにインストレーションをその場で移行することができます。 アップグレードを瞬時に行うことができます。

更新対象のバージョンの PostgreSQL をスタンバイサーバとして作成して、 Slony などの特定のレプリケーション方式を使用することもできます。 Slonyが異なるメジャーバージョンの PostgreSQL との間でレプリケーションすることができるため、これが実現できます。 スタンバイは同じコンピュータで作成することも異なるコンピュータで作成することもできます。 (古いバージョンの PostgreSQL で実行している)マスタサーバと同期した後、マスタを切り替え、スタンバイをマスタにし、古いデータベースインスタンスを停止することができます。 このようなスイッチオーバの結果、数秒の停止時間でアップグレードされます。


powered by SEO.CUG.NET