• BPnet
  • ビジネス
  • IT
  • テクノロジー
  • 医療
  • 建設・不動産
  • TRENDY
  • WOMAN
  • ショッピング
  • 転職
  • ナショジオ
  • 日経電子版
  • PR

  • PR

  • PR

  • PR

  • PR

オープンソース

[PostgreSQLウォッチ]第10回 基幹業務向けに大幅拡張されたPostgreSQL 8.0,ベータテスト開始

高橋信頼 2004/08/23 ITpro

 昨年11月にPostgreSQL 7.4がリリースされてから9カ月,8月10日,ついに次期バージョン8.0のベータテストが開始された。バージョン番号の1ケタ目の数字が上がるのは2000年にリリースされた7.0以来のことであり,今回のバージョンにかける開発者の意気込みがうかがわれる。

大幅に機能を拡張した8.0

 実際8.0では今までのリリースでは見られなかったような大幅な機能拡張が行われている。以下,主要なものを列挙した。

  • ポイント・イン・タイム・リカバリ(Point In Time Recovery)

     データベース本体がディスク・クラッシュなどで失われても(メディア障害),バックアップとトランザクション・ログから最新の状態に復元することができる。バックアップを取得した時点までしか戻れなかった従来のPostgreSQLに比べると大幅な進歩であり,データベースの信頼性という観点から見て商用DBに肩を並べることができるようになったと言える。

  • テーブル・スペース(Table Spaces)

     テーブルやインデックスを別々のデータベース用の領域(テーブル・スペース)に配置し,より細かく領域管理するための機能である。これによって複数のディスク・ドライブを使って性能を向上させることが可能になるなどのメリットが生まれる。

     また,ディスク領域は不足したときにディスクを追加し,特定のテーブルやインデックスをそこに移動するといった使い方もできる。

  • セーブ・ポイント(Save Point)

     SQL標準のセーブポイントが実装された。セーブ・ポイントを使うとトランザクションのすべてではなく,一部だけをロールバックでき,より細かなトランザクション管理ができるようになる。

  • Win32対応

     Cygwinなどのエミュレーションを使うことなくWindowsプラットフォームでPostgreSQLがそのまま動くようになった。今のところ,Windows NT,Windows 2000,Windows XPなどに対応している(Windows 95,98,MEには対応していない)。

     なお,コンパイル済のバイナリはhttp://www.hagander.net/pgsql/win32snap/で提供されている。

  • バックグラウンド・ライター・プロセス(Background Writer Process)

     ディスクI/Oを管理するバックグラウンド・ライター・プロセスが追加され,より安定した性能を得ることができるようになった。

     本稿ではこのうちポイント・イン・タイム・リカバリ,テーブル・スペース,セーブ・ポイントの機能面について説明する。

    ポイント・イン・タイム・リカバリ

    図1●トランザクション・ログによるクラッシュ・リカバリ
     PostgreSQLでは,従来以下のような方法でクラッシュ・リカバリを実現していた(図1[拡大表示])。

    (1). 更新が発生した際にテーブルやインデックスなどのデータベース本体を更新するだけでなく,更新記録をトランザクション・ログに格納する。この際,トランザクション・ログだけは同期書込を行い,電源断などでもデータが失われないようにする。

    (2). 定期的に「チェックポイント」処理を実行し,古いトランザクション・ログを削除。また,テーブルやインデックスなどの更新されたブロックを同期書き込みする。

    (3). 電源断などの後では,PostgreSQL起動時に自動リカバリを行う。前回チェックポイント以降トランザクション・ログに記録されたトランザクションを再実行する。テーブルやインデックスは同期書き込みをしていないので内容が失われている可能性があるが,トランザクション再実行によって復旧されるので問題ない。

    図2●チェックポイントとメディア障害
     問題は(2)である。チェックポイント時かそれ以前に同期書込したテーブルやインデックスがディスク・クラッシュで失われると,対応するトランザクション・ログがないために(3)でもリカバリできない(図2[拡大表示])。これが従来PostgreSQLがメディア障害に対応できなかった理由である。メディア障害に対処する唯一の方法はバックアップから復元することだが,この方法ではバックアップ取得時点までしかデータ回復ができず,最新のトランザクションは失われてしまうことになる。

     ポイント・イン・タイム・リカバリでは,(2)のときにトランザクション・ログを捨てるのではなく,「アーカイブ・ログ」として保存する。バックアップとアーカイブ・ログを併用することにより,メディア障害が発生しても最新の状態(最後にコミットされたトランザクション)まで復元できる。

     さらに,最新状態ではなく,日付やトランザクションIDを指定して特定の時点までリカバリすることも可能である。これによって,重大なオペレーション・ミスでデータを失ってしまったような場合にも,その直前の状態までデータベースを戻し,データを回復することができる。これが「Point In Time Recovery」と呼ばれる所以である。

    ここから先はITpro会員(無料)の登録が必要です。

  • 次ページ ポイント・イン・タイム・リカバリを体験してみる
    • 1
    • 2
    • 3
    • 4

    あなたにお薦め

    連載新着

    連載目次を見る

    今のおすすめ記事

    • 【脱出! 暗闇プロジェクト】

      天狗のマネジャーは不幸への道を必ず歩む

       J部長は悩んでいる。新規プロジェクトのリーダー候補としてA氏とB氏の二人がいて、どちらも甲乙つけがたいのだ。A氏とB氏の仲がいいのであれば、まだ何とかなる。困ったことに、二人はあまり仲がよくないとの噂である。二人とも自己主張が強いタイブで、はたから見ても性格が合わないという印象を受ける。

    ITpro SPECIALPR

    What’s New!

    経営

    アプリケーション/DB/ミドルウエア

    クラウド

    運用管理

    設計/開発

    サーバー/ストレージ

    クライアント/OA機器

    ネットワーク/通信サービス

    セキュリティ

    もっと見る