<!-- $Id: intro.sgml,v 1.17 2005/05/12 21:47:02 cbbrowne Exp $ -->
<sect1 id="introduction">
<title>Introduction to &slony1;</title>
<sect2> <title>What &slony1; is</title>

<para>&slony1; is a <quote>master to
multiple slaves</quote> replication system supporting cascading and
slave promotion.  The big picture for the development of
&slony1; is as a master-slave system that
includes all features and capabilities needed to replicate large
databases to a reasonably limited number of slave systems.
<quote>Reasonable,</quote> in this context, is probably no more than a
few dozen servers.  If the number of servers grows beyond that, the
cost of communications becomes prohibitively high.</para>

<para> See also <xref linkend="slonylistenercosts"> for a further
analysis of costs associated with having many nodes.</para>

<para> &slony1; is a system intended for data centers and backup
sites, where the normal mode of operation is that all nodes are
available all the time, and where all nodes can be secured.  If you
have nodes that are likely to regularly drop onto and off of the
network, or have nodes that cannot be kept secure, &slony1; is
probably not the ideal replication solution for you.</para>

<para> Thus, examples of cases where &slony1; probably won't work out
well would include:

<itemizedlist>
<listitem><para> Sites where connectivity is really <quote>flakey</quote>
</para></listitem>
<listitem><para> Replication to nodes that are unpredictably connected.</para>

<para> Replicating a pricing database from a central server to sales
staff who connect periodically to grab updates.  </para></listitem>
</itemizedlist></para>

<para> There is also a <link linkend="logshipping">file-based log
shipping</link> extension where updates would be serialized into
files.  Given that, log files could be distributed by any means
desired without any need of feedback between the provider node and
those nodes subscribing via <quote>log shipping.</quote></para>

<para> But &slony1;, by only having a single origin for each set, is
quite unsuitable for <emphasis>really</emphasis> asynchronous multiway
replication.  For those that could use some sort of
<quote>asynchronous multimaster replication with conflict
resolution</quote> akin to what is provided by <productname>Lotus
<trademark>Notes</trademark></productname> or the
<quote>syncing</quote> protocols found on PalmOS systems, you will
really need to look elsewhere.  These sorts of replication models are
not without merit, but they represent <emphasis>different</emphasis>
replication scenarios that &slony1; does not attempt to
address.</para>

</sect2>

<sect2><title>Why yet another replication system?</title>

<para>&slony1; was born from an idea to create a replication system
that was not tied to a specific version of &postgres;, which is
allowed to be started and stopped on an existing database with out the
need for a dump/reload cycle.</para>

</sect2>

<sect2><title> What &slony1; is not</title>

<itemizedlist>
<listitem><para>&slony1; is not a network management system.</para></listitem>

<listitem><para> &slony1; does not have any functionality within it to detect a
node failure, nor to automatically promote a node to a master or other
data origin.</para>

<para> It is quite possible that you may need to do that; that
will require that you combine some network tools that evaluate
<emphasis> to your satisfaction </emphasis> which nodes you consider
<quote>live</quote> and which nodes you consider <quote>dead</quote>
along with some local policy to determine what to do under those
circumstances.  &slony1; does not dictate any of that policy to
you.</para></listitem>

<listitem><para>&slony1; is not multi-master; it is not a connection broker, and
it doesn't make you coffee and toast in the morning.</para></listitem>

</itemizedlist>

<para>All that being said, there are tools available to help with some
of these things, and there is a plan under way for a subsequent
system, <productname>Slony-II</productname>, to provide
<quote>multimaster</quote> capabilities.  But that represents a
different, separate project, being implemented in a rather different
fashion than &slony1;, and expectations for &slony1; should not be
based on hopes for future projects.</para></sect2>

<sect2><title> Why doesn't &slony1; do automatic fail-over/promotion?
</title>

<para>That is properly the responsibility of network monitoring
software, not &slony1;.  The configuration, fail-over paths, and
preferred policies will be different for each site.  For example,
keep-alive monitoring with redundant NIC's and intelligent HA switches
that guarantee race-condition-free takeover of a network address and
disconnecting the <quote>failed</quote> node will vary based on
network configuration, vendor choices, and the combinations of
hardware and software in use.  This is clearly the realm of network
management software and not &slony1;.</para>

<para> Furthermore, choosing what to do based on the
<quote>shape</quote> of the cluster represents local business policy.
If &slony1; imposed failover policy on you, that might conflict with
business requirements, thereby making &slony1; an unacceptable
choice.</para>

<para>As a result, let &slony1; do what it does best: provide database
replication.</para></sect2>

<sect2><title> Current Limitations</title>

<para>&slony1; does not automatically propagate schema changes, nor
does it have any ability to replicate large objects.  There is a
single common reason for these limitations, namely that &slony1;
operates using triggers, and neither schema changes nor large object
operations can raise triggers suitable to tell &slony1; when those
kinds of changes take place.</para>

