slon

名前

slon --  Slony-I デーモン

概要

slon [オプション...] [クラスタ名] [接続情報]

説明

slonSlony-I レプリケーションを"実行する"デーモンアプリケーションです。

オプション

-ddebuglevel

log_level は、slon がログ取得作業を行う時に使用される冗長段階を規定します。

8 段階のログ取得は以下のようになっています。

  • Error

  • Warn

  • Config

  • Info

  • Debug1

  • Debug2

  • Debug3

  • Debug4

-sSYNC check interval

ミリ秒単位で測定される、sync_intervalslon がどの程度頻繁に SYNC が導入されるべきかの検査を指定します。デフォルトは 1000 ms です。sync_Thread_main() の中のメインループは、反復の間で sync_interval ミリ秒間隔でスリープします。

短時間の sync 検査間隔によって、オリジンを"短い束縛"状態に保ち、購読ノードをより頻繁に更新します。もし頻繁に更新されるレプリケートされたシーケンスがあって、そこに影響を受けるテーブルが無い場合、シーケンスが更新されるのに時間は必要なく、従って sync は発生しません

ノードが如何なるレプリケーションセットに対しオリジンでなければ、従い更新は入って来ず、sync_interval_timeout の値よりより小さい値は無駄となります。

-tSYNC interval timeout

それぞれの sync_interval_timeout タイムアウト期間の終わりに、。例え、SYNC を押し出したであろう、更新されたレプリケート可能なデータが存在しなくても、"ローカル"ノード上で SYNC が生成されます。

デフォルト且つ最大は 60000 ms で、1 秒毎に SYNC により、それぞれのノードが"報告"されて来ることを期待できます。

SYNC 事象は購読ノードでも生成されることを覚えておいてください。他のノードに対して複製するデータを実際に生成しないので、これらの SYNC 事象は非常に大きな値ではありません。

-ggroup size

最大の SYNC グループの大きさ、sync_group_maxsize を制御し、デフォルトは 6 です。従って、もしも特定のノードが 200 SYNC 遅れであれば、sync_group_maxsize の最大の大きさのグループにまとめようとします。COMMITする、より少ないトランザクションを持つため、トランザクションのオーバヘッドを削減させると期待されます。

6 というデフォルトは slon に割り当てるメモリをわずかに抑えられる小規模システムにたぶん好都合です。もしも豊富なメモリを所有していれば、これを増加するのは合理的で、それぞれのトランザクションで処理される仕事量を増加させ、追い付かなければならない作業を持っている購読ノードをより迅速に作業させます。

Slon プロセスは通常とても小さく留まります。このオプションが大きな値であっても、 slon は容量で数 MB しか増殖しません。

このパラメータを増加による大きな利点は、トランザクションの COMMIT を減少させることです。1 から 2 へ移行するとかなりの恩典が得られますが、恩典は処理されているトランザクションがかなり多くになるにつれ、進行的に衰えます。 80 と 90 の間では性能に関して量的な差違はありません。その時点で"大きい方が良い"のか否かは、SYNC のより大きいセットが、より多くのメモリの消費とソートの時間をより多く必要とする理由から、 LOG カーソルの振る舞いを悪くするかどうかに依存します。

Slony-I バージョン 1.0 では、slon は常にこの最大値に SYNC をグループにまとめようとし、もしレプリケーションがそこで非常に多量の更新を行っているため不安定な場合(例えば:1 つのトランザクションが 数十万もの行を更新する場合)、もしくはオリジンノードで SYNC が、非常に大きな小数の SYNC が存在することで崩壊させられた場合は理想的でありません。何らかの非常に大きな SYNC のグループ化が slon プロセスを圧倒すると問題に遭遇します。それが再度拾いあげる時、同一の大規模にグループ化された SYNC の処理を試み、管理者が割り込みを掛け、この"デッドロック"を止めさせる -g の値を変更するまで問題が繰り返されます。

Slony-I バージョン 1.0 では、slon はそうはしないで、最大のグループの大きさまで 1 つの SYNC の度に適用的に"立ち上がります"。その結果、もし問題を生じさせるいくつかの SYNC が存在すると、slon は(関連のある全てのウォッチドッグの支援を得て)、常に問題となっている SYNC ひとつひとつが処理されている所に戻ることができ、希望的には操作者による支援が必要なくなります。

-odesired sync time

A "maximum" time planned for grouped SYNCs.

もしレプリケーションが裏で稼働しているならば、slon は、(最終の SYNC グループで消費された時間に基づき)指定された desired_sync_time の値を越えないよう目標を定め、段階的にグループにまとめられる SYNC の数を増加します。

desired_sync_time のデフォルトの値は 60000ms で、これは 1 秒と等価です。

そのようにして、おおざっぱに 1 分に 1 つの COMMIT を期待(少なくとも希望的に)できます。

誰かがとても大規模な更新を要求することは紛れもなく、全てが 1 つのトランザクションとして結果として SYNC を殆ど任意に長たらしくする長さを "書き込む"ことは、全く予想がつきません。

全体的な効果は Slony-I の能力をトラフィックの変化に対応するよう向上することです。たとえ PostgreSQL のバックエンドをクラッシュさせるのに充分なほど変化が大きくなったとしても、1 つの SYNC から徐々に増やして行くことで、必要であれば Slony-I 1 回に 1 つの sync となる所に戻し、レプリケーションが進行するようになるのであればそうの様にします。

-ccleanup cycles

vac_frequency の値はクリーンアップサイクルでどれほど頻繁に VACUUM を行うかを示します。

slon 主導の vacuum を無効にするにはこの値を零にセットします。vacuum を開始するため、pg_autovacuum を使用する場合は、slon 自身に vacuum を行わせる必要はありません。そうでなければ、頻繁に vacuum される必要のある数多くの全く役に立たないタプルを集めた Slony-I が使用するいくつかのテーブル、取り立てると pg_listener、があります。

Slony-I バージョン 1.1 では、これは余り影響を与えません。クリーンアップスレッドは、反復から反復まで、システムの中でいまだ使用できるトランザクション識別子を追跡します。ひとつの反復から次の反復までにこれに変化が無ければ、旧いトランザクションが現役であって、従い VACUUM は何も良いことを行いません。一方、クリーンアップスレッドは、pg_statistics にある統計情報を更新するこれらのテーブルに ANALYZE を掛けます。

-pPID filename

pid_file には slon の PID(プロセス識別子)が保存されるファイル名があります。

これは単一のホスト上で稼働する複数の slon プロセスを監視するスクリプトを作成することを容易にさせます。

-fconfig file

slon 構成を読み込むファイル

この構成は "ランタイム構成" で更に論議されます。もし、複雑な構成パラメータのまとまりが存在したり、(パスワードのように)プロセス環境変数の中で目に見えて欲しくないパラメータがある場合は、構成ファイルから多くの、もしくは全てのパラメータを削除すると便利です。もしくは、共有して使用される構成ファイルの中の全ての slon プロセスに対し共通パラメータを入れ、接続情報を除いてコマンドラインからわずかだけ指定するようにします。外には、それぞれのノード毎に構成ファイルを作成します。

-aarchive directory

archive_dir は、ログ送出モードで使用される SYNC のシーケンスのアーカイブファイルを置くディレクトリを示します。

終了状態

slon は通常に終了した場合シェルに 0 を返します。知命的なエラーに遭遇すると -1 を返します。