象と戯れ

 | 

2010-01-23

ホットスタンバイとストリーミングレプリケーションを触ってみた

04:11 | ホットスタンバイとストリーミングレプリケーションを触ってみた - 象と戯れ を含むブックマーク はてなブックマーク - ホットスタンバイとストリーミングレプリケーションを触ってみた - 象と戯れ

#タイトルはあえてカタカナで。

そのうちLet'sあたりでちゃんとした解説が出ることを期待しつつ、野良ビルドでの最速(!)レビュー。

現段階でまだ開発途中ですがソースをgitあたりで取ってきて試せます。

ドキュメントが大幅に再構成されるという噂もありつつ、現時点では24章(バックアップとリストア)に記述されていますのでその辺りを参考に。特にストリーミングレプリケーションのセクションに手順が詳しく書いてあります。ホットスタンバイはリカバリモードに入ればデフォルトでONになるようです。

ちなみに環境はプライマリ、スタンバイともにCent5ですがマイナーバージョンが異なるので当然カーネルのバージョンは若干異なりますが問題ないようで。共に32ビット。これは揃える必要があります。

1.プライマリでinitdb

今回はDB作るところからやります。適宜createdbもしちゃって下さい。

2.pg_hba.confをいじる

いつものように

host all all 192.168.1.0/24 trust

みたいにガバガバで書けば問題ないですが、対象データベースの箇所にreplicationという値が設定できるので

host replication user 192.168.1.0/24 trust

という感じでかいておけばOK

3.postgresql.confをいじる

少なくともスタンバイからアクセスできるようにしつついつもの通り設定。つまりは

listen_address = '*'

です。

あと、archive_modeを'on'にしてarchive_commandを設定してやる必要があります。何故かは知りません。WALまわりは底なし沼なのでいつも深く考えないようにしていますw。

archive_mode = 'on'

archive_command = 'cp "%p" /data/backup/%f'

最低限これでOK。

4.プライマリを立ち上げる

おもむろにプライマリサーバを立ち上げます。

[user@primary ~]$ postgres -D /data/pg

5.バックアップをスタンバイにコピー

ここもいろんなやり方があると思いますが、今回はPgConでのデモのようにpg_start_backup().

[user@primary ~]$ psql regression -U postgres

regression=# select pg_start_backup('repli');

[user@standby ~]$ scp -rp standby:/data/pg /data/

6.スタンバイ用に再構成

とりあえずpostmaster.pidを消します。続いて、今回は実験なのでスタンバイでのWALは要らない想定として、postgresql.confをエディットしarchive_commandをコメントアウト。スタンバイをフェイルオーバーに使う想定などではpg_hba.confの修正とかもいるかもしれません。

7.recovery.confを作成

recovery.confはリカバリモードで起動するためのファイルです。これを$PGDATAに作成しておくとpostgresの起動時にリカバリモードに入る。具体的には下記のような内容を記述。primary_conninfoはプライマリへの接続文字列です。

[user@standby ~]$ echo "standby_mode = on" >> /data/pg/recovery.conf

[user@standby ~]$ echo "primary_conninfo = 'host=primary'" >> /data/pg/recovery.conf

そしてこれはダメです。standby_mode = 'on'やstandby_mode = 'true'というようにクォートしてください。

LOG: starting archive recovery

FATAL: syntax error in recovery command file: standby_mode = on

というところで少しハマった。適宜修正してスタンバイも起動。

LOG: starting archive recovery

LOG: standby_mode = 'on'

LOG: primary_conninfo = 'host=primary'

LOG: automatic recovery in progress

LOG: initializing recovery connections

LOG: redo starts at 0/B000250

LOG: consistent recovery state reached at 0/B0002DC

LOG: starting streaming recovery at 0/B0002DC

こんな感じのログが出れば成功です。"starting streaming recovery"がなんとなくSRを開始した感触です。おめでとう、これでレプリケーションが完成しました。なんて簡単なんだ!

と喜ぶのもつかの間、スタンバイにpsqlできない。

[user@standby ~]$ psql regression

psql: FATAL: the database system is starting up

うーんなんでだろうと悩むこと約15分。GDBしようかと思ってしまった。

ここまで読んだ手練れな皆様ならすでにおわかりかもしれませんが、プライマリでpg_stop_backup()してないのでした。プライマリでpg_stop_backupするまではホットスタンバイが始まらないみたいですね。ドキュメントに書いてあるのか調べてないですが。

LOG: database system is ready to accept read only connections

という起動ログがでるまではホットスタンバイが始まっていないので、ご注意を。プライマリでpg_stop_backup()した瞬間、スタンバイでこれが出ました。

あとは存分にレプリケーションを楽しむだけ。ちょろっと触ったところでわかったのは、まだ非同期モードなのでそこには注意した方がよさそうなところ。例えば

P(Primary):BEGIN;

P:DROP TABLE t;

S(Standby):SELECT count(*) FROM t; [LOCK]

P:ROLLBACK;

というようなシナリオの時、プライマリのロールバック後暫くはスタンバイのレスポンスがないこと。ほっといても十数秒後にはレスポンスがありましたが、プライマリでCHECKPOINTするとスタンバイに反応がありました。プライマリでのDELETEもスタンバイに反映されるまでに少し間がある感じでした。このへんは同期モードになると変わるものと思われます。

「組み込み」で「簡単」になったとは言え、上記の手順はまだまだ単純化できそうな気がします。ユーティリティツールの出番か。逆に、動き出してからのシームレス感は絶大ですね。ほんとに何も気にする必要がない。

というわけで、今後は実データを投入して実戦での使い方を模索して行きますであります。

aaaaaa2010/01/26 12:41archive_mode = on が必要なのはオンライン・バックアップを取得するためですね。off だと pg_start/stop_backup が実行できません。

 |