/usr/share/doc/slony1-2-doc/adminguide/concepts.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Slony-I Concepts</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REV="MADE"
HREF="mailto:slony1-general@lists.slony.info"><LINK
REL="HOME"
TITLE="Slony-I 2.2.3 Documentation"
HREF="index.html"><LINK
REL="UP"
TITLE="Preface"
HREF="preface.html"><LINK
REL="PREVIOUS"
TITLE="System Requirements"
HREF="requirements.html"><LINK
REL="NEXT"
TITLE=" Current Limitations"
HREF="limitations.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="stylesheet.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-8859-1"><META
NAME="creation"
CONTENT="2014-07-24T12:39:44"></HEAD
><BODY
CLASS="SECT1"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="5"
ALIGN="center"
VALIGN="bottom"
><SPAN
CLASS="PRODUCTNAME"
>Slony-I</SPAN
> 2.2.3 Documentation</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="requirements.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="preface.html"
>Fast Backward</A
></TD
><TD
WIDTH="60%"
ALIGN="center"
VALIGN="bottom"
>Chapter 1. Preface</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="top"
><A
HREF="preface.html"
>Fast Forward</A
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="top"
><A
HREF="limitations.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="CONCEPTS"
>1.3. <SPAN
CLASS="PRODUCTNAME"
>Slony-I</SPAN
> Concepts</A
></H1
><A
NAME="AEN161"
></A
><P
>In order to set up a set of <SPAN
CLASS="PRODUCTNAME"
>Slony-I</SPAN
> replicas, it is necessary
to understand the following major abstractions that it uses:</P
><P
></P
><UL
><LI
><P
>Cluster</P
></LI
><LI
><P
>Node</P
></LI
><LI
><P
>Replication Set</P
></LI
><LI
><P
>Origin, Providers and Subscribers</P
></LI
><LI
><P
>slon daemons</P
></LI
><LI
><P
>slonik configuration processor</P
></LI
></UL
><P
> It is also worth knowing the meanings of certain Russian words:</P
><P
></P
><UL
><LI
><P
>slon is Russian for <SPAN
CLASS="QUOTE"
>"elephant"</SPAN
></P
></LI
><LI
><P
>slony is the plural of slon, and therefore refers to a group of elephants</P
></LI
><LI
><P
>slonik is Russian for <SPAN
CLASS="QUOTE"
>"little elephant"</SPAN
></P
></LI
></UL
><P
> The use of these terms in <SPAN
CLASS="PRODUCTNAME"
>Slony-I</SPAN
> is a <SPAN
CLASS="QUOTE"
>"tip of the
hat"</SPAN
> to Vadim Mikheev, who was responsible for the
<SPAN
CLASS="APPLICATION"
>rserv</SPAN
> prototype which inspired some of the
algorithms used in <SPAN
CLASS="PRODUCTNAME"
>Slony-I</SPAN
>.</P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN193"
>1.3.1. Cluster</A
></H2
><A
NAME="AEN195"
></A
><P
>In <SPAN
CLASS="PRODUCTNAME"
>Slony-I</SPAN
> terms, a <SPAN
CLASS="QUOTE"
>"cluster"</SPAN
> is a named set of
<SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> database instances; replication takes place between those
databases.</P
><P
>The cluster name is specified in each and every Slonik script via the directive:</P
><PRE
CLASS="PROGRAMLISTING"
>cluster name = something;</PRE
><P
>If the Cluster name is <TT
CLASS="ENVAR"
>something</TT
>, then <SPAN
CLASS="PRODUCTNAME"
>Slony-I</SPAN
>
will create, in each database instance in the cluster, the
namespace/schema <TT
CLASS="ENVAR"
>_something.</TT
></P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN207"
>1.3.2. Node</A
></H2
><A
NAME="AEN209"
></A
><P
>A <SPAN
CLASS="PRODUCTNAME"
>Slony-I</SPAN
> Node is a named <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> database that will be
participating in replication.</P
><P
>It is defined, near the beginning of each Slonik script, using the directive:</P
><PRE
CLASS="PROGRAMLISTING"
> NODE 1 ADMIN CONNINFO = 'dbname=testdb host=server1 user=slony';</PRE
><P
>The <A
HREF="admconninfo.html"
>SLONIK ADMIN CONNINFO</A
> information indicates database
connection information that will ultimately be passed to the
<CODE
CLASS="FUNCTION"
>PQconnectdb()</CODE
> libpq function.</P
><P
>Thus, a <SPAN
CLASS="PRODUCTNAME"
>Slony-I</SPAN
> cluster consists of:</P
><P
></P
><UL
><LI
><P
> A cluster name</P
></LI
><LI
><P
> A set of <SPAN
CLASS="PRODUCTNAME"
>Slony-I</SPAN
> nodes, each of which has a namespace based on that cluster name</P
></LI
></UL
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN227"
>1.3.3. Replication Set</A
></H2
><A
NAME="AEN229"
></A
><P
>A replication set is defined as a set of tables and sequences
that are to be replicated between nodes in a <SPAN
CLASS="PRODUCTNAME"
>Slony-I</SPAN
> cluster.</P
><P
>You may have several sets, and the <SPAN
CLASS="QUOTE"
>"flow"</SPAN
> of
replication does not need to be identical between those sets.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN235"
>1.3.4. Origin, Providers and Subscribers</A
></H2
><A
NAME="AEN237"
></A
><A
NAME="AEN239"
></A
><P
>Each replication set has some origin node, which is the
<SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>only</I
></SPAN
> place where user applications are permitted
to modify data in the tables that are being replicated.  This might
also be termed the <SPAN
CLASS="QUOTE"
>"master provider"</SPAN
>; it is the main
place from which data is provided.</P
><A
NAME="AEN244"
></A
><P
>Other nodes in the cluster subscribe to the replication set,
indicating that they want to receive the data.</P
><P
>The origin node will never be considered a
<SPAN
CLASS="QUOTE"
>"subscriber."</SPAN
> (Ignoring the case where the cluster is
reshaped, and the origin is expressly shifted to another node.)  But
<SPAN
CLASS="PRODUCTNAME"
>Slony-I</SPAN
> supports the notion of cascaded subscriptions, that is, a
node that is subscribed to some set may also behave as a
<SPAN
CLASS="QUOTE"
>"provider"</SPAN
> to other nodes in the cluster for that
replication set.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN251"
>1.3.5. slon Daemon</A
></H2
><A
NAME="AEN253"
></A
><P
>For each node in the cluster, there will be a <A
HREF="slon.html"
><SPAN
CLASS="APPLICATION"
>slon</SPAN
></A
> process to manage replication activity for that node.</P
><P
> <A
HREF="slon.html"
><SPAN
CLASS="APPLICATION"
>slon</SPAN
></A
> is a program implemented in C that
processes replication events.  There are two main sorts of events:</P
><P
></P
><UL
><LI
><P
> Configuration events</P
><P
> These normally occur when a <A
HREF="slonik.html"
><SPAN
CLASS="APPLICATION"
>slonik</SPAN
></A
> script is
run, and submit updates to the configuration of the cluster. </P
></LI
><LI
><P
> <TT
CLASS="COMMAND"
>SYNC</TT
> events </P
><P
> Updates to the tables that are replicated are grouped together
into <TT
CLASS="COMMAND"
>SYNC</TT
>s; these groups of transactions are
applied together to the subscriber nodes.  </P
></LI
></UL
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN269"
>1.3.6. slonik Configuration Processor</A
></H2
><A
NAME="AEN271"
></A
><P
> The <A
HREF="slonik.html"
><SPAN
CLASS="APPLICATION"
>slonik</SPAN
></A
> command processor processes scripts
in a <SPAN
CLASS="QUOTE"
>"little language"</SPAN
> that are used to submit events to
update the configuration of a <SPAN
CLASS="PRODUCTNAME"
>Slony-I</SPAN
> cluster.  This includes such
things as adding and removing nodes, modifying communications paths,
adding or removing subscriptions.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="PLAINPATHS"
>1.3.7. <SPAN
CLASS="PRODUCTNAME"
>Slony-I</SPAN
> Path Communications</A
></H2
><A
NAME="AEN280"
></A
><P
> <SPAN
CLASS="PRODUCTNAME"
>Slony-I</SPAN
> uses <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> DSNs in three contexts to establish
access to databases:

<P
></P
></P><UL
><LI
><P
> <A
HREF="admconninfo.html"
>SLONIK ADMIN CONNINFO</A
> - controlling how a
<A
HREF="slonik.html"
><SPAN
CLASS="APPLICATION"
>slonik</SPAN
></A
> script accesses the various nodes.</P
><P
> These connections are the ones that go from your
<SPAN
CLASS="QUOTE"
>"administrative workstation"</SPAN
> to all of the nodes in a <SPAN
CLASS="PRODUCTNAME"
>Slony-I</SPAN
>
cluster.</P
><P
> It is <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>vital</I
></SPAN
> that you have connections from the
central location where you run <A
HREF="slonik.html"
><SPAN
CLASS="APPLICATION"
>slonik</SPAN
></A
> 
to each and every node in the network.  These connections are only
used briefly, to submit the few <ACRONYM
CLASS="ACRONYM"
>SQL</ACRONYM
> requests required to
control the administration of the cluster.</P
><P
> Since these communications paths are only used briefly, it may
be quite reasonable to <SPAN
CLASS="QUOTE"
>"hack together"</SPAN
> temporary
connections using SSH tunnelling.</P
></LI
><LI
><P
> The <A
HREF="slon.html"
><SPAN
CLASS="APPLICATION"
>slon</SPAN
></A
> DSN parameter. </P
><P
> The DSN parameter passed to each <A
HREF="slon.html"
><SPAN
CLASS="APPLICATION"
>slon</SPAN
></A
> indicates what network
path should be used to get from the <A
HREF="slon.html"
><SPAN
CLASS="APPLICATION"
>slon</SPAN
></A
> process to the database
that it manages.</P
></LI
><LI
><P
> <A
HREF="stmtstorepath.html"
>SLONIK STORE
     PATH</A
