PostgreSQL 雑記

PostgreSQLのドキュメントはバージョンごとに管理／公開されているのですが、ウェブ検索から探すと新旧のバージョンの区別無く検索に引っかかってしまいます。特に Google ではエンジンのクセなのか、やけに古いバージョンのドキュメントが第一候補に挙がることが多いんですよね。

そんなところに、たまたま Ready2Search という検索バーを自作できるサイトを見つけたので、PostgreSQL の各バージョンのドキュメントごとの検索バーを作ってみました。検索エンジンは、とりあえず Google にしています。

日本語ドキュメント

• PostgreSQL文書検索 (最新)
• PostgreSQL文書検索 (8.4)
• PostgreSQL文書検索 (8.3)
• PostgreSQL文書検索 (8.2)
• PostgreSQL文書検索 (8.1)
• PostgreSQL文書検索 (8.0)
• PostgreSQL文書検索 (7.4)
• PostgreSQL文書検索 (7.3)

英語ドキュメント

• PostgreSQL Documentation (HEAD)
• PostgreSQL Documentation (8.4)
• PostgreSQL Documentation (8.3)
• PostgreSQL Documentation (8.2)
• PostgreSQL Documentation (8.1)
• PostgreSQL Documentation (8.0)

兼ねてから噂はありましたが、どうやら正式に "PostgreSQL 9.0" としてリリースされることが決まったようです。始めは Dave の冗談かと思いましたが、"the core team have discussed" とありますし……。Hot Standby, Streaming Replication, 64bit Windows 対応と、長年待ち望まれた機能が入ったので、大々的に売り込みたいということだと思います。

ちなみに、バージョンの上2桁 x.y は、こういったマーケティング的な理由で決められます。前回 8.0 のときは Windows 対応がウリでしたっけ。なので、8.3 → 8.4 の差と、8.4 → 9.0 の差は、実はあまり違いが無かったりします。

リリースできれば、とりあえずお祭りになることは間違いなさそうですね。

Hot Standby に続き、Streaming Replication が採用されました → Introduce Streaming Replication。このレプリケーション機能は、以前からある warm standby と動作は似ていますが、遅延が少なく、また特に複数のスタンバイ・サーバを使う場合に管理が容易になる利点があります。Hot Standby との組み合わせでスタンバイ・サーバに参照処理を振り分けることもでき、今後の PostgreSQL のレプリケーションの主流の1つになっていくことは確実です。

---

それでは、コミットメッセージと、変更差分を見てみます。

This includes two new kinds of postmaster processes, walsenders and
walreceiver. Walreceiver is responsible for connecting to the primary server
and streaming WAL to disk, while walsender runs in the primary server and
streams WAL from disk to the client.

PostgreSQL インスタンスは複数のプロセスで構成されますが、レプリケーションのために新しく2種類のプロセス walsender と walreceiver が追加されました。walreceiver はスタンバイ側で動作し、マスタから WAL をストリーム的に受信していったんディスクに書き出します。それを同じくスタンバイ側の startup プロセスが読み取り、更新処理の REDO を行います。一方、walsender はマスタ側で動作し、ディスクから WAL を読み取ってスタンバイ側へ送ります。

1つのマスタ・サーバは複数のスタンバイ・サーバを持つこともでき、最大数は max_wal_senders パラメータで指定します。デフォルトは 0 になっているので、レプリケーションを行う場合は増やす必要があります。

もう1つ追加されたパラメータ wal_sender_delay は、WAL を送るまでに許容する遅延を指定します。デフォルトは 200ms になっており、これはたとえマスタ・サーバがクラッシュしても、直近の 200ms に行われた更新を除いてスタンバイに更新結果を引き継げることを示します。8.4 までの warm standby では WAL セグメント (16MB) を使い切るまでの時間は遅延があったことを考えると、データの消失はかなり抑えられるでしょう。

