象と戯れ

 | 

2009-08-08

Synch Rep と Hot Standby

19:48 | Synch Rep と Hot Standby - 象と戯れ を含むブックマーク はてなブックマーク - Synch Rep と Hot Standby - 象と戯れ

先生!

やっと(いまさら)わかりましたぞ。両者の関係が。

前提(現状):
  • WALを書き出している
  • WALを任意のコマンドに通すことができる。"archive_command"
  • WALを使ったリカバリができる。"recovery_command"
  • リカバリするにはWALを書き出し始めた(もしくはそれ以降)時点でのスナップショットバックアップが必要
  • リカバリはPostgreSQLの起動処理で行われる
  • リカバリ中はSQLを受け付けられない
  • 要するにネタは揃っているけどメンドクサイしあくまで「リカバリ」である
  • pg_standbyというcontribモジュールがある
  • pg_standbyはリカバリモードを継続し、「主になって」というまでひたすらWALリカバリを続ける

Synch Rep:
  • walsender/walreceiverを開発して指定したサーバ間でWALをやりとりする
  • 受け取り側がOKするまで送り側はCOMMITしない
  • COMMITを管理するだけでリカバリモードについては今まで通り
Hot Standby:
  • リカバリ中もRead-OnlyなSQLを受け付ける
  • WALの送受信については知らない
  • 各種書き込み処理をブロックする

というわけで用途別に考えると下記のようになります。

コールドスタンドバイ(ダウンタイムゼロ)

とにかく主が死んでも誰かが処理を引き継いでほしい、システム全体として止まっちゃイヤな場合。まさにNTTが2008年にOttawaで発表したケース。なので、Synch Repが完成すればOK。但し主が死んだ時に「自動的に」従が処理を引き継ぐHeartBeatにあたる処理はないので別途自分で用意してね。


負荷分散

読み取り専用の従が複数いて主の更新を断続的に反映してくれればOKな場合。現状ではリカバリモードでSQLを受付られないし、SQLを受け付けている間はWAL反映が出来ない。ので、Hot Standbyが完成してくれればOK。但しSynch Repができるまでは自分でWALを送信(archive_commandを使えばできる)しなきゃいけないけど、WALがアーカイブされるまでにはそれなりに時間があるし、なにより主はどんどんCOMMITしてしまうのでズレも生じうる。Asynchなレプリケーションとしてはありではないかと。

どっちも開発Wikiにかなりのボリュームのドキュメントがあるのですが、どっちも「AはやるけどBはやらない」みたいな記述がなくて、というかかなり前提がすっとばされているので、理解するまでに時間が掛かりました。

Web屋さん的視点に立てば参照系での負荷分散は喉から手が出るほど欲しいところです。がHot StandbyだけできてもAdminが難しすぎるので、Synch Rep付の完全体になることを楽しみにしています。

ちなみにHot Standbyはメールアーカイブを読む限り去年の段階でかなりできあがっているように見えるのですが、何故に取り込まれていないのでしょうか。というのをこれから探る予定です。


xlog.cでも読んでみるかー

 |