Postgresqlレプリケーションストリーミングレプリケーション仕組みメモ

Postgresqlストリーミングレプリケーション(S/R)仕組みメモ

ここでは、Postgresqlのストリーミングレプリケーションについて、簡単に仕組みと種類をメモしておきます。

参考サイト

日本語訳ドキュメント(9.0.2)
http://www.postgresql.jp/document/pg902doc/html/index.html

仕組みについて正しい情報はここ
http://www.interdb.jp/techinfo/pg_sr/index.html

こちらのスライドがわかりやすい
http://www.slideshare.net/uptimejp/5postgresql

レプリケーションの種類

Postgresql(>=9.0.2)のとき。

表記について

下記の表記は同じものです。

- マスタサーバ、マスタノード、プライマリノードなど
- スレイブサーバ、セカンダリノード、スタンバイサーバなど

PITRについて

ストリーミングレプリケーションのまえに、PITR（ポイントインタイムリカバリ）についておさらいしておくといいと思います。

種類

ファイルベースのログシッピング
- アーカイブログからWALログファイルをコピーして継続的に適用するイメージです。
- セカンダリサーバでは勝手にアーカイブログをコピーしてきて適用しているだけなので、マスタサーバには負荷はかからないようです。
- スタンバイサーバはWALアーカイブ(restore_command参照)から、WALを読み取ることができます。
- スタンバイモードでは、サーバは継続的にマスタサーバから受け取ったWALを適用します

ストリーミングレプリケーション
- WALログファイルではなく、WALレコードを直接受け取って適用するイメージです。同期の遅延が最小に抑えられます。
- スタンバイサーバは直接TCP接続(ストリーミングレプリケーション)を介してマスタサーバから、WALを読み取ることができます。
- スタンバイモードでは、サーバは継続的にマスタサーバから受け取ったWALを適用します

ストリーミングレプリケーション(ホットスタンバイ)
- WALログファイルではなく、WALレコードを直接受け取って適用するイメージです。同期の遅延が最小に抑えられます。また、スタンバイサーバで参照クエリを実行できます。
- スタンバイサーバは直接TCP接続(ストリーミングレプリケーション)を介してマスタサーバから、WALを読み取ることができます。
- スタンバイモードでは、サーバは継続的にマスタサーバから受け取ったWALを適用します

設定の違い

ファイルベースのログシッピング

recovery.conf

standby_mode = 'on'
restore_command = 'cp /path/to/archive/%f %p'
trigger_file = '/path/to/trigger_file'
archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'

ストリーミングレプリケーション

primary_conninfoを設定する
recovery.conf

standby_mode = 'on'
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
restore_command = 'cp /path/to/archive/%f %p'
trigger_file = '/path/to/trigger_file'
archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'

WALストリームを送信する接続許可設定を追加(プライマリ側)
これで、セカンダリ側のwal receiverから接続要求がくると、プライマリ側のwal senderが起動します
pg_hba.conf

host    replication     foo             192.168.1.100/32        md5

ストリーミングレプリケーション(ホットスタンバイ)

primary_conninfoを設定する(セカンダリ側)
recovery.conf

standby_mode = 'on'
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
restore_command = 'cp /path/to/archive/%f %p'
trigger_file = '/path/to/trigger_file'
archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'

host    replication     foo             192.168.1.100/32        md5

ホットスタンバイ
postgresql.conf

wal_level = hot_standby
hot_standby = on    # プライマリ側:off セカンダリ側:on

recovery.conf

standby_mode	'on'を設定することでアーカイブWALファイルの最後に到達してもリカバリを終了せず、新しいWALセグメントの取得を継続します
primary_conninfo	wal receiverの接続設定です。pqb形式でプライマリサーバを指定します
restore_command	起動時にレストアするアーカイブログを指定します。
trigger_file	trigger_fileで指定したファイルを置くことで、fail over(ストリーミングレプリケーションをやめる)します。fail overしないのであれば不要
archive_cleanup_command	wal receiverで取得したWALで、不要になったものを破棄するコマンドを指定します

ストリーミングレプリケーションについて

内容

通常時のストリーミングレプリケーションの動作

　wal senderとwal receiverの動作

ノードを追加した時のセカンダリサーバの動作のイメージ

　ベースバックアップからのレストアと、レストア終了後のスタンバイサーバとしての動作

ストリーミングレプリケーションのだいたいの動き

レプリケーションイメージ(ホットスタンバイ)

便宜的にWALログファイルを受け取るように書いてありますが、実際はTCP接続経由のWALレコードのストリーミングデータで送受信されます。
(この書き方にしたのは、スタンバイサーバの動きがPITRのイメージに近い(ように見えた)からですが･･･)

wal sender	コミットされたWALレコードをTCP接続経由で送信する。セカンダリサーバのwal receiverと接続する。
wal receiver	更新されたWALレコードをTCP接続経由で受信する。プライマリサーバのwal senderと接続する。
startup process	受け取ったWALを適用します。(リカバリ処理を行うプロセスと同じ)