<para>There is a capability for &slony1; to propagate DDL changes if
you submit them as scripts via the <application>slonik</application>
<xref linkend="stmtddlscript"> operation.  That is not
<quote>automatic;</quote> you have to construct an SQL DDL script and
submit it, and there are a number of further caveats.</para>

<para>If you have those sorts of requirements, it may be worth
exploring the use of &postgres; 8.0 <acronym>PITR</acronym> (Point In
Time Recovery), where <acronym>WAL</acronym> logs are replicated to
remote nodes.  Unfortunately, that has two attendant limitations:

<itemizedlist>
	
<listitem><para> PITR replicates <emphasis>all</emphasis> changes in
<emphasis>all</emphasis> databases; you cannot exclude data that isn't
relevant;</para></listitem>

<listitem><para> A PITR replica remains dormant until you apply logs
and start up the database.  You cannot use the database and apply
updates simultaneously.  It is like having a <quote>standby
server</quote> which cannot be used without it ceasing to be
<quote>standby.</quote></para></listitem>

</itemizedlist></para>
</sect2>

<sect2><title>Replication Models</title>

<para>There are a number of distinct models for database replication;
it is impossible for one replication system to be all things to all
people.</para>

<para> &slony1; implements a particular model, namely that of
asynchronous replication, using triggers, where a single
<quote>origin</quote> may be replicated to multiple
<quote>subscribers</quote> including cascaded subscribers.</para>

<para> There are a number of other replication models which are
<emphasis> different </emphasis>; it is worth pointing out other
approaches that exist.  &slony1; is certainly not the only approach,
and for some applications, it is <emphasis> not </emphasis> the
optimal approach. </para>

<itemizedlist> 
<listitem><para> Synchronous single-origin multi-subscriber replication</para>

<para> In a synchronous system, updates cannot be committed at the
origin until they have also been accepted by subscriber nodes.  This
enhances the security property of nonrepudiation as updates will not
be committed until they can be confirmed elsewhere.  Unfortunately,
the requirement that changes be applied in multiple places introduces
a performance bottleneck.  </para>

<para> This approach is similar to the two phase commit processing
model of the XA transaction processing protocol.</para>
</listitem>

<listitem><para> Synchronous multi-origin multi-subscriber replication </para> 

<para> This is the model being used by the forthcoming
<productname>Slony-II</productname> system.  Synchronous replication
systems all <quote>suffer</quote> from the performance bottleneck that
updates must be accepted on all nodes before they can be
<command>commit</command>ted anywhere.  </para>
</listitem>

<listitem><para> Asynchronous multimaster replication with conflict
avoidance/resolution</para>

<para> Perhaps the most widely used replication system of this sort is
the <productname>PalmOS HotSync</productname> system.
<trademark>Lotus Notes</trademark> also provides a replication system
that functions in much this manner.</para>

<para> The characteristic <quote>troublesome problem</quote> with this
style of replication is that it is possible for conflicts to arise
because users update the same record in different ways on different
nodes. </para>

<para> In the case of <productname>HotSync</productname>, if conflicts
arise due to records being updated on multiple nodes, the
<quote>resolution</quote> is to simply create a duplicate record to
reflect the two changes, and have the user resolve the conflict
manually. </para>

<para> Some async multimaster systems try to resolve conflicts by
finding ways to apply partial record updates.  For instance, with an
address update, one user, on one node, might update the phone number
for an address, and another user might update the street address, and
the conflict resolution system might try to apply these updates in a
non-conflicting order.</para>

<para> Conflict resolution systems almost always require some domain
knowledge of the application being used. </para>
</listitem>

</itemizedlist>

</sect2>
</sect1>

<sect1 id="slonylistenercosts"><title> &slony1; Communications
Costs</title>

<para>The cost of communications grows in a quadratic fashion in
several directions as the number of replication nodes in a cluster
increases.  Note the following relationships:

<itemizedlist>

<listitem><para> It is necessary to have <xref
linkend="table.sl-listen"> entries allowing connection from each node
to every other node.  Most will normally not need to be very heavily,
but it still means that there needs to be n(n-1) paths.
</para></listitem>

<listitem><para> Each SYNC applied needs to be reported back to all of
the other nodes participating in the set so that the nodes all know
that it is safe to purge <xref linkend="table.sl-log-1"> and <xref
linkend="table.sl-log-2"> data, as any <quote>forwarding</quote> node
could potentially take over as <quote>master</quote> at any time.  One
might expect SYNC messages to need to travel through n/2 nodes to get
propagated to their destinations; this means that each SYNC is
expected to get transmitted n(n/2) times.  Again, this points to a
quadratic growth in communications costs as the number of nodes
increases.</para></listitem>

</itemizedlist></para>

<para>This points to it being a bad idea to have the large
communications network resulting from the number of nodes being large.
Up to a half dozen nodes seems pretty reasonable; every time the
number of nodes doubles, this can be expected to quadruple
communications overheads.</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:
-->
