<!-- $Id: concepts.sgml,v 1.15 2005/06/22 16:54:23 cbbrowne Exp $ -->
<sect1 id="concepts">
<title>&slony1; Concepts</title>


<para>In order to set up a set of &slony1; replicas, it is necessary
to understand the following major abstractions that it uses:</para>

<itemizedlist>
	<listitem><para>Cluster</para></listitem>
	<listitem><para>Node</para></listitem>
	<listitem><para>Replication Set</para></listitem>
	<listitem><para>Origin, Providers and Subscribers</para></listitem>
        <listitem><para>slon daemons</para></listitem>
        <listitem><para>slonik configuration processor</para></listitem>
</itemizedlist>

<para> It is also worth knowing the meanings of certain Russian words:</para>
<itemizedlist>
<listitem><para>slon is Russian for <quote>elephant</quote></para></listitem>
<listitem><para>slony is the plural of slon, and therefore refers to a group of elephants</para></listitem>
<listitem><para>slonik is Russian for <quote>little elephant</quote></para></listitem>
</itemizedlist>

<para> The use of these terms in &slony1; is a <quote>tip of the
hat</quote> to Vadim Mikheev, who was responsible for the
<application>rserv</application> prototype which inspired some of the
algorithms used in &slony1;.</para>

<sect2>
<title>Cluster</title>
<indexterm>
 <primary>cluster</primary>
</indexterm>

<para>In &slony1; terms, a <quote>cluster</quote> is a named set of
&postgres; database instances; replication takes place between those
databases.</para>

<para>The cluster name is specified in each and every Slonik script via the directive:</para>
<programlisting>
cluster name = 'something';
</programlisting>

<para>If the Cluster name is <envar>something</envar>, then &slony1;
will create, in each database instance in the cluster, the
namespace/schema <envar>_something.</envar></para>
</sect2>
<sect2><title>Node</title>
<indexterm>
<primary>node</primary>
</indexterm>

<para>A &slony1; Node is a named &postgres; database that will be
participating in replication.</para>

<para>It is defined, near the beginning of each Slonik script, using the directive:</para>
<programlisting>
 NODE 1 ADMIN CONNINFO = 'dbname=testdb host=server1 user=slony';
</programlisting>

<para>The <xref linkend="admconninfo"> information indicates database
connection information that will ultimately be passed to the
<function>PQconnectdb()</function> libpq function.</para>

<para>Thus, a &slony1; cluster consists of:</para>
<itemizedlist>
	<listitem><para> A cluster name</para></listitem>
	<listitem><para> A set of &slony1; nodes, each of which has a namespace based on that cluster name</para></listitem>
</itemizedlist>
</sect2>
<sect2><title> Replication Set</title>
<indexterm>
<primary>replication set</primary>
</indexterm>

<para>A replication set is defined as a set of tables and sequences
that are to be replicated between nodes in a &slony1; cluster.</para>

<para>You may have several sets, and the <quote>flow</quote> of
replication does not need to be identical between those sets.</para>
</sect2>

<sect2><title> Origin, Providers and Subscribers</title>
<indexterm>
<primary>origin node</primary>
</indexterm>
<indexterm>
<primary>provider node</primary>
</indexterm>

<para>Each replication set has some origin node, which is the
<emphasis>only</emphasis> place where user applications are permitted
to modify data in the tables that are being replicated.  This might
also be termed the <quote>master provider</quote>; it is the main
place from which data is provided.</para>

<indexterm>
<primary>subscriber node</primary>
</indexterm>

<para>Other nodes in the cluster subscribe to the replication set,
indicating that they want to receive the data.</para>

<para>The origin node will never be considered a
<quote>subscriber.</quote> (Ignoring the case where the cluster is
reshaped, and the origin is expressly shifted to another node.)  But
&slony1; supports the notion of cascaded subscriptions, that is, a
node that is subscribed to some set may also behave as a
<quote>provider</quote> to other nodes in the cluster for that
replication set.</para>
</sect2>

<sect2><title>slon Daemon</title>

<para>For each node in the cluster, there will be a <xref
linkend="slon"> process to manage replication activity for that node.
</para>

<para> <xref linkend="slon"> is a program implemented in C that
processes replication events.  There are two main sorts of events:</para>

<itemizedlist>

<listitem><para> Configuration events</para>

<para> These normally occur when a <xref linkend="slonik"> script is
run, and submit updates to the configuration of the cluster. </para>
</listitem>

<listitem><para> <command>SYNC</command> events </para>

<para> Updates to the tables that are replicated are grouped together
into <command>SYNC</command>s; these groups of transactions are
applied together to the subscriber nodes.  </para>
</listitem>
</itemizedlist>
</sect2>

<sect2><title>slonik Configuration Processor</title>

<para> The <xref linkend="slonik"> command processor processes scripts
in a <quote>little language</quote> that are used to submit events to
update the configuration of a &slony1; cluster.  This includes such
things as adding and removing nodes, modifying communications paths,
adding or removing subscriptions.
</para>
</sect2>
</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:
-->
