実際に Slony-I レプリケーションを遂行するプログラムは slon デーモンです。
Slony-I クラスタ内のそれぞれのノードに対して、それらのノードが "master" もしくは "slave" に係わらず、1つの slon インスタンスが必要です。MOVE SET または FAILOVER でノードの役割りを交換できるので、slon はプロバイダとサブスクライバ双方として機能する必要があります。これらのデーモンはいかなる特定のホスト上でも走ることは必須ではありませんが、考慮すべきいくつかの原則があります。
それぞれの slon は、それが"ノードコントローラ"であるデータベースと迅速に通信できる必要があります。したがって、Slony-I クラスタが何らかの広域ネットワーク(WAN)に渡って稼働する場合は、slon プロセスはそれぞれが管理しているその、もしくは近くのデータベース上で走らなければなりません。この規則に違反しても特別な災害が引き起こされるわけではありませんが、待ち時間の追加により slon "自身のノード"上の事象の監視がレプリケーションを多少時宜を得ないようにさせます。
最も速い結果はサービスを提供しているデータベース上でそれぞれの slon を走らせることにより達成されます。もし何らかの速いローカルネットワーク内で走るのであれば、性能は検知されるほど劣化しないでしょう。
多くの slon プロセスを1つのマシン上のクラスタで走らせることは魅力的な考え方です。と言うのは、1つの位置にあるログファイルやプロセステーブルの双方の観点からも管理するのは用意になるからです。ログファイルを見ることや slon インスタンスを再起動させるために複数のホストにログインする必要性もなくなります。
現時点で2つの"ウォッチドッグ"スクリプトが利用できます。
tools/altperl/slon_watchdog - slon の起動回りのループを基本的にラップし、障害時に再起動をかける"初期の"バージョンです。
tools/altperl/slon_watchdog2 - データベースに定期的にポーリングし、最近 SYNC が行われたかどうかを調査する多少知的なバージョンです。アプリケーションに警告を出さず時おり障害を引き起こす VPN 接続がかつてあって、slon は働きを停止するものの、死ぬことはありません。ポーリングはこの問題に対処するものです。
slon_watchdog2 スクリプトは多分通常、むしろ走らせるものでしょう。最初の COPY SET を行うのに沢山の時間を要すると予想される非常に大規模なレプリケーションセットを購読する時の一点だけ、走らせるのは好ましくありません。この場合に問題となるのは、2時間も SYNC が行われれず、slon の再起動を要求する何かの支障があり、そこで COPY SET 事象の再起動が起こると言う事例がありました。より最近では COPY SET が進行中であることを検出するスクリプトが書き換えられました。