« ATOK 2007 for Mac | Home | Subversionのmerge »

Slony-I まとめ

結構前から情報を追いかけてはいたけど、PostgreSQLで分散DB を実現させるためにSlony-Iを今回初めてちゃんと使ってみた。

負荷テストとか、異常系のテストとかをしたけどデータの不整合が起こることなくいい感じ。 こんなの「レプリケーション」としてはできるのが当たり前なんだけど、PostgreSQL系のレプリケーションのソフトウェアはその辺からして怪しいのが多いのである。

もしデータ的に壊れてしまった場合、ということで色々手でデータ壊して復旧させてみたのだけど、これも結構簡単なんで、今後安心して運用できそう。運用に入って何か問題が出たらまた何か書く予定。

そんなわけで、ちょっとまとめてみた。

1. Slony-I

非同期シングルマスタのレプリケーションソフト。

欠点（仕様）として、非同期なので、極端に言えば、いつスレーブにレプリケーションされるかわからない。 シングルマスタなので、書き込みが激しいテーブルの負荷分散には使えない。

スレーブは複数台持てる。またカスケードしてスレーブを多段にすることも可能。 レプリケーションはテーブル単位。

Slony-IIってのも開発されてるという噂だけど、表に出てこない。 IIは同期型になるらしいので、場合によって使い分けって感じになるんだろう。でもまったく開発されている雰囲気がない。

2. 仕組

大きくわけて二段階でレプリケーションが行われる。

1. レプリケーション対象となるテーブルに張られているトリガーで、データ更新時にレプリケーション用のログをDB内に格納する
2. Slony-Iのプロセスが1.のログを監視しSlaveに書き出し

1.の部分は完全にPostgreSQLだけの機能で行われるので、Slony-Iプロセスが落ちていても問題ない。ここが結構気に入ってるところ。

たとえば、Slony立ち上げ忘れてたり、なんか落ちちゃった場合にも、ログが取れなかったりすることがない。もちろん2.がないとレプリケーションされないが、そこは元々非同期の部分なので、システム的に致命的にはならないはず。Slony-Iを立ち上げれば溜まっていたログがレプリケーションされる。

3. 設定

Slony-I標準の管理コマンドの説明はこちら。

とりあえず一回はこのチュートリアル通りに一回はやった方がいい。でもやればわかるけど、毎回コマンドを自分でするのは大変。

で、自分で管理用のwrapperを作ってたんだけど、そのまんまの物が標準でついてた。それがslon_tools。 これはSlony-Iの管理コマンドを作成するもの。Slony-Iのコマンドを作成して標準出力に吐くだけなので、サードパーティtoolが変なことしちゃって！という不透明さはない。

slontoolsはSlony-Iに添付されている。GentooだとslonyをUSE=”perl”でemergeするとslontoolsもインストールされる（今思うとこのUSEフラグはいまいちわかりづらいか）。ソースからインストールする場合には、configureに—with-perltoolsをつける。

Gentooの場合だと、/etc/slontools.confへ、ソースからの場合には、prefixによって、/usr/local/etc/slontools.confとかに設定ファイルのサンプルがコピーされてるはずなので、それを適当に編集。

そのファイルにコメントも多いし、上のチュートリアルを一回やった後なら、何を書いたらいいかと迷うところはほぼないはず。LOGDIRに設定するディレクトリはあらかじめ作成してSlony-Iを実行するユーザで書き込み権限与えておく必要があった。

4. 実際にレプリケーションを始める準備

slontoolsの設定が終わったら次は実際にslontoolsとSlony-Iを使って設定の開始。

slonik*がslontoolsのコマンドになる。 例えば、slonikinitclusterコマンドは、クラスタを作成するSlonyコマンドを出力する(Slony-Iで実行はされない)。

$ slonik_init_cluster
# INIT CLUSTER
cluster name = rems_main;
 node 1 admin conninfo='host=hogehoge dbname=tmp2_4 user=postgres port=5432';
 node 2 admin conninfo='host=hogehoge dbname=tmp2_4_1 user=postgres port=5432';
  init cluster (id = 1, comment = 'Node 1 - tmp2_4@hogehoge');

# STORE NODE
  store node (id = 2, event node = 1, comment = 'Node 2 - tmp2_4_1@hogehoge');
  echo 'Set up replication nodes';

# STORE PATH
  echo 'Next: configure paths for each node/origin';
  store path (server = 1, client = 2, conninfo = 'host=hogehoge dbname=tmp2_4 user=postgres port=5432');  store path (server = 2, client = 1, conninfo = 'host=hogehoge dbname=tmp2_4_1 user=postgres port=5432');  echo 'Replication nodes prepared';  echo 'Please start a slon replication daemon for each node';

のように出力される。 もしこれがOKだったら、

$ slonik_init_cluster | slonik

みたいにして、slony本体のコマンドであるslonikに流してやればいい。

実際に単純なレプリケーションをするだけだったら、以下の３つを使うだけ。

• slonikinitcluster : Clusterを作成する。Cluster単位でレプリケーションが行われる。
• slonikcreateset : どのテーブルをレプリケーションするかの設定。1 Clusterに複数set持てる。
• sloniksubscribeset : Slave側で、Masterをsubscribeする。Slaveの数だけこのコマンドを実行する。

上の３つを実行したら準備完了。 後は、Slonyを起動する。これもslon_toolsを使うのが楽。

$ slon_start 1
$ slon_start 2

みたいな感じ。引数はslon_tools.confで指定したnode。

Slony-Iのプロセスは、PostgreSQL(Master/Slave)にTCP/IPで接続するので、アクセスできるようにネットワークやPostgreSQLを設定してあればどこに置いてもいい。普通はそれぞれのサーバー(node)上で起動しておく。

これで、レプリケーションが始まってるはずなので、後はMaster側でDB更新してSlave側にレプリケーションされているのを見て喜べばおｋ

5. ぶっ壊れたとき

幸いまだ経験してないんだけど、MasterとSlaveで不整合が起こっちゃったときの対応方法。 とりあえず全部copyし直すのが（簡単で）よさそう。

方法としては、unsubscribe > subscribe がいいみたい。

$ /usr/bin/slonik_unsubscribe_set  1 2 | slonik
$ /usr/bin/slonik_subscribe_set  1 2 | slonik

みたいな感じ。新たにSubscribeすると、truncate(またはdelete)tableされた後にPostgreSQLのcopyコマンドで全体がコピーされる。その間Slave側ではテーブルは完全にlockされるので何もできなくなる。