<!-- $Id: startslons.sgml,v 1.11 2005/02/22 17:37:59 darcyb Exp $ -->
<sect1 id="slonstart"> <title>Slon daemons</title>

<para>The programs that actually perform &slony1; replication are the
<application>slon</application> daemons.</para>

<para>You need to run one <xref linkend="slon"> instance for each node
in a &slony1; cluster, whether you consider that node a
<quote>master</quote> or a <quote>slave</quote>. Since a <command>MOVE
SET</command> or <command>FAILOVER</command> can switch the roles of
nodes, slon needs to be able to function for both providers and
subscribers.  It is not essential that these daemons run on any
particular host, but there are some principles worth considering:

<itemizedlist>

<listitem><para> Each <application>slon</application> needs to be able
to communicate quickly with the database whose <quote>node
controller</quote> it is.  Therefore, if a &slony1; cluster runs
across some form of Wide Area Network, each slon process should run on
or nearby the databases each is controlling.  If you break this rule,
no particular disaster should ensue, but the added latency introduced
to monitoring events on the slon's <quote>own node</quote> will cause
it to replicate in a <emphasis>somewhat</emphasis> less timely
manner.</para></listitem>

<listitem><para> The very fastest results would be achieved by having
each <application>slon</application> run on the database server that
it is servicing.  If it runs somewhere within a fast local network,
performance will not be noticeably degraded.</para></listitem>

<listitem><para> It is an attractive idea to run many of the
<application>slon</application> processes for a cluster on one
machine, as this makes it easy to monitor them both in terms of log
files and process tables from one location.  This also eliminates the
need to login to several hosts in order to look at log files or to
restart <application>slon</application> instances.</para></listitem>

</itemizedlist>
</para>

<para>There are two <quote>watchdog</quote> scripts currently available:

<itemizedlist>

<listitem><para> <filename>tools/altperl/slon_watchdog</filename> -
an <quote>early</quote> version that basically wraps a loop around the
invocation of <xref linkend="slon">, restarting any time it falls
over</para>
</listitem>

<listitem><para> <filename>tools/altperl/slon_watchdog2</filename>
- a somewhat more intelligent version that periodically polls the
database, checking to see if a <command>SYNC</command> has taken place
recently.  We have had VPN connections that occasionally fall over
without signalling the application, so that the <xref linkend="slon">
stops working, but doesn't actually die; this polling addresses that
issue.</para></listitem>

</itemizedlist></para>

<para>The <filename>slon_watchdog2</filename> script is probably
<emphasis>usually</emphasis> the preferable thing to run.  It was at
one point not preferable to run it whilst subscribing a very large
replication set where it is expected to take many hours to do the
initial <command>COPY SET</command>.  The problem that came up in that
case was that it figured that since it hasn't done a
<command>SYNC</command> in 2 hours, something was broken requiring
restarting slon, thereby restarting the <command>COPY SET</command>
event.  More recently, the script has been changed to detect
<command>COPY SET</command> in progress.</para>

</sect1>
<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
sgml-omittag:nil
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:"book.sgml"
sgml-exposed-tags:nil
sgml-local-catalogs:("/usr/lib/sgml/catalog")
sgml-local-ecat-files:nil
End:
-->