Documentation still needs work, but the basics are there. We will probably
pull the replication section to a new chapter later on, as well as the
sections describing file-based replication. But let's do that as a separate
patch, so that it's easier to see what has been added/changed. This patch
also adds a new section to the chapter about FE/BE protocol, documenting the
protocol used by walsender/walreceiver.

Streaming Replication のために PostgreSQL サーバとの通信プロトコルが拡張されています。このプロトコルは libpq の API として拡張されていますので、例えば軽量な WAL ストリームの Hub になるプログラムを自作することもできるでしょう。

Bump catalog version because of two new functions,
pg_last_xlog_receive_location() and pg_last_xlog_replay_location(), for
monitoring the progress of replication.

関数 pg_last_xlog_[receive|replay]_location() も追加されており、これらを使って WAL の送信や REDO が大幅に遅延していないか外部からモニタリングすることもできるでしょう。

---

採用されたのは「素」の機能だけなので、例えば初回のファイルコピーからレプリケーションを開始するあたりは補助ツールが欲しいところではありますが、何はともあれ Hot Standby + Streaming Replication が共に採用されたことは歴史に残る改善です。主要な開発者である Simon 氏、Fujii 氏、Heikki 氏は、本当にお疲れさまでした。

さて、8.5 に向けた最後の CommitFest も始まりましたので、当たらなくなったパッチを rebase する仕事に戻ります :)

Hot Standby が採用され、PostgreSQL 8.5 Alpha 3 がリリースされました。

• COMMITTERS: Allow read only connections during recovery, known as Hot Standby.
• Documentation: Hot Standby

postgresql.conf にて recovery_connections = on (default) を指定してアーカイブ・リカバリを開始すると、リカバリ中に接続を受け付けるようになります。正確には、まず最低限の一貫性を保障できる状態まで接続を受け付けない状態で REDO を行い、それ以降は接続を許可して MVCC を満たすよう REDO を行います。リカバリ中の接続では参照のみ許可されています。もし REDO 処理とロック競合が発生した場合には、max_standby_delay の時間だけ待機した後、参照処理を強制的にロールバックします。

「参照クエリ」に含まれない処理に、一時テーブルの作成、シーケンス操作、LISTEN/NOTIFY が含まれることに注意が必要かもしれません（ソート用の一時ファイルは可）。また、統計情報 (pg_stat*) やサーバログは問題なく更新されます。pg_stat_statements も利用できます ― オンメモリ操作だけで実装したのは、結果的に良かったかもしれません。

また、スタンバイ側で時間のかかるトランザクションを行う場合は注意が必要です。PostgreSQL は追加型なので、基本的には残されている過去のデータを自由に参照できるのですが、VACUUM や HOT ではデータが実際に削除されてしまいます。この場合、シングルユーザの集計処理では上記 max_standby_delay を長くするのが適しているでしょう。一方、オンライン処理で遅延を抑えたい場合には、遅延が頻発するのは望ましくありません。代わりに、アクティブ側で vacuum_defer_cleanup_age を設定して、VACUUM が削除するまで若干遅延させるのが良いと思われます。

まだ Streaming Replication は採用されていないので、Hot Standby はこれまでの Warm Standby の延長で使うことになります。アーカイブログの継続的な適用には pg_standby が使えます。また、参照・更新クエリの振り分けは、たぶん pgpool の master-slave モードが利用できると思われます。pgpool + Slony-I 構成の、Slony-I の部分を Hot Standby に置き換える形になります。

Software Design 2010年1月号 に PostgreSQL の記事を執筆しました。

特別企画：～進化するデータベースの今を知る～ PostgreSQL 8.4実践活用ガイド

機能紹介やチューニングは他の方に任せて、自分は特にページレイアウトに関連する地味なネタで書いています。きちんとした設計だと、ふつーに問題なく動作してしまうので、トラブルのあった案件から拾おうと思うとどうしてもバッド・ノウハウの紹介になってしまいますね。