Postgres9.0 レプリケーションめも

設定はこのあたりが参考に...
http://d.hatena.ne.jp/interdb/20100517/1274031168

Q. warm standbyとStreaming Replicationの違い
A. 参照＆更新できない点は同じだが、Streaming Replicationの方がレコード単位である為、遅延が少ない

warm standby	WALファイル単位
Streaming Replication	WALレコード単位

Q. 非同期*1による遅延ってどのくらい？
A. 通常は1秒以下（LAN内で軽いSQLを実行した程度では即反映されている感覚）
warm standbyよりは改善された模様（WALの転送単位がファイル単位からレコード単位になった事により）

詳細な遅延時間は以下で算出できそうです
http://postgresql.g.hatena.ne.jp/pgsql/20100613

Q. スタンバイサーバの追加や削除は？

A. 設定したスタンバイサーバを起動、停止するだけでマスタでの作業はいりません。
ただし、あらかじめマスタで適切な設定を行なっておく必要があります
・スレーブの最大数は、postgresql.confのmax_wal_sendersで設定
・pg_hba.confにて各スレーブがアクセスできるようなネットワークを設定

Q. recovery.confは何に使う？

A. レプリケーションとフェイルオーバーで必要です。スレーブにのみ作成します。
primaryのアドレスを指定してある為、このファイルが無いとレプリケーションできません。また、trigger_fileを指定する事で、フェイルオーバーが可能になります
フェイルオーバー後はrecovery.doneとリネームされます

フェイルオーバー	障害時にスレーブがマスタに切り替わって、サービスを止めること無く稼動させること（具体的にはスレーブサーバが更新可能になる事）
ログ・シッピング	アーカイブ・ログをスタンバイサイトへ転送し、スタンバイサイトは転送されてきたログを適用して常にプライマリサイトに近い状態を保つ方式です。ログシッピングが非同期であることに注意しなければなりません。つまり、WALレコードはトランザクションがコミットした後に転送されます
ストリーミング	データを受信しながら同時に再生を行なう方式。全データを受信するまで待たなくてもよい。
WALログ	トランザクションログ。ディスク書き込み前に作成される
アーカイブログ	使い終わったWALログ。本来なら消去されるログ。バックアップ用に

postgresql.confのパラメータ

archive_mode	アーカイブログを残す設定。onにします
archive_command	ログが満杯になったときのコマンド。基本、cpで他の場所に保存していきます
max_wal_senders	スレーブの最大数　※無限だが、パフォーマンスを維持できるのは10程度までらしい
wal_keep_segmemts	walを保持する範囲。ストリーミングで必須。スタンバイが古いwalを追随して取ってくる場合、十分大きく設定しないと追いつかなくなる可能性がある
archive_timeout	ファイルベースのログシッピングで利用。プライマリ障害時のデータ損失期間を減らす為に調整する。ストリーミングの場合は関係ない

recovery.confのパラメータ

primary_conninfo

プライマリDBへの接続設定（IP,userなど）。ストリーミングで必須。スタンバイは、自分のwalアーカイブ内から再生した後にプライマリに接続

・max_wal_sendersを減らした場合
2つのスレーブが動いている状態で1に変更すると、古い方が無効になる（readonlyで更新はできないまま）
→復帰するには
　①マスタで値を元に戻し、再起動
　②無効になったスレーブを再起動　←①だけでは復帰しないので注意！

*1:※9.1にて同期オプションが付くとの事