> - controlling how
<A
HREF="slon.html"
><SPAN
CLASS="APPLICATION"
>slon</SPAN
></A
> daemons communicate with remote nodes.  These paths are stored
in <A
HREF="table.sl-path.html"
>sl_path</A
>.</P
><P
> You forcibly <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>need</I
></SPAN
> to have a path between
each subscriber node and its provider; other paths are optional, and
will not be used unless a listen path in <A
HREF="table.sl-listen.html"
>sl_listen</A
>. is needed that uses that particular
path.</P
></LI
></UL
><P></P
><P
> The distinctions and possible complexities of paths are not
normally an issue for people with simple networks where all the hosts
can see one another via a comparatively <SPAN
CLASS="QUOTE"
>"global"</SPAN
> set of
network addresses.  In contrast, it matters rather a lot for those
with complex firewall configurations, nodes at multiple locations, and
the issue where nodes may not be able to all talk to one another via a
uniform set of network addresses.</P
><P
> Consider the attached diagram, which describes a set of six
nodes

<SPAN
CLASS="INLINEMEDIAOBJECT"
><IMG
SRC="complexenv.png"></SPAN
></P
><P
></P
><UL
><LI
><P
> DB1 and DB2 are databases residing in a secure
<SPAN
CLASS="QUOTE"
>"database layer,"</SPAN
> firewalled against outside access
except from specifically controlled locations.</P
><P
> Let's suppose that DB1 is the origin node for the replication
system.</P
></LI
><LI
><P
> DB3 resides in a <SPAN
CLASS="QUOTE"
>"DMZ"</SPAN
> at the same site;
it is intended to be used as a <SPAN
CLASS="PRODUCTNAME"
>Slony-I</SPAN
> <SPAN
CLASS="QUOTE"
>"provider"</SPAN
> for
remote locations.</P
></LI
><LI
><P
> DB4 is a counterpart to DB3 in a <SPAN
CLASS="QUOTE"
>"DMZ"</SPAN
>
at a secondary/failover site.  Its job, in the present configuration,
is to <SPAN
CLASS="QUOTE"
>"feed"</SPAN
> servers in the secure database layers at the
secondary site.</P
></LI
><LI
><P
> DB5 and DB6 are counterparts to DB1 and DB2, but
are, at present, configured as subscribers.</P
><P
> Supposing disaster were to strike at the <SPAN
CLASS="QUOTE"
>"primary"</SPAN
>
site, the secondary site would be well-equipped to take over servicing
the applications that use this data.</P
></LI
><LI
><P
> The symmetry of the configuration means that if you
had <SPAN
CLASS="emphasis"
><I
CLASS="EMPHASIS"
>two</I
></SPAN
> transactional applications needing
protection from failure, it would be straightforward to have
additional replication sets so that each site is normally
<SPAN
CLASS="QUOTE"
>"primary"</SPAN
> for one application, and where destruction of
one site could be addressed by consolidating services at the remaining
site.</P
></LI
></UL
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN343"
>1.3.8. SSH tunnelling</A
></H2
><P
>If a direct connection to <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> can not be established because of a 
firewall then you can establish an ssh tunnel that <SPAN
CLASS="PRODUCTNAME"
>Slony-I</SPAN
> can operate
over. </P
><P
>SSH tunnels can be configured by passing the <TT
CLASS="OPTION"
>w</TT
> to SSH.
This enables  forwarding <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> traffic where a local port is forwarded 
across a connection, encrypted and compressed, using 
<SPAN
CLASS="APPLICATION"
>SSH</SPAN
></P
><P
> See the  <SPAN
CLASS="APPLICATION"
>ssh</SPAN
> documentation for details on how to configure and use SSH tunnels.</P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="requirements.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="limitations.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>System Requirements</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="preface.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Current Limitations</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
slony1-2-doc 2.2.3-1 / usr / share / doc / slony1-2-doc / adminguide / concepts.html
