Slony-I は実際 "cleanup" スレッドで数多くの必要とされる保守を自身で行います。
特に sl_log_1, sl_log_2 (not yet used), and sl_seqlog のエントリの Slony-I クラスタ名前空間にある各種のテーブルから古いデータを消去します。
Slony-I で使用されるあるテーブルをバキュームします。1.0.5 時点では pg_listener を含みます。より以前のバージョンではそのテーブルを十分にバキュームしなければなりません。さもないと、Slony-I は数多くの事象を立ち上げ、これによって数多くの無用なタプルを持つことになり、レプリケーションを遅くします。
あるバージョン(1.1 は確かです。1.0.5 でも多分)においては、テーブルのバキュームを扱うための pg_autovacuum を使用しているのであればそれら如何なるテーブルをバキュームするのを妨げないオプションがあります。残念ながら pg_autovacuum は十分と言える程度に頻繁にバキュームを行わないようなので、内部バキュームを使用した方が良いかもしれません。"かなり頻繁に" pg_listener をバキュームしても、十分な頻度でバキュームしないよりも危険ではありません。
遺憾ながら長期に係わるトランザクションがある場合は、未だ走っている一番古いトランザクションよりよりも新しい死んだタプルをバキュームは整理できません。このことは pg_listener を肥大化させる最も顕著な要因で、レプリケーションを遅くさせます。
重複キー違反バグは何らかの PostgreSQL 競合状態の追跡を助けます。残っている一つの問題として、VACUUM が空間を正しく回復させずに B-tree を破壊に導きます。
この問題を回避するため、定期的に REINDEX TABLE sl_log_1; を走らせると役立つかもしれません。
物事を監視する2つの"ウォッチドッグ"が利用でき、接続を失わせるネットワーク"欠陥"等の理由で slon プロセスが突然停止した時、再起動を掛けます。
走らせてみたいと思いませんか …
Slony-I 1.1 用の新しいスクリプトは generate_syncs.sh で、次のような状況に対処するものです。
slon デーモンが常時稼働しないかもしれない重厚でないサーバであって、週明けに業務に戻って来たら以下の状況を発見した。
金曜日の夜に何かが"突沸"し、データベースは復旧したものの slon デーモンは生き残っていなかった。オンラインアプリケーションはほぼ3日に渡る常識的とも言える大量のトランザクション負荷に見舞われた。
月曜日に slon を再起動した時点で、金曜日からマスター上で SYNC をしていないので次の "SYNC セット"は金曜日から月曜日までの全ての更新を含んでいた。オエッ!
もしも generate_syncs.sh を20分おきにクロンジョブとして走らせておけば、オリジン上で SYNC を定期的に強制し、金曜日から月曜日の間で数多くの更新が100以上の SYNC に分割され、増分が適用されるので掃除がより快適になります。
もしも SYNC が定期的に走しらされてるならこのスクリプトは功も害も与えないことを覚えておいてください。
tools ディレクトリに Slony-I インスタンスを監視するのに用いられる4つのスクリプトがあります。
test_slony_replication は Slony-I ノードを取得する接続情報を渡せる Perl スクリプトです。そして、要求されるレプリケーションセットの形態を決定するためにそのノードの sl_path とその他の情報を問い合わせます。
その次に、テストテーブルに slony_test と呼ばれるテスト問い合わせを注入します。その問い合わせは以下のように定義され、レプリケートされるテーブルのセットに追加される必要があります。
CREATE TABLE slony_test ( description text, mod_date timestamp with time zone, "_Slony-I_testcluster_rowID" bigint DEFAULT nextval('"_testcluster".sl_rowid_seq'::text) NOT NULL );
テーブルの最後の列は主キーを欠いてはいますが Slony-I で定義されました。
このスクリプトはそれぞれの Slony-I ノードに対して、cluster.fact.log と言うファイルの中の要求されたレプリケーションセットに対して使用できる1行の出力を生成します。
アプリケーションの状態について何らかを決定することが可能なアプリケーション特有の SQL 問い合わせを渡せるようにする追加の finalquery オプションがあります。
log.pm は Perl スクリプトのログを管理する Perl モジュールです。
run_rep_tests.sh は test_slony_replication を起動する"ラッパー"スクリプトです。
いくつかの Slony-I クラスタを所有している場合、全てのそれらクラスタに接続するためこのファイルで構成を設定できます。
nagios_slony_test は、レプリケーションテストを頻繁に行わせるようにして(私たちは6分毎に走らせていますが)、ログファイルに問い合わせをするように構成を行うスクリプトで、そして Nagios のような監視ツールがそれらのログで指摘された状態を問い合わせるこのスクリプトを使用するべく設定可能になります。
Nagios に直接テストを実行させるよりも cron ジョブでテストを実行し、Nagios に結果を検証させることの方がより効率がよいと思われます。Nagios が何度も何度も更新を呼び出すよりも、このテストで Slony-I クラスタ全体を1回で検証できます。
slon デーモンはどのデバッグレベルが設定されているかに応じて何らかの水準の冗長的なログを生成します。類別も必要かもしれません。
Apache の rotatelogs のようなローテイタを使用して、一つのログが大きくならないようにログファイルを順序立てしてください。
定期的に古いログファイルを削除します。