Mon Jan 24 18:41:34 PST 2005
- Previous message: [Slony1-commit] By cbbrowne: Plenty of modifications to documentation; lots of textual
- Next message: [Slony1-commit] By cbbrowne: Added in stored function for generating SYNC events
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Log Message:
-----------
Apply changes from CVS HEAD admin guide into the stable branch as this
material will be useful for both versions
Modified Files:
--------------
slony1-engine/doc/adminguide:
README (r1.1 -> r1.2)
Removed Files:
-------------
slony1-engine/doc/adminguide:
addthings.html
altperl.html
app-slon.html
app-slonik.html
cluster.html
concepts.html
ddlchanges.html
definingsets.html
dropthings.html
failover.html
faq.html
firstdb.html
help.html
installation.html
listenpaths.html
maintenance.html
monitoring.html
requirements.html
reshape.html
slonconfig.html
slonik.html
slonstart.html
slony-commands.html
slony.html
slonyadmin.html
slonyintro.html
subscribenodes.html
t24.html
x267.html
x931.html
-------------- next part --------------
--- doc/adminguide/reshape.html
+++ /dev/null
@@ -1,235 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
-<HTML
-><HEAD
-><TITLE
->Reshaping a Cluster</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
-REV="MADE"
-HREF="mailto:cbbrowne at gmail.com"><LINK
-REL="HOME"
-TITLE="Slony-I 1.1 Administration"
-HREF="slony.html"><LINK
-REL="UP"
-HREF="slonyadmin.html"><LINK
-REL="PREVIOUS"
-TITLE="Slony-I Maintenance"
-HREF="maintenance.html"><LINK
-REL="NEXT"
-TITLE="Doing switchover and failover with Slony-I"
-HREF="failover.html"><LINK
-REL="STYLESHEET"
-TYPE="text/css"
-HREF="stdstyle.css"><META
-HTTP-EQUIV="Content-Type"></HEAD
-><BODY
-CLASS="SECT1"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->Slony-I 1.1 Administration</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="maintenance.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="failover.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="RESHAPE"
->6. Reshaping a Cluster</A
-></H1
-><P
->If you rearrange the nodes so that they serve different
-purposes, this will likely lead to the subscribers changing a bit. </P
-><P
->This will require doing several things:
-<P
-></P
-><UL
-><LI
-><P
-> If you want a node that is a subscriber to become the
-origin for a particular replication set, you will have to issue a
-suitable <A
-HREF="app-slonik.html#SLONIK"
-> slonik </A
-> <TT
-CLASS="COMMAND"
->MOVE SET</TT
->
-operation. </P
-></LI
-><LI
-><P
-> You may subsequently, or instead, wish to modify the
-subscriptions of other nodes. You might want to modify a node to get
-its data from a different provider, or to change it to turn forwarding
-on or off. This can be accomplished by issuing the slonik
-<TT
-CLASS="COMMAND"
->SUBSCRIBE SET</TT
-> operation with the new subscription
-information for the node; <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> will change the
-configuration. </P
-></LI
-><LI
-><P
-> If the directions of data flows have changed, it is
-doubtless appropriate to issue a set of <TT
-CLASS="COMMAND"
->DROP LISTEN</TT
->
-operations to drop out obsolete paths between nodes and <TT
-CLASS="COMMAND"
->SET
-LISTEN</TT
-> to add the new ones. At present, this is not changed
-automatically; at some point, <TT
-CLASS="COMMAND"
->MOVE SET</TT
-> and
-<TT
-CLASS="COMMAND"
->SUBSCRIBE SET</TT
-> might change the paths as a side-effect. See
-<A
-HREF="listenpaths.html"
-> Slony Listen Paths </A
-> for more
-information about this. In version 1.1 and later, it is likely that
-the generation of sl_listen entries will be entirely automated, where
-they will be regenerated when changes are made to sl_path or
-sl_subscribe, thereby making it unnecessary to even think about
-<TT
-CLASS="COMMAND"
->SET LISTEN</TT
->. </P
-></LI
-></UL
-> </P
-><P
-> The <TT
-CLASS="FILENAME"
->altperl</TT
-> toolset includes a
-<B
-CLASS="APPLICATION"
->init_cluster.pl</B
-> script that is quite up to the task of
-creating the new <TT
-CLASS="COMMAND"
->SET LISTEN</TT
-> commands; it isn't, however,
-smart enough to know what listener paths should be dropped.</P
-></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="maintenance.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slony.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="failover.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Slony-I Maintenance</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slonyadmin.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Doing switchover and failover with Slony-I</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/requirements.html
+++ /dev/null
@@ -1,585 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->System Requirements</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
-REV="MADE"
-HREF="mailto:slony1-general at gborg.postgresql.org"><LINK
-REL="HOME"
-TITLE="Slony-I HEAD_20041221 Documentation"
-HREF="index.html"><LINK
-REL="UP"
-TITLE="Slony-I Introduction"
-HREF="slonyintro.html"><LINK
-REL="PREVIOUS"
-TITLE=" Slony-I Communications
-Costs"
-HREF="slonylistenercosts.html"><LINK
-REL="NEXT"
-TITLE="Slony-I Installation"
-HREF="installation.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="2004-12-22T22:53:46"></HEAD
-><BODY
-CLASS="ARTICLE"
-><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
-> HEAD_20041221 Documentation</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="slonylistenercosts.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="introduction.html"
->Fast Backward</A
-></TD
-><TD
-WIDTH="60%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="installation.html"
->Fast Forward</A
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="installation.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="ARTICLE"
-><DIV
-CLASS="TITLEPAGE"
-><H1
-CLASS="TITLE"
-><A
-NAME="REQUIREMENTS"
->System Requirements</A
-></H1
-><HR></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="AEN113"
->1. System Requirements</A
-></H1
-><P
->Any platform that can run
-PostgreSQL should be able to run
-<SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
->.</P
-><P
->The platforms that have received specific testing at the time of
-this release are FreeBSD-4X-i368, FreeBSD-5X-i386, FreeBSD-5X-alpha,
-osX-10.3, Linux-2.4X-i386 Linux-2.6X-i386 Linux-2.6X-amd64,
-<SPAN
-CLASS="TRADEMARK"
->Solaris</SPAN
->™-2.8-SPARC, <SPAN
-CLASS="TRADEMARK"
->Solaris</SPAN
->™-2.9-SPARC, AIX 5.1
-and OpenBSD-3.5-sparc64.</P
-><P
->There have been reports of success at running
-<SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> hosts that are running PostgreSQL
-on Microsoft <SPAN
-CLASS="TRADEMARK"
->Windows</SPAN
->™. At this time, the
-<SPAN
-CLASS="QUOTE"
->"binary"</SPAN
-> applications (<SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->e.g.</I
-></SPAN
-> -
-<SPAN
-CLASS="APPLICATION"
-><A
-HREF="app-slonik.html#SLONIK"
->slonik</A
-></SPAN
->,
-<SPAN
-CLASS="APPLICATION"
-><A
-HREF="app-slon.html#SLON"
->slon</A
-></SPAN
->) do not
-run on <SPAN
-CLASS="TRADEMARK"
->Windows</SPAN
->™, but a <SPAN
-CLASS="APPLICATION"
-><A
-HREF="app-slon.html#SLON"
->slon</A
-></SPAN
-> running on one of the
-Unix-like systems has no reason to have difficulty connect to a
-PostgreSQL instance running on <SPAN
-CLASS="TRADEMARK"
->Windows</SPAN
->™.</P
-><P
-> It ought to be possible to port <SPAN
-CLASS="APPLICATION"
-><A
-HREF="app-slon.html#SLON"
-> slon </A
-></SPAN
-> and <SPAN
-CLASS="APPLICATION"
-><A
-HREF="app-slonik.html#SLONIK"
-> slonik </A
-></SPAN
-> to run on
-<SPAN
-CLASS="TRADEMARK"
->Windows</SPAN
->™; the conspicuous challenge is of having
-a POSIX-like <TT
-CLASS="FILENAME"
->pthreads</TT
-> implementation for
-<SPAN
-CLASS="APPLICATION"
-><A
-HREF="app-slon.html#SLON"
-> slon </A
-></SPAN
->, as it
-uses that to have multiple threads of execution. There are reports of
-there being a <TT
-CLASS="FILENAME"
->pthreads</TT
-> library for
-<SPAN
-CLASS="TRADEMARK"
->Windows</SPAN
->™, so nothing should prevent some
-interested party from volunteering to do the port.</P
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN144"
->1.1. Software needed</A
-></H2
-><P
-><P
-></P
-></P><UL
-><LI
-><P
-> GNU make. Other make programs will not work. GNU
-make is often installed under the name <TT
-CLASS="COMMAND"
->gmake</TT
->; this
-document will therefore always refer to it by that name. (On
-Linux-based systems GNU make is typically the default make, and is
-called <TT
-CLASS="COMMAND"
->make</TT
->) To test to see if your make is GNU
-make enter <TT
-CLASS="COMMAND"
->make version</TT
->. Version 3.76 or later
-will suffice; previous versions may not.</P
-></LI
-><LI
-><P
-> You need an ISO/ANSI C compiler. Recent versions of
-<SPAN
-CLASS="APPLICATION"
->GCC</SPAN
-> work.</P
-></LI
-><LI
-><P
-> You also need a recent version of PostgreSQL
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->source</I
-></SPAN
->. <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
->
-depends on namespace support so you must have PostgreSQL version 7.3.3 or newer
-to be able to build and use <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
->. Rod
-Taylor has <SPAN
-CLASS="QUOTE"
->"hacked up"</SPAN
-> a version of
-<SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> that works with version 7.2; if you
-desperately need that, look for him on the PostgreSQL Hackers mailing
-list. It is not anticipated that 7.2 will be supported by any
-official <SPAN
-CLASS="APPLICATION"
-><SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-></SPAN
->
-release.</P
-></LI
-><LI
-><P
-> GNU packages may be included in the standard
-packaging for your operating system, or you may need to look for
-source code at your local GNU mirror (see <A
-HREF="http://www.gnu.org/order/ftp.html"
-TARGET="_top"
->http://www.gnu.org/order/ftp.html </A
-> for a list) or at <A
-HREF="ftp://ftp.gnu.org/gnu"
-TARGET="_top"
-> ftp://ftp.gnu.org/gnu </A
-> .)</P
-></LI
-><LI
-><P
-> If you need to obtain PostgreSQL source, you can
-download it from your favorite PostgreSQL mirror. See <A
-HREF="http://www.postgresql.org/mirrors-www.html"
-TARGET="_top"
->http://www.postgresql.org/mirrors-www.html </A
-> for a list.</P
-></LI
-></UL
-><P></P
-><P
->Also check to make sure you have sufficient disk space. You
-will need approximately 5MB for the source tree during build and
-installation.</P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN173"
->1.2. Getting <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
->Source</A
-></H2
-><P
->You can get the <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> source from
-<A
-HREF="http://developer.postgresql.org/~wieck/slony1/download/"
-TARGET="_top"
->http://developer.postgresql.org/~wieck/slony1/download/</A
-></P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN179"
->1.3. Time Synchronization</A
-></H2
-><P
-> All the servers used within the replication cluster need to
-have their Real Time Clocks in sync. This is to ensure that slon
-doesn't error with messages indicating that slave is already ahead of
-the master during replication. We recommend you have ntpd running on
-all nodes, with subscriber nodes using the <SPAN
-CLASS="QUOTE"
->"master"</SPAN
->
-provider node as their time server.</P
-><P
-> It is possible for <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> to
-function even in the face of there being some time discrepancies, but
-having systems <SPAN
-CLASS="QUOTE"
->"in sync"</SPAN
-> is usually pretty important for
-distributed applications.</P
-><P
-> See <A
-HREF="http://www.ntp.org/"
-TARGET="_top"
-> www.ntp.org </A
-> for
-more details about NTP (Network Time Protocol).</P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN188"
->1.4. Network Connectivity</A
-></H2
-><P
->It is necessary that the hosts that are to replicate between one
-another have <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->bidirectional</I
-></SPAN
-> network communications
-to the PostgreSQL instances. That is, if node B is replicating data
-from node A, it is necessary that there be a path from A to B and from
-B to A. It is recommended that all nodes in a
-<SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> cluster allow this sort of
-bidirection communications from any node in the cluster to any other
-node in the cluster.</P
-><P
->Note that the network addresses need to be consistent across all
-of the nodes. Thus, if there is any need to use a
-<SPAN
-CLASS="QUOTE"
->"public"</SPAN
-> address for a node, to allow remote/VPN access,
-that <SPAN
-CLASS="QUOTE"
->"public"</SPAN
-> address needs to be able to be used
-consistently throughout the <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
->
-cluster, as the address is propagated throughout the cluster in table
-<TT
-CLASS="ENVAR"
->sl_path</TT
->.</P
-><P
->A possible workaround for this, in environments where firewall
-rules are particularly difficult to implement, may be to establish SSH
-Tunnels that are created on each host that allow remote access through
-IP address 127.0.0.1, with a different port for each destination.</P
-><P
-> Note that <SPAN
-CLASS="APPLICATION"
->slonik</SPAN
-> and the
-<SPAN
-CLASS="APPLICATION"
->slon</SPAN
-> instances need no special connections
-or protocols to communicate with one another; they just need to be
-able to get access to the <SPAN
-CLASS="APPLICATION"
->PostgreSQL</SPAN
->
-databases, connecting as a <SPAN
-CLASS="QUOTE"
->"superuser"</SPAN
->.</P
-><P
-> An implication of the communications model is that the entire
-extended network in which a <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> cluster
-operates must be able to be treated as being secure. If there is a
-remote location where you cannot trust the
-<SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> node to be considered
-<SPAN
-CLASS="QUOTE"
->"secured,"</SPAN
-> this represents a vulnerability that adversely
-the security of the entire cluster. In effect, the security policies
-throughout the cluster can only be considered as stringent as those
-applied at the <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->weakest</I
-></SPAN
-> link. Running a
-full-blown <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> node at a branch
-location that can't be kept secure compromises security for the
-cluster.</P
-><P
->In the future plans is a feature whereby updates for a
-particular replication set would be serialized via a scheme called
-<SPAN
-CLASS="QUOTE"
->"log shipping."</SPAN
-> The data stored in sl_log_1 and sl_log_2
-would be written out to log files on disk. These files could be
-transmitted in any manner desired, whether via scp, FTP, burning them
-onto DVD-ROMs and mailing them, or even by recording them on a USB
-<SPAN
-CLASS="QUOTE"
->"flash device"</SPAN
-> and attaching them to birds, allowing a
-sort of <SPAN
-CLASS="QUOTE"
->"avian transmission protocol."</SPAN
-> This will allow
-one way communications so that <SPAN
-CLASS="QUOTE"
->"subscribers"</SPAN
-> that use log
-shipping would have no need for access to other
-<SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> nodes.</P
-></DIV
-></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="slonylistenercosts.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="installation.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-><SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> Communications
-Costs</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slonyintro.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Slony-I Installation</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/maintenance.html
+++ /dev/null
@@ -1,335 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
-<HTML
-><HEAD
-><TITLE
->Slony-I Maintenance</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
-REV="MADE"
-HREF="mailto:cbbrowne at gmail.com"><LINK
-REL="HOME"
-TITLE="Slony-I 1.1 Administration"
-HREF="slony.html"><LINK
-REL="UP"
-HREF="slonyadmin.html"><LINK
-REL="PREVIOUS"
-TITLE="Monitoring"
-HREF="monitoring.html"><LINK
-REL="NEXT"
-TITLE="Reshaping a Cluster"
-HREF="reshape.html"><LINK
-REL="STYLESHEET"
-TYPE="text/css"
-HREF="stdstyle.css"><META
-HTTP-EQUIV="Content-Type"></HEAD
-><BODY
-CLASS="SECT1"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->Slony-I 1.1 Administration</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="monitoring.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="reshape.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="MAINTENANCE"
->5. Slony-I Maintenance</A
-></H1
-><P
-><SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> actually does most of its necessary
-maintenance itself, in a <SPAN
-CLASS="QUOTE"
->"cleanup"</SPAN
-> thread:
-
-<P
-></P
-><UL
-><LI
-><P
-> Deletes old data from various tables in the
-<SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> cluster's namespace, notably entries in
-sl_log_1, sl_log_2 (not yet used), and sl_seqlog. </P
-></LI
-><LI
-><P
-> Vacuum certain tables used by <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
->.
-As of 1.0.5, this includes pg_listener; in earlier versions, you must
-vacuum that table heavily, otherwise you'll find replication slowing
-down because <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> raises plenty of events, which
-leads to that table having plenty of dead tuples. </P
-><P
-> In some versions (1.1, for sure; possibly 1.0.5) there is the
-option of not bothering to vacuum any of these tables if you are using
-something like <B
-CLASS="APPLICATION"
->pg_autovacuum</B
-> to handle vacuuming of
-these tables. Unfortunately, it has been quite possible for
-<B
-CLASS="APPLICATION"
->pg_autovacuum</B
-> to not vacuum quite frequently enough, so
-you probably want to use the internal vacuums. Vacuuming pg_listener
-"too often" isn't nearly as hazardous as not vacuuming it frequently
-enough. </P
-><P
->Unfortunately, if you have long-running transactions, vacuums
-cannot clear out dead tuples that are newer than the eldest
-transaction that is still running. This will most notably lead to
-pg_listener growing large and will slow replication.</P
-></LI
-></UL
-> </P
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN748"
->5.1. Watchdogs: Keeping Slons Running</A
-></H2
-><P
->There are a couple of <SPAN
-CLASS="QUOTE"
->"watchdog"</SPAN
-> scripts available that
-monitor things, and restart the <B
-CLASS="APPLICATION"
->slon</B
-> processes should
-they happen to die for some reason, such as a network <SPAN
-CLASS="QUOTE"
->"glitch"</SPAN
->
-that causes loss of connectivity. </P
-><P
->You might want to run them... </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN755"
->5.2. Alternative to Watchdog: generate_syncs.sh</A
-></H2
-><P
->A new script for <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> 1.1 is
-<B
-CLASS="APPLICATION"
->generate_syncs.sh</B
->, which addresses the following kind of
-situation. </P
-><P
->Supposing you have some possibly-flakey server where the <B
-CLASS="APPLICATION"
->slon</B
->
-daemon that might not run all the time, you might return from a
-weekend away only to discover the following situation... </P
-><P
->On Friday night, something went <SPAN
-CLASS="QUOTE"
->"bump"</SPAN
-> and while the
-database came back up, none of the <B
-CLASS="APPLICATION"
->slon</B
-> daemons
-survived. Your online application then saw nearly three days worth of
-reasonably heavy transaction load. </P
-><P
->When you restart slon on Monday, it hasn't done a SYNC on the
-master since Friday, so that the next <SPAN
-CLASS="QUOTE"
->"SYNC set"</SPAN
-> comprises all
-of the updates between Friday and Monday. Yuck. </P
-><P
->If you run <B
-CLASS="APPLICATION"
->generate_syncs.sh</B
-> as a cron job every 20 minutes, it
-will force in a periodic SYNC on the origin, which means that
-between Friday and Monday, the numerous updates are split into more
-than 100 syncs, which can be applied incrementally, making the cleanup
-a lot less unpleasant. </P
-><P
->Note that if SYNCs <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->are</I
-></SPAN
-> running regularly,
-this script won't bother doing anything. </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN771"
->5.3. Log Files</A
-></H2
-><P
-><A
-HREF="app-slon.html#SLON"
-> <B
-CLASS="APPLICATION"
->slon</B
-> </A
-> daemons
-generate some more-or-less verbose log files, depending on what
-debugging level is turned on. You might assortedly wish to:
-
-<P
-></P
-><UL
-><LI
-><P
-> Use a log rotator like <SPAN
-CLASS="PRODUCTNAME"
->Apache</SPAN
->
-<B
-CLASS="APPLICATION"
->rotatelogs</B
-> to have a sequence of log files so that no
-one of them gets too big; </P
-></LI
-><LI
-><P
-> Purge out old log files, periodically.</P
-></LI
-></UL
-></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="monitoring.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slony.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="reshape.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Monitoring</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slonyadmin.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Reshaping a Cluster</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/monitoring.html
+++ /dev/null
@@ -1,226 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
-<HTML
-><HEAD
-><TITLE
->Monitoring</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
-REV="MADE"
-HREF="mailto:cbbrowne at gmail.com"><LINK
-REL="HOME"
-TITLE="Slony-I 1.1 Administration"
-HREF="slony.html"><LINK
-REL="UP"
-HREF="slonyadmin.html"><LINK
-REL="PREVIOUS"
-TITLE=" Subscribing Nodes"
-HREF="subscribenodes.html"><LINK
-REL="NEXT"
-TITLE="Slony-I Maintenance"
-HREF="maintenance.html"><LINK
-REL="STYLESHEET"
-TYPE="text/css"
-HREF="stdstyle.css"><META
-HTTP-EQUIV="Content-Type"></HEAD
-><BODY
-CLASS="SECT1"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->Slony-I 1.1 Administration</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="subscribenodes.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="maintenance.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="MONITORING"
->4. Monitoring</A
-></H1
-><P
->Here are some of things that you may find in your
-<SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> logs, and explanations of what they mean. </P
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN721"
->4.1. CONFIG notices</A
-></H2
-><P
->These entries are pretty straightforward. They are informative
-messages about your configuration. </P
-><P
->Here are some typical entries that you will probably run into in
-your logs:
-
-<TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="100%"
-><TR
-><TD
-><PRE
-CLASS="SCREEN"
-> CONFIG main: local node id = 1
- CONFIG main: loading current cluster configuration
- CONFIG storeNode: no_id=3 no_comment='Node 3'
- CONFIG storePath: pa_server=5 pa_client=1 pa_conninfo="host=127.0.0.1 dbname=foo user=postgres port=6132" pa_connretry=10
- CONFIG storeListen: li_origin=3 li_receiver=1 li_provider=3
- CONFIG storeSet: set_id=1 set_origin=1 set_comment='Set 1'
- CONFIG main: configuration complete - starting threads</PRE
-></TD
-></TR
-></TABLE
-> </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN726"
->4.2. DEBUG Notices</A
-></H2
-><P
->Debug notices are always prefaced by the name of the thread that
-the notice originates from. You will see messages from the following
-threads:
-
-<TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="100%"
-><TR
-><TD
-><PRE
-CLASS="SCREEN"
-> localListenThread: This is the local thread that listens for events on the local node.
- remoteWorkerThread_X: The thread processing remote events.
- remoteListenThread_X: Listens for events on a remote node database.
- cleanupThread: Takes care of things like vacuuming, cleaning out the confirm and event tables, and deleting logs.
- syncThread: Generates sync events.</PRE
-></TD
-></TR
-></TABLE
-> </P
-><P
-> WriteMe: I can't decide the format for the rest of this. I
-think maybe there should be a "how it works" page, explaining more
-about how the threads work, what to expect in the logs after you run a
-slonik command... </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="subscribenodes.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slony.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="maintenance.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Subscribing Nodes</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slonyadmin.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Slony-I Maintenance</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/slonyintro.html
+++ /dev/null
@@ -1,308 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->Slony-I Introduction</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
-REV="MADE"
-HREF="mailto:slony1-general at gborg.postgresql.org"><LINK
-REL="HOME"
-TITLE="Slony-I HEAD_20041221 Documentation"
-HREF="index.html"><LINK
-REL="PREVIOUS"
-TITLE="Slony-I HEAD_20041221 Documentation"
-HREF="index.html"><LINK
-REL="NEXT"
-TITLE="Introduction to Slony-I"
-HREF="introduction.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="2004-12-22T22:53:46"></HEAD
-><BODY
-CLASS="PART"
-><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
-> HEAD_20041221 Documentation</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="index.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="index.html#AEN4"
->Fast Backward</A
-></TD
-><TD
-WIDTH="60%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="commandreferencec.html"
->Fast Forward</A
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="introduction.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="PART"
-><A
-NAME="SLONYINTRO"
-></A
-><DIV
-CLASS="TITLEPAGE"
-><H1
-CLASS="TITLE"
->I. <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> Introduction</H1
-><DIV
-CLASS="TOC"
-><DL
-><DT
-><B
->Table of Contents</B
-></DT
-><DT
-><A
-HREF="introduction.html"
->Introduction to <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-></A
-></DT
-><DD
-><DL
-><DT
->1. <A
-HREF="introduction.html#AEN31"
->Why yet another replication system?</A
-></DT
-><DT
->2. <A
-HREF="x35.html"
->What <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> is</A
-></DT
-><DT
->3. <A
-HREF="x51.html"
-><SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> is not</A
-></DT
-><DT
->4. <A
-HREF="x64.html"
->Why doesn't <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> do automatic fail-over/promotion?</A
-></DT
-><DT
->5. <A
-HREF="x72.html"
->Current Limitations</A
-></DT
-><DT
->6. <A
-HREF="slonylistenercosts.html"
-><SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> Communications
-Costs</A
-></DT
-></DL
-></DD
-><DT
-><A
-HREF="requirements.html"
->System Requirements</A
-></DT
-><DD
-><DL
-><DT
->1. <A
-HREF="requirements.html#AEN113"
->System Requirements</A
-></DT
-></DL
-></DD
-><DT
-><A
-HREF="installation.html"
->Slony-I Installation</A
-></DT
-><DD
-><DL
-><DT
->1. <A
-HREF="installation.html#AEN218"
->Slony-I Installation</A
-></DT
-><DT
->2. <A
-HREF="x225.html"
->Short Version</A
-></DT
-><DT
->3. <A
-HREF="x229.html"
->Configuration</A
-></DT
-><DT
->4. <A
-HREF="x238.html"
->Example</A
-></DT
-><DT
->5. <A
-HREF="x244.html"
->Build</A
-></DT
-><DT
->6. <A
-HREF="x253.html"
->Installing Slony-I</A
-></DT
-><DT
->7. <A
-HREF="concepts.html"
-><SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> Concepts</A
-></DT
-><DT
->8. <A
-HREF="cluster.html"
->Defining Slony-I Clusters</A
-></DT
-><DT
->9. <A
-HREF="definingsets.html"
->Defining Slony-I Replication Sets</A
-></DT
-></DL
-></DD
-></DL
-></DIV
-></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="index.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="introduction.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-><SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> HEAD_20041221 Documentation</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-> </TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Introduction to <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-></TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/faq.html
+++ /dev/null
@@ -1,176 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->Slony-I FAQ</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
-REV="MADE"
-HREF="mailto:slony1-general at gborg.postgresql.org"><LINK
-REL="HOME"
-TITLE="Slony-I HEAD_20041221 Documentation"
-HREF="index.html"><LINK
-REL="PREVIOUS"
-HREF="t2563.html"><LINK
-REL="NEXT"
-HREF="t2593.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="2004-12-22T22:53:46"></HEAD
-><BODY
-CLASS="PART"
-><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
-> HEAD_20041221 Documentation</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="t2563.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="slonyadmin.html"
->Fast Backward</A
-></TD
-><TD
-WIDTH="60%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="developer.html"
->Fast Forward</A
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="t2593.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="PART"
-><A
-NAME="FAQ"
-></A
-><DIV
-CLASS="TITLEPAGE"
-><H1
-CLASS="TITLE"
->IV. Slony-I FAQ</H1
-><DIV
-CLASS="TOC"
-><DL
-><DT
-><B
->Table of Contents</B
-></DT
-><DT
-><A
-HREF="t2593.html"
-></A
-></DT
-></DL
-></DIV
-></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="t2563.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="t2593.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-> </TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-></TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/x931.html
+++ /dev/null
@@ -1,160 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
-<HTML
-><HEAD
-><TITLE
-> Other Information Sources</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
-REV="MADE"
-HREF="mailto:cbbrowne at gmail.com"><LINK
-REL="HOME"
-TITLE="Slony-I 1.1 Administration"
-HREF="slony.html"><LINK
-REL="UP"
-HREF="t24.html"><LINK
-REL="PREVIOUS"
-TITLE=" More Slony-I Help "
-HREF="help.html"><LINK
-REL="NEXT"
-HREF="faq.html"><LINK
-REL="STYLESHEET"
-TYPE="text/css"
-HREF="stdstyle.css"><META
-HTTP-EQUIV="Content-Type"></HEAD
-><BODY
-CLASS="SECT1"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->Slony-I 1.1 Administration</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="help.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="faq.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="AEN931"
->22. Other Information Sources</A
-></H1
-><P
-></P
-><UL
-><LI
-><P
-> <A
-HREF="http://comstar.dotgeek.org/postgres/slony-config/"
-TARGET="_top"
-> slony-config</A
-> - A Perl tool for configuring Slony nodes using config files in an XML-based format that the tool transforms into a Slonik script </P
-></LI
-></UL
-></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="help.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slony.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="faq.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->More Slony-I Help</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="t24.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-></TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/help.html
+++ /dev/null
@@ -1,235 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
-<HTML
-><HEAD
-><TITLE
-> More Slony-I Help </TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
-REV="MADE"
-HREF="mailto:cbbrowne at gmail.com"><LINK
-REL="HOME"
-TITLE="Slony-I 1.1 Administration"
-HREF="slony.html"><LINK
-REL="UP"
-HREF="slonyadmin.html"><LINK
-REL="PREVIOUS"
-TITLE="Replicating Your First Database"
-HREF="firstdb.html"><LINK
-REL="NEXT"
-TITLE="Slony-I FAQ"
-HREF="faq.html"><LINK
-REL="STYLESHEET"
-TYPE="text/css"
-HREF="stdstyle.css"><META
-HTTP-EQUIV="Content-Type"></HEAD
-><BODY
-CLASS="SECT1"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->Slony-I 1.1 Administration</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="firstdb.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="faq.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="HELP"
->13. More Slony-I Help</A
-></H1
-><P
->If you are having problems with Slony-I, you have several
-options for help:
-
-<P
-></P
-><UL
-><LI
-><P
-> <A
-HREF="http://slony.info/"
-TARGET="_top"
->http://slony.info/</A
-> - the official
-"home" of Slony</P
-></LI
-><LI
-><P
-> Documentation on the Slony-I Site- Check the
-documentation on the Slony website: <A
-HREF="http://gborg.postgresql.org/project/slony1/genpage.php?howto_idx"
-TARGET="_top"
->Howto</A
-></P
-></LI
-><LI
-><P
-> Other Documentation - There are several articles here
-<A
-HREF="http://www.varlena.com/varlena/GeneralBits/Tidbits/index.php#Replication"
-TARGET="_top"
->Varlena GeneralBits </A
-> that may be helpful.</P
-></LI
-><LI
-><P
-> IRC - There are usually some people on #slony on
-irc.freenode.net who may be able to answer some of your
-questions. There is also a bot named "rtfm_please" that you may want
-to chat with.</P
-></LI
-><LI
-><P
-> Mailing lists - The answer to your problem may exist
-in the Slony1-general mailing list archives, or you may choose to ask
-your question on the Slony1-general mailing list. The mailing list
-archives, and instructions for joining the list may be found <A
-HREF="http://gborg.postgresql.org/mailman/listinfo/slony1"
-TARGET="_top"
->here. </A
-></P
-></LI
-><LI
-><P
-> If your Russian is much better than your English,
-then <A
-HREF="http://kirov.lug.ru/wiki/Slony"
-TARGET="_top"
->KirovOpenSourceCommunity: Slony</A
-> may be the place to go</P
-></LI
-></UL
-> </P
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN1239"
->13.1. Other Information Sources</A
-></H2
-><P
-></P
-><UL
-><LI
-><P
-> <A
-HREF="http://comstar.dotgeek.org/postgres/slony-config/"
-TARGET="_top"
->slony-config</A
-> - A Perl tool for configuring Slony nodes using
-config files in an XML-based format that the tool transforms into a
-Slonik script</P
-></LI
-></UL
-></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="firstdb.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slony.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="faq.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Replicating Your First Database</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slonyadmin.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Slony-I FAQ</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/altperl.html
+++ /dev/null
@@ -1,590 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
-<HTML
-><HEAD
-><TITLE
-> Slony-I Administration Scripts</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
-REV="MADE"
-HREF="mailto:cbbrowne at gmail.com"><LINK
-REL="HOME"
-TITLE="Slony-I 1.1 Administration"
-HREF="slony.html"><LINK
-REL="UP"
-HREF="t24.html"><LINK
-REL="PREVIOUS"
-TITLE="Defining Slony-I Replication Sets"
-HREF="x267.html"><LINK
-REL="NEXT"
-TITLE="Slon daemons"
-HREF="slonstart.html"><LINK
-REL="STYLESHEET"
-TYPE="text/css"
-HREF="stdstyle.css"><META
-HTTP-EQUIV="Content-Type"></HEAD
-><BODY
-CLASS="SECT1"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->Slony-I 1.1 Administration</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="x267.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="slonstart.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="ALTPERL"
->8. Slony-I Administration Scripts</A
-></H1
-><P
->In the "altperl" directory in the CVS tree, there is a sizable set of Perl scripts that may be used to administer a set of Slony-I instances, which support having arbitrary numbers of nodes. </P
-><P
->Most of them generate Slonik scripts that are then to be passed on to the slonik utility to be submitted to all of the Slony-I nodes in a particular cluster. At one time, this embedded running slonik on the slonik scripts. Unfortunately, this turned out to be a pretty large calibre "foot gun," as minor typos on the command line led, on a couple of occasions, to pretty calamitous actions, so the behaviour has been changed so that the scripts simply submit output to standard output. An administrator should review the slonik script before submitting it to Slonik. </P
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN314"
->8.1. Node/Cluster Configuration - cluster.nodes</A
-></H2
-><P
->The UNIX environment variable <CODE
-CLASS="ENVAR"
->SLONYNODES</CODE
-> is used to determine what Perl configuration file will be used to control the shape of the nodes in a Slony-I cluster. </P
-><P
->What variables are set up...
-<P
-></P
-><UL
-><LI
-><P
-> <CODE
-CLASS="ENVAR"
->$SETNAME</CODE
->=orglogs; # What is the name of the replication set? </P
-></LI
-><LI
-><P
-> <CODE
-CLASS="ENVAR"
->$LOGDIR</CODE
->='/opt/OXRS/log/LOGDBS'; # What is the base directory for logs? </P
-></LI
-><LI
-><P
-> <CODE
-CLASS="ENVAR"
->$SLON_BIN_PATH</CODE
->='/opt/dbs/pgsql74/bin'; # Where to look for slony binaries </P
-></LI
-><LI
-><P
-> <CODE
-CLASS="ENVAR"
->$APACHE_ROTATOR</CODE
->="/opt/twcsds004/OXRS/apache/rotatelogs"; # If set, where to find Apache log rotator</P
-></LI
-></UL
-> </P
-><P
->You then define the set of nodes that are to be replicated using a set of calls to <CODE
-CLASS="FUNCTION"
->add_node()</CODE
->.</P
-><P
-><TT
-CLASS="COMMAND"
-> add_node (host => '10.20.30.40', dbname => 'orglogs', port => 5437,
- user => 'postgres', node => 4, parent => 1);</TT
-></P
-><P
->The set of parameters for <CODE
-CLASS="FUNCTION"
->add_node()</CODE
-> are thus: </P
-><P
-> <P
-CLASS="LITERALLAYOUT"
-><TT
-CLASS="LITERAL"
->my %PARAMS = (host=> undef, # Host name
- dbname => 'template1', # database name
- port => 5432, # Port number
- user => 'postgres', # user to connect as
- node => undef, # node number
- password => undef, # password for user
- parent => 1, # which node is parent to this node
- noforward => undef # shall this node be set up to forward results?
-);</TT
-></P
-></P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN342"
->8.2. Set configuration - cluster.set1, cluster.set2</A
-></H2
-><P
->The UNIX environment variable <CODE
-CLASS="ENVAR"
->SLONYSET</CODE
-> is used to determine what Perl configuration file will be used to determine what objects will be contained in a particular replication set. </P
-><P
->Unlike <CODE
-CLASS="ENVAR"
->SLONYNODES</CODE
->, which is essential for <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->all</I
-></SPAN
-> of the slonik-generating scripts, this only needs to be set when running <TT
-CLASS="FILENAME"
->create_set.pl</TT
->, as that is the only script used to control what tables will be in a particular replication set. </P
-><P
->What variables are set up...
-<P
-></P
-><UL
-><LI
-><P
-> $TABLE_ID = 44; Each table must be identified by a unique number; this variable controls where numbering starts</P
-></LI
-><LI
-><P
-> @PKEYEDTABLES An array of names of tables to be replicated that have a defined primary key so that Slony-I can automatically select its key</P
-></LI
-><LI
-><P
-> %KEYEDTABLES A hash table of tables to be replicated, where the hash index is the table name, and the hash value is the name of a unique not null index suitable as a "candidate primary key."</P
-></LI
-><LI
-><P
-> @SERIALTABLES An array of names of tables to be replicated that have no candidate for primary key. Slony-I will add a key field based on a sequence that Slony-I generates</P
-></LI
-><LI
-><P
-> @SEQUENCES An array of names of sequences that are to be replicated</P
-></LI
-></UL
-> </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN362"
->8.3. build_env.pl</A
-></H2
-><P
->Queries a database, generating output hopefully suitable for
-<TT
-CLASS="FILENAME"
->slon.env</TT
-> consisting of:
-<P
-></P
-><UL
-><LI
-><P
-> a set of <CODE
-CLASS="FUNCTION"
->add_node()</CODE
-> calls to configure the cluster</P
-></LI
-><LI
-><P
-> The arrays <CODE
-CLASS="ENVAR"
->@KEYEDTABLES</CODE
->, <CODE
-CLASS="ENVAR"
->@SERIALTABLES</CODE
->, and <CODE
-CLASS="ENVAR"
->@SEQUENCES</CODE
-></P
-></LI
-></UL
-> </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN375"
->8.4. create_set.pl</A
-></H2
-><P
->This requires <CODE
-CLASS="ENVAR"
->SLONYSET</CODE
-> to be set as well as <CODE
-CLASS="ENVAR"
->SLONYNODES</CODE
->; it is used to
-generate the Slonik script to set up a replication set consisting of a
-set of tables and sequences that are to be replicated. </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN380"
->8.5. drop_node.pl</A
-></H2
-><P
->Generates Slonik script to drop a node from a Slony-I cluster. </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN383"
->8.6. drop_set.pl</A
-></H2
-><P
->Generates Slonik script to drop a replication set (<SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->e.g.</I
-></SPAN
-> - set of tables and sequences) from a Slony-I cluster. </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN387"
->8.7. failover.pl</A
-></H2
-><P
->Generates Slonik script to request failover from a dead node to some new origin </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN390"
->8.8. init_cluster.pl</A
-></H2
-><P
->Generates Slonik script to initialize a whole Slony-I cluster,
-including setting up the nodes, communications paths, and the listener
-routing. </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN393"
->8.9. merge_sets.pl</A
-></H2
-><P
->Generates Slonik script to merge two replication sets together. </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN396"
->8.10. move_set.pl</A
-></H2
-><P
->Generates Slonik script to move the origin of a particular set to a different node. </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN399"
->8.11. replication_test.pl</A
-></H2
-><P
->Script to test whether Slony-I is successfully replicating data. </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN402"
->8.12. restart_node.pl</A
-></H2
-><P
->Generates Slonik script to request the restart of a node. This was
-particularly useful pre-1.0.5 when nodes could get snarled up when
-slon daemons died. </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN405"
->8.13. restart_nodes.pl</A
-></H2
-><P
->Generates Slonik script to restart all nodes in the cluster. Not
-particularly useful... </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN408"
->8.14. show_configuration.pl</A
-></H2
-><P
->Displays an overview of how the environment (e.g. - <CODE
-CLASS="ENVAR"
->SLONYNODES</CODE
->) is set
-to configure things. </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN412"
->8.15. slon_kill.pl</A
-></H2
-><P
->Kills slony watchdog and all slon daemons for the specified set. It
-only works if those processes are running on the local host, of
-course! </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN415"
->8.16. slon_pushsql.pl</A
-></H2
-><P
->Generates Slonik script to push DDL changes to a replication set. </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN418"
->8.17. slon_start.pl</A
-></H2
-><P
->This starts a slon daemon for the specified cluster and node, and uses
-slon_watchdog.pl to keep it running. </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN421"
->8.18. slon_watchdog.pl</A
-></H2
-><P
->Used by slon_start.pl... </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN424"
->8.19. slon_watchdog2.pl</A
-></H2
-><P
->This is a somewhat smarter watchdog; it monitors a particular Slony-I
-node, and restarts the slon process if it hasn't seen updates go in in
-20 minutes or more. </P
-><P
->This is helpful if there is an unreliable network connection such that
-the slon sometimes stops working without becoming aware of it... </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN428"
->8.20. subscribe_set.pl</A
-></H2
-><P
->Generates Slonik script to subscribe a particular node to a particular replication set. </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN431"
->8.21. uninstall_nodes.pl</A
-></H2
-><P
->This goes through and drops the Slony-I schema from each node; use
-this if you want to destroy replication throughout a cluster. This is
-a VERY unsafe script! </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN434"
->8.22. unsubscribe_set.pl</A
-></H2
-><P
->Generates Slonik script to unsubscribe a node from a replication set.
- </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN437"
->8.23. update_nodes.pl</A
-></H2
-><P
->Generates Slonik script to tell all the nodes to update the Slony-I
-
-functions. This will typically be needed when you upgrade from one
-
-version of Slony-I to another.
-
-
- </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="x267.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slony.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="slonstart.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Defining Slony-I Replication Sets</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="t24.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Slon daemons</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/app-slon.html
+++ /dev/null
@@ -1,477 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->slon</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
-REV="MADE"
-HREF="mailto:slony1-general at gborg.postgresql.org"><LINK
-REL="HOME"
-TITLE="Slony-I HEAD_20041221 Documentation"
-HREF="index.html"><LINK
-REL="UP"
-TITLE="Slony-I binaries"
-HREF="c383.html"><LINK
-REL="PREVIOUS"
-TITLE="Slony-I binaries"
-HREF="c383.html"><LINK
-REL="NEXT"
-TITLE="slonik"
-HREF="app-slonik.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="2004-12-22T22:53:46"></HEAD
-><BODY
-CLASS="REFENTRY"
-><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
-> HEAD_20041221 Documentation</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="c383.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="c383.html#AEN383"
->Fast Backward</A
-></TD
-><TD
-WIDTH="60%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="app-slonik.html"
->Fast Forward</A
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="app-slonik.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><H1
-><A
-NAME="APP-SLON"
-></A
-><SPAN
-CLASS="APPLICATION"
->slon</SPAN
-></H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN392"
-></A
-><H2
->Name</H2
-><SPAN
-CLASS="APPLICATION"
->slon</SPAN
-> -- <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> daemon
- </DIV
-><A
-NAME="AEN397"
-></A
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN399"
-></A
-><H2
->Synopsis</H2
-><P
-><TT
-CLASS="COMMAND"
->slon</TT
-> [<VAR
-CLASS="REPLACEABLE"
->option</VAR
->...] [<VAR
-CLASS="REPLACEABLE"
->clustername</VAR
->] [<VAR
-CLASS="REPLACEABLE"
->conninfo</VAR
->]</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN408"
-></A
-><H2
->Description</H2
-><P
-> <SPAN
-CLASS="APPLICATION"
->slon</SPAN
-> is the daemon application that
- <SPAN
-CLASS="QUOTE"
->"runs"</SPAN
-> <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
->
- replication. A <SPAN
-CLASS="APPLICATION"
->slon</SPAN
-> instance must be
- run for each node in a <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
->
- cluster.
- </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="R1-APP-SLON-3"
-></A
-><H2
->Options</H2
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><TT
-CLASS="OPTION"
->-d</TT
-><VAR
-CLASS="REPLACEABLE"
->debuglevel</VAR
-><//arg></DT
-><DD
-><P
-> Specifies the level of verbosity that <SPAN
-CLASS="APPLICATION"
->slon</SPAN
-> should
- use when logging its activity.
- </P
-><P
-> The eight levels of logging are:
- <P
-></P
-></P><UL
-><LI
-><P
->Error</P
-></LI
-><LI
-><P
->Warn</P
-></LI
-><LI
-><P
->Config</P
-></LI
-><LI
-><P
->Info</P
-></LI
-><LI
-><P
->Debug1</P
-></LI
-><LI
-><P
->Debug2</P
-></LI
-><LI
-><P
->Debug3</P
-></LI
-><LI
-><P
->Debug4</P
-></LI
-></UL
-><P>
- </P
-></DD
-><DT
-><TT
-CLASS="OPTION"
->-s</TT
-><VAR
-CLASS="REPLACEABLE"
->SYNC check interval</VAR
-><//arg></DT
-><DD
-><P
-> Specifies the interval, in milliseconds, in which
- <SPAN
-CLASS="APPLICATION"
->slon</SPAN
-> should add a SYNC even if none has been
- mandated by data creation. Default is 10000 ms.
- </P
-><P
-> Short sync times keep the master on a <SPAN
-CLASS="QUOTE"
->"short leash"</SPAN
->,
- updating the slaves more frequently. If you have replicated
- sequences that are frequently updated <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->without</I
-></SPAN
-> there
- being tables that are affected, this keeps there from being times
- when only sequences are updated, and therefore <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->no</I
-></SPAN
->
- syncs take place
- </P
-></DD
-><DT
-><TT
-CLASS="OPTION"
->-t</TT
-><VAR
-CLASS="REPLACEABLE"
->SYNC interval timeout</VAR
-><//arg></DT
-><DD
-><P
-> Default is 60000 ms.
- </P
-></DD
-><DT
-><TT
-CLASS="OPTION"
->-g</TT
-><VAR
-CLASS="REPLACEABLE"
->group size</VAR
-><//arg></DT
-><DD
-><P
-> Maximum SYNC group size; defaults to 6. Thus, if a particular
- node is behind by 200 SYNCs, it will try to group them together
- into groups of 6. This would be expected to reduce transaction
- overhead due to having fewer transactions to <TT
-CLASS="COMMAND"
->COMMIT</TT
->.
- </P
-><P
-> The default of 6 is probably suitable for small systems
- that can devote only very limited bits of memory to slon. If you
- have plenty of memory, it would be reasonable to increase this,
- as it will increase the amount of work done in each transaction,
- and will allow a subscriber that is behind by a lot to catch up
- more quickly.
- </P
-><P
-> Slon processes usually stay pretty small; even with large
- value for this option, slon would be expected to only grow to a
- few MB in size.
- </P
-></DD
-><DT
-><TT
-CLASS="OPTION"
->-c</TT
-><VAR
-CLASS="REPLACEABLE"
->cleanup cycles</VAR
-><//arg></DT
-><DD
-><P
-> How often to <TT
-CLASS="COMMAND"
->VACUUM</TT
-> in cleanup cycles.
- </P
-><P
-> Set this to zero to disable slon-initiated vacuuming. If
- you are using something like <SPAN
-CLASS="APPLICATION"
->pg_autovacuum</SPAN
->
- to initiate vacuums, you may not need for slon to initiate vacuums itself.
- If you are not, there are some tables Slony-I uses that collect a
- <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->lot</I
-></SPAN
-> of dead tuples that should be vacuumed frequently.
- </P
-></DD
-><DT
-><TT
-CLASS="OPTION"
->-p</TT
-><VAR
-CLASS="REPLACEABLE"
->PID filename</VAR
-><//arg></DT
-><DD
-><P
-> PID filename.
- </P
-></DD
-><DT
-><TT
-CLASS="OPTION"
->-f</TT
-><VAR
-CLASS="REPLACEABLE"
->config file</VAR
-><//arg></DT
-><DD
-><P
-> File containing <SPAN
-CLASS="APPLICATION"
->slon</SPAN
-> configuration.
- </P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN493"
-></A
-><H2
->Exit Status</H2
-><P
-> <SPAN
-CLASS="APPLICATION"
->slon</SPAN
-> returns 0 to the shell if it
- finished normally. It returns -1 if it encounters any fatal error.
- </P
-></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="c383.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="app-slonik.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-><SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> binaries</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="c383.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><SPAN
-CLASS="APPLICATION"
->slonik</SPAN
-></TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/failover.html
+++ /dev/null
@@ -1,487 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
-<HTML
-><HEAD
-><TITLE
->Doing switchover and failover with Slony-I</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
-REV="MADE"
-HREF="mailto:cbbrowne at gmail.com"><LINK
-REL="HOME"
-TITLE="Slony-I 1.1 Administration"
-HREF="slony.html"><LINK
-REL="UP"
-HREF="slonyadmin.html"><LINK
-REL="PREVIOUS"
-TITLE="Reshaping a Cluster"
-HREF="reshape.html"><LINK
-REL="NEXT"
-TITLE=" Slony Listen Paths"
-HREF="listenpaths.html"><LINK
-REL="STYLESHEET"
-TYPE="text/css"
-HREF="stdstyle.css"><META
-HTTP-EQUIV="Content-Type"></HEAD
-><BODY
-CLASS="SECT1"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->Slony-I 1.1 Administration</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="reshape.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="listenpaths.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="FAILOVER"
->7. Doing switchover and failover with Slony-I</A
-></H1
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN810"
->7.1. Foreword</A
-></H2
-><P
-> <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> is an asynchronous
-replication system. Because of that, it is almost certain that at the
-moment the current origin of a set fails, the final transactions
-committed at the origin will have not yet propagated to the
-subscribers. Systems are particularly likely to fail under heavy
-load; that is one of the corollaries of Murphy's Law. Therefore the
-principal goal is to <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->prevent</I
-></SPAN
-> the main server from
-failing. The best way to do that is frequent maintenance.</P
-><P
-> Opening the case of a running server is not exactly what we
-should consider a <SPAN
-CLASS="QUOTE"
->"professional"</SPAN
-> way to do system
-maintenance. And interestingly, those users who found it valuable to
-use replication for backup and failover purposes are the very ones
-that have the lowest tolerance for terms like <SPAN
-CLASS="QUOTE"
->"system
-downtime."</SPAN
-> To help support these requirements, Slony-I has not
-only failover capabilities, but features for controlled origin
-transfer.</P
-><P
-> It is assumed in this document that the reader is familiar with
-the <A
-HREF="app-slonik.html#SLONIK"
-> <B
-CLASS="APPLICATION"
->slonik</B
-> </A
->
-utility and knows at least how to set up a simple 2 node replication
-system with <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
->.</P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN822"
->7.2. Controlled Switchover</A
-></H2
-><P
-> We assume a current <SPAN
-CLASS="QUOTE"
->"origin"</SPAN
-> as node1 with one
-<SPAN
-CLASS="QUOTE"
->"subscriber"</SPAN
-> as node2 (<SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->e.g.</I
-></SPAN
-> -
-slave). A web application on a third server is accessing the database
-on node1. Both databases are up and running and replication is more
-or less in sync.
-
-<P
-></P
-><UL
-><LI
-><P
-> At the time of this writing switchover to another
-server requires the application to reconnect to the database. So in
-order to avoid any complications, we simply shut down the web server.
-Users who use <B
-CLASS="APPLICATION"
->pg_pool</B
-> for the applications database
-connections merely have to shut down the pool.</P
-></LI
-><LI
-><P
-> A small slonik script executes the following commands:
-
-<TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="90%"
-><TR
-><TD
-><PRE
-CLASS="PROGRAMLISTING"
-> lock set (id = 1, origin = 1);
- wait for event (origin = 1, confirmed = 2);
- move set (id = 1, old origin = 1, new origin = 2);
- wait for event (origin = 1, confirmed = 2);</PRE
-></TD
-></TR
-></TABLE
-></P
-><P
-> After these commands, the origin (master role) of data set 1
-has been transferred to node2. And it is not simply transferred; it
-is done in a fashion such that node1 becomes a fully synchronized
-subscriber, actively replicating the set. So the two nodes have
-switched roles completely.</P
-></LI
-><LI
-><P
-> After reconfiguring the web application (or
-<B
-CLASS="APPLICATION"
->pgpool</B
->) to connect to the database on node2, the web
-server is restarted and resumes normal operation.</P
-><P
-> Done in one shell script, that does the application shutdown,
-<B
-CLASS="APPLICATION"
->slonik</B
->, move config files and startup all together, this
-entire procedure is likely to take less than 10 seconds.</P
-></LI
-></UL
-></P
-><P
-> You may now simply shutdown the server hosting node1 and do
-whatever is required to maintain the server. When <B
-CLASS="APPLICATION"
-><A
-HREF="app-slon.html#SLON"
-> slon </A
-></B
-> node1 is restarted later,
-it will start replicating again, and soon catch up. At this point the
-procedure to switch origins is executed again to restore the original
-configuration.</P
-><P
-> This is the preferred way to handle things; it runs quickly,
-under control of the administrators, and there is no need for there to
-be any loss of data.</P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN845"
->7.3. Failover</A
-></H2
-><P
-> If some more serious problem occurs on the <SPAN
-CLASS="QUOTE"
->"origin"</SPAN
->
-server, it may be necessary to failover to a backup server. This is a
-highly undesirable circumstance, as transactions <SPAN
-CLASS="QUOTE"
->"committed"</SPAN
-> on
-the origin, but not applied to the subscribers, will be lost. You may
-have reported these transactions as <SPAN
-CLASS="QUOTE"
->"successful"</SPAN
-> to outside
-users. As a result, failover should be considered a <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->last
-resort</I
-></SPAN
->. If the <SPAN
-CLASS="QUOTE"
->"injured"</SPAN
-> origin server can be brought up to
-the point where it can limp along long enough to do a controlled
-switchover, that is <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->greatly</I
-></SPAN
-> preferable.</P
-><P
-> Slony does not provide any automatic detection for failed
-systems. Abandoning committed transactions is a business decision
-that cannot be made by a database. If someone wants to put the
-commands below into a script executed automatically from the network
-monitoring system, well ... it's <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->your</I
-></SPAN
-> data, and it's <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->your</I
-></SPAN
-> failover policy.
-
-<P
-></P
-><UL
-><LI
-><P
-> The <A
-HREF="app-slonik.html#SLONIK"
-> <B
-CLASS="APPLICATION"
->slonik</B
-> </A
-> command
-
-<TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="90%"
-><TR
-><TD
-><PRE
-CLASS="PROGRAMLISTING"
-> failover (id = 1, backup node = 2);</PRE
-></TD
-></TR
-></TABLE
-></P
-><P
-> causes node2 to assume the ownership (origin) of all sets that
-have node1 as their current origin. If there should happen to be
-additional nodes in the <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> cluster, all direct
-subscribers of node1 are instructed that this is happening.
-<B
-CLASS="APPLICATION"
->Slonik</B
-> will also query all direct subscribers in order
-to determine out which node has the highest replication status
-(<SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->e.g.</I
-></SPAN
-> - the latest committed transaction) for each set, and
-the configuration will be changed in a way that node2 first applies
-those final before actually allowing write access to the tables.</P
-><P
-> In addition, all nodes that subscribed directly to node1 will
-now use node2 as data provider for the set. This means that after the
-failover command succeeded, no node in the entire replication setup
-will receive anything from node1 any more.</P
-></LI
-><LI
-><P
-> Reconfigure and restart the application (or <B
-CLASS="APPLICATION"
->pgpool</B
->)
-to cause it to reconnect to node2.</P
-></LI
-><LI
-><P
-> After the failover is complete and node2 accepts
-write operations against the tables, remove all remnants of node1's
-configuration information with the <A
-HREF="app-slonik.html#SLONIK"
-> <B
-CLASS="APPLICATION"
->slonik</B
-> </A
-> command
-
-<TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="90%"
-><TR
-><TD
-><PRE
-CLASS="PROGRAMLISTING"
-> drop node (id = 1, event node = 2);</PRE
-></TD
-></TR
-></TABLE
-></P
-></LI
-></UL
-></P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN876"
->7.4. After Failover, Reconfiguring node1</A
-></H2
-><P
-> After the above failover, the data stored on node1 is
-considered out of sync with the rest of the nodes, and must be treated
-as corrupt. Therefore, the only way to get node1 back and transfer
-the origin role back to it is to rebuild it from scratch as a
-subscriber, let it catch up, and then follow the switchover
-procedure.</P
-><P
-> If the database is very large, it may take many hours to
-recover node1 as a functioning <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> node; that is
-another reason to consider failover as an undesirable <SPAN
-CLASS="QUOTE"
->"final
-resort."</SPAN
-></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="reshape.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slony.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="listenpaths.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Reshaping a Cluster</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slonyadmin.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Slony Listen Paths</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/addthings.html
+++ /dev/null
@@ -1,222 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
-<HTML
-><HEAD
-><TITLE
-> Adding Things to Replication</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
-REV="MADE"
-HREF="mailto:cbbrowne at gmail.com"><LINK
-REL="HOME"
-TITLE="Slony-I 1.1 Administration"
-HREF="slony.html"><LINK
-REL="UP"
-HREF="slonyadmin.html"><LINK
-REL="PREVIOUS"
-TITLE=" Slony Listen Paths"
-HREF="listenpaths.html"><LINK
-REL="NEXT"
-TITLE=" Dropping things from Slony Replication"
-HREF="dropthings.html"><LINK
-REL="STYLESHEET"
-TYPE="text/css"
-HREF="stdstyle.css"><META
-HTTP-EQUIV="Content-Type"></HEAD
-><BODY
-CLASS="SECT1"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->Slony-I 1.1 Administration</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="listenpaths.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="dropthings.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="ADDTHINGS"
->9. Adding Things to Replication</A
-></H1
-><P
->You may discover that you have missed replicating things that
-you wish you were replicating. </P
-><P
->This can be fairly easily remedied. </P
-><P
->You cannot directly use <A
-HREF="app-slonik.html#SLONIK"
-> slonik </A
->
-commands <TT
-CLASS="COMMAND"
->SET ADD TABLE</TT
-> or <TT
-CLASS="COMMAND"
->SET ADD SEQUENCE</TT
-> in
-order to add tables and sequences to a replication set that is
-presently replicating; you must instead create a new replication set.
-Once it is identically subscribed (e.g. - the set of providers and
-subscribers is <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->entirely identical</I
-></SPAN
-> to that for the set it is
-to merge with), the sets may be merged together using <TT
-CLASS="COMMAND"
->MERGE
-SET</TT
->. </P
-><P
->Up to and including 1.0.2, there was a potential problem where
-if <TT
-CLASS="COMMAND"
->MERGE_SET</TT
-> is issued while other subscription-related
-events are pending, it is possible for things to get pretty confused
-on the nodes where other things were pending. This problem was
-resolved in 1.0.5. </P
-><P
->It is suggested that you be very deliberate when adding such
-things. For instance, submitting multiple subscription requests for a
-particular set in one <A
-HREF="app-slonik.html#SLONIK"
-> slonik </A
-> script
-often turns out quite badly. If it is <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->truly</I
-></SPAN
-> necessary to
-automate this, you'll probably want to submit <TT
-CLASS="COMMAND"
->WAIT FOR EVENT</TT
->
-requests in between subscription requests in order that the <A
-HREF="app-slonik.html#SLONIK"
-> slonik </A
-> script wait for one subscription to
-complete processing before requesting the next one. </P
-><P
->But in general, it is likely to be easier to cope with complex
-node reconfigurations by making sure that one change has been
-successfully processed before going on to the next. It's way easier
-to fix one thing that has broken than to piece things together after
-the interaction of five things that have all broken.
-
-
- </P
-></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="listenpaths.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slony.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="dropthings.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Slony Listen Paths</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slonyadmin.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Dropping things from Slony Replication</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/concepts.html
+++ /dev/null
@@ -1,344 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->Slony-I Concepts</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
-REV="MADE"
-HREF="mailto:slony1-general at gborg.postgresql.org"><LINK
-REL="HOME"
-TITLE="Slony-I HEAD_20041221 Documentation"
-HREF="index.html"><LINK
-REL="UP"
-TITLE="Slony-I Installation"
-HREF="installation.html"><LINK
-REL="PREVIOUS"
-TITLE=" Installing Slony-I"
-HREF="x253.html"><LINK
-REL="NEXT"
-TITLE="Defining Slony-I Clusters"
-HREF="cluster.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="2004-12-22T22:53:46"></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
-> HEAD_20041221 Documentation</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="x253.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="installation.html"
->Fast Backward</A
-></TD
-><TD
-WIDTH="60%"
-ALIGN="center"
-VALIGN="bottom"
->Slony-I Installation</TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="installation.html"
->Fast Forward</A
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="cluster.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="CONCEPTS"
->7. <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> Concepts</A
-></H1
-><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
-></UL
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN273"
->7.1. Cluster</A
-></H2
-><P
->In <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> terms, a Cluster is a named set of PostgreSQL
-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="AEN283"
->7.2. Node</A
-></H2
-><P
->A <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> Node is a named PostgreSQL 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"
-><TT
-CLASS="COMMAND"
->CONNINFO</TT
-></A
->
-information indicates a string argument 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="AEN301"
->7.3. Replication Set</A
-></H2
-><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="AEN307"
->7.4. Origin, Providers and Subscribers</A
-></H2
-><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
-><P
->Other nodes in the cluster will 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
-moved to another node.) But <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> supports the notion of cascaded
-subscriptions, that is, a node that is subscribed to the origin may
-also behave as a <SPAN
-CLASS="QUOTE"
->"provider"</SPAN
-> to other nodes in the cluster.</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="x253.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="cluster.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Installing Slony-I</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="installation.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Defining Slony-I Clusters</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/slonyadmin.html
+++ /dev/null
@@ -1,360 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->Slony-I Administration</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
-REV="MADE"
-HREF="mailto:slony1-general at gborg.postgresql.org"><LINK
-REL="HOME"
-TITLE="Slony-I HEAD_20041221 Documentation"
-HREF="index.html"><LINK
-REL="PREVIOUS"
-TITLE="WAIT FOR EVENT"
-HREF="stmtwaitevent.html"><LINK
-REL="NEXT"
-HREF="t1741.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="2004-12-22T22:53:46"></HEAD
-><BODY
-CLASS="PART"
-><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
-> HEAD_20041221 Documentation</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="stmtwaitevent.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="commandreferencec.html"
->Fast Backward</A
-></TD
-><TD
-WIDTH="60%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="faq.html"
->Fast Forward</A
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="t1741.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="PART"
-><A
-NAME="SLONYADMIN"
-></A
-><DIV
-CLASS="TITLEPAGE"
-><H1
-CLASS="TITLE"
->III. <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> Administration</H1
-><DIV
-CLASS="TOC"
-><DL
-><DT
-><B
->Table of Contents</B
-></DT
-><DT
-><A
-HREF="t1741.html"
-></A
-></DT
-><DD
-><DL
-><DT
->1. <A
-HREF="t1741.html#ALTPERL"
->Slony-I Administration Scripts</A
-></DT
-></DL
-></DD
-><DT
-><A
-HREF="t1898.html"
-></A
-></DT
-><DD
-><DL
-><DT
->1. <A
-HREF="t1898.html#SLONSTART"
->Slon daemons</A
-></DT
-></DL
-></DD
-><DT
-><A
-HREF="t1949.html"
-></A
-></DT
-><DD
-><DL
-><DT
->1. <A
-HREF="t1949.html#SUBSCRIBENODES"
->Subscribing Nodes</A
-></DT
-></DL
-></DD
-><DT
-><A
-HREF="t1980.html"
-></A
-></DT
-><DD
-><DL
-><DT
->1. <A
-HREF="t1980.html#MONITORING"
->Monitoring</A
-></DT
-></DL
-></DD
-><DT
-><A
-HREF="t2015.html"
-></A
-></DT
-><DD
-><DL
-><DT
->1. <A
-HREF="t2015.html#MAINTENANCE"
->Slony-I Maintenance</A
-></DT
-></DL
-></DD
-><DT
-><A
-HREF="t2071.html"
-></A
-></DT
-><DD
-><DL
-><DT
->1. <A
-HREF="t2071.html#RESHAPE"
->Reshaping a Cluster</A
-></DT
-></DL
-></DD
-><DT
-><A
-HREF="t2103.html"
-></A
-></DT
-><DD
-><DL
-><DT
->1. <A
-HREF="t2103.html#FAILOVER"
->Doing switchover and failover with Slony-I</A
-></DT
-></DL
-></DD
-><DT
-><A
-HREF="t2185.html"
-></A
-></DT
-><DD
-><DL
-><DT
->1. <A
-HREF="t2185.html#LISTENPATHS"
-><SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> listen paths</A
-></DT
-></DL
-></DD
-><DT
-><A
-HREF="t2287.html"
-></A
-></DT
-><DD
-><DL
-><DT
->1. <A
-HREF="t2287.html#ADDTHINGS"
->Adding Things to Replication</A
-></DT
-></DL
-></DD
-><DT
-><A
-HREF="t2313.html"
-></A
-></DT
-><DD
-><DL
-><DT
->1. <A
-HREF="t2313.html#DROPTHINGS"
->Dropping things from Slony Replication</A
-></DT
-></DL
-></DD
-><DT
-><A
-HREF="t2409.html"
-></A
-></DT
-><DD
-><DL
-><DT
->1. <A
-HREF="t2409.html#DDLCHANGES"
->Database Schema Changes (DDL)</A
-></DT
-></DL
-></DD
-><DT
-><A
-HREF="t2447.html"
-></A
-></DT
-><DD
-><DL
-><DT
->1. <A
-HREF="t2447.html#FIRSTDB"
->Replicating Your First Database</A
-></DT
-></DL
-></DD
-><DT
-><A
-HREF="t2563.html"
-></A
-></DT
-><DD
-><DL
-><DT
->1. <A
-HREF="t2563.html#HELP"
->More Slony-I Help</A
-></DT
-></DL
-></DD
-></DL
-></DIV
-></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="stmtwaitevent.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="t1741.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->WAIT FOR EVENT</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-> </TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-></TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/t24.html
+++ /dev/null
@@ -1,524 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
-<HTML
-><HEAD
-><TITLE
->Slony-I Administration</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
-REV="MADE"
-HREF="mailto:cbbrowne at gmail.com"><LINK
-REL="HOME"
-TITLE="Slony-I 1.1 Administration"
-HREF="slony.html"><LINK
-REL="PREVIOUS"
-TITLE="Slony-I 1.1 Administration"
-HREF="slony.html"><LINK
-REL="NEXT"
-TITLE=" Requirements"
-HREF="requirements.html"><LINK
-REL="STYLESHEET"
-TYPE="text/css"
-HREF="stdstyle.css"><META
-HTTP-EQUIV="Content-Type"></HEAD
-><BODY
-CLASS="ARTICLE"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->Slony-I 1.1 Administration</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="slony.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="requirements.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="ARTICLE"
-><DIV
-CLASS="TITLEPAGE"
-><H1
-CLASS="TITLE"
-><A
-NAME="AEN24"
->Slony-I Administration</A
-></H1
-><HR></DIV
-><DIV
-CLASS="TOC"
-><DL
-><DT
-><B
->Table of Contents</B
-></DT
-><DT
->1. <A
-HREF="t24.html#INTRODUCTION"
->Introduction to Slony-I</A
-></DT
-><DT
->2. <A
-HREF="requirements.html"
->Requirements</A
-></DT
-><DT
->3. <A
-HREF="installation.html"
->Slony-I Installation</A
-></DT
-><DT
->4. <A
-HREF="slonik.html"
->Slonik</A
-></DT
-><DT
->5. <A
-HREF="concepts.html"
->Slony-I Concepts</A
-></DT
-><DT
->6. <A
-HREF="cluster.html"
->Defining Slony-I Clusters</A
-></DT
-><DT
->7. <A
-HREF="x267.html"
->Defining Slony-I Replication Sets</A
-></DT
-><DT
->8. <A
-HREF="altperl.html"
->Slony-I Administration Scripts</A
-></DT
-><DT
->9. <A
-HREF="slonstart.html"
->Slon daemons</A
-></DT
-><DT
->10. <A
-HREF="slonconfig.html"
->Slon Configuration Options</A
-></DT
-><DT
->11. <A
-HREF="subscribenodes.html"
->Subscribing Nodes</A
-></DT
-><DT
->12. <A
-HREF="monitoring.html"
->Monitoring</A
-></DT
-><DT
->13. <A
-HREF="maintenance.html"
->Slony-I Maintenance</A
-></DT
-><DT
->14. <A
-HREF="reshape.html"
->Reshaping a Cluster</A
-></DT
-><DT
->15. <A
-HREF="failover.html"
->Doing switchover and failover with Slony-I</A
-></DT
-><DT
->16. <A
-HREF="listenpaths.html"
->Slony Listen Paths</A
-></DT
-><DT
->17. <A
-HREF="addthings.html"
->Adding Things to Replication</A
-></DT
-><DT
->18. <A
-HREF="dropthings.html"
->Dropping things from Slony Replication</A
-></DT
-><DT
->19. <A
-HREF="ddlchanges.html"
->Database Schema Changes (DDL)</A
-></DT
-><DT
->20. <A
-HREF="firstdb.html"
->Replicating Your First Database</A
-></DT
-><DT
->21. <A
-HREF="help.html"
->More Slony-I Help</A
-></DT
-><DT
->22. <A
-HREF="x931.html"
->Other Information Sources</A
-></DT
-></DL
-></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="INTRODUCTION"
->1. Introduction to Slony-I</A
-></H1
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN28"
->1.1. Why yet another replication system?</A
-></H2
-><P
->Slony-I was born from an idea to create a replication system that was not tied
-to a specific version of PostgreSQL, which is allowed to be started and stopped on
-an existing database with out the need for a dump/reload cycle.</P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN31"
->1.2. What Slony-I is</A
-></H2
-><P
->Slony-I is a <SPAN
-CLASS="QUOTE"
->"master to multiple slaves"</SPAN
-> replication
-system supporting cascading and slave promotion. The big picture for
-the development of Slony-I 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. <SPAN
-CLASS="QUOTE"
->"Reasonable,"</SPAN
-> 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.</P
-><P
-> See also <A
-HREF="t24.html#SLONYLISTENERCOSTS"
-> SlonyListenerCosts</A
-> for a further analysis.</P
-><P
-> Slony-I 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, Slony-I may not be the ideal
-replication solution for you.</P
-><P
-> There are plans for a <SPAN
-CLASS="QUOTE"
->"file-based log shipping"</SPAN
->
-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
-<SPAN
-CLASS="QUOTE"
->"log shipping."</SPAN
-></P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN42"
->1.3. Slony-I is not</A
-></H2
-><P
->Slony-I is not a network management system.</P
-><P
-> Slony-I does not have any functionality within it to detect a
-node failure, or automatically promote a node to a master or other
-data origin.</P
-><P
->Slony-I is not multi-master; it's not a connection broker, and
-it doesn't make you coffee and toast in the morning.</P
-><P
->(That being said, the plan is for a subsequent system, Slony-II,
-to provide "multimaster" capabilities, and be "bootstrapped" using
-Slony-I. But that is a separate project, and expectations for Slony-I
-should not be based on hopes for future projects.)</P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN48"
->1.4. Why doesn't Slony-I do automatic fail-over/promotion?</A
-></H2
-><P
->This is the job of network monitoring software, not Slony.
-Every site's configuration and fail-over path is different. 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 <SPAN
-CLASS="QUOTE"
->"failed"</SPAN
-> node vary in every
-network setup, vendor choice, hardware/software combination. This is
-clearly the realm of network management software and not
-Slony-I.</P
-><P
->Let Slony-I do what it does best: provide database replication.</P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN53"
->1.5. Current Limitations</A
-></H2
-><P
->Slony-I 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 Slony-I
-operates using triggers, and neither schema changes nor large object
-operations can raise triggers suitable to tell Slony-I when those
-kinds of changes take place.</P
-><P
->There is a capability for Slony-I to propagate DDL changes if
-you submit them as scripts via the <B
-CLASS="APPLICATION"
->slonik</B
->
-<TT
-CLASS="COMMAND"
->EXECUTE SCRIPT</TT
-> operation. That is not
-<SPAN
-CLASS="QUOTE"
->"automatic;"</SPAN
-> you have to construct an SQL DDL script and submit
-it.</P
-><P
->If you have those sorts of requirements, it may be worth
-exploring the use of <B
-CLASS="APPLICATION"
->PostgreSQL</B
-> 8.0 PITR (Point In Time
-Recovery), where <ACRONYM
-CLASS="ACRONYM"
->WAL</ACRONYM
-> logs are replicated to remote
-nodes. Unfortunately, that has two attendant limitations:
-
-<P
-></P
-><UL
-><LI
-><P
-> PITR replicates <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->all</I
-></SPAN
-> changes in
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->all</I
-></SPAN
-> databases; you cannot exclude data that isn't
-relevant;</P
-></LI
-><LI
-><P
-> 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 <SPAN
-CLASS="QUOTE"
->"standby
-server"</SPAN
-> which cannot be used without it ceasing to be
-<SPAN
-CLASS="QUOTE"
->"standby."</SPAN
-></P
-></LI
-></UL
-></P
-><P
->There are a number of distinct models for database replication;
-it is impossible for one replication system to be all things to all
-people.</P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="SLONYLISTENERCOSTS"
->1.6. Slony-I Communications
-Costs</A
-></H2
-><P
->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:
-
-<P
-></P
-><UL
-><LI
-><P
-> It is necessary to have a sl_path entry allowing
-connection from each node to every other node. Most will normally not
-need to be used for a given replication configuration, but this means
-that there needs to be n(n-1) paths. It is probable that there will
-be considerable repetition of entries, since the path to "node n" is
-likely to be the same from everywherein the network.</P
-></LI
-><LI
-><P
-> It is similarly necessary to have a sl_listen entry
-indicating how data flows from every node to every other node. This
-again requires configuring n(n-1) "listener paths."</P
-></LI
-><LI
-><P
-> 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 sl_log_1 and sl_log_2 data, as any
-<SPAN
-CLASS="QUOTE"
->"forwarding"</SPAN
-> node could potentially take over as <SPAN
-CLASS="QUOTE"
->"master"</SPAN
->
-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.</P
-></LI
-></UL
-></P
-><P
->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.</P
-></DIV
-></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="slony.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slony.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="requirements.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Slony-I 1.1 Administration</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-> </TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Requirements</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/app-slonik.html
+++ /dev/null
@@ -1,311 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->slonik</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
-REV="MADE"
-HREF="mailto:slony1-general at gborg.postgresql.org"><LINK
-REL="HOME"
-TITLE="Slony-I HEAD_20041221 Documentation"
-HREF="index.html"><LINK
-REL="UP"
-TITLE="Slony-I binaries"
-HREF="c383.html"><LINK
-REL="PREVIOUS"
-TITLE="slon"
-HREF="app-slon.html"><LINK
-REL="NEXT"
-TITLE="Slonik Command Summary"
-HREF="slonikcommands.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="2004-12-22T22:53:46"></HEAD
-><BODY
-CLASS="REFENTRY"
-><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
-> HEAD_20041221 Documentation</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="app-slon.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="app-slon.html"
->Fast Backward</A
-></TD
-><TD
-WIDTH="60%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="slonikcommands.html"
->Fast Forward</A
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="slonikcommands.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><H1
-><A
-NAME="APP-SLONIK"
-></A
-><SPAN
-CLASS="APPLICATION"
->slonik</SPAN
-></H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN503"
-></A
-><H2
->Name</H2
-><SPAN
-CLASS="APPLICATION"
->slonik</SPAN
-> -- <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> command processor
- </DIV
-><A
-NAME="AEN508"
-></A
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN510"
-></A
-><H2
->Synopsis</H2
-><P
-><TT
-CLASS="COMMAND"
->slonik</TT
-> [<VAR
-CLASS="REPLACEABLE"
->filename</VAR
->]</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN515"
-></A
-><H2
->Description</H2
-><P
-> <SPAN
-CLASS="APPLICATION"
->slonik</SPAN
-> is the command processor
- application that is used to set up and modify configurations of
- <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> replication clusters.
- </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN520"
-></A
-><H2
->Outline</H2
-><P
->The <SPAN
-CLASS="APPLICATION"
->slonik</SPAN
-> command line utility is
- supposed to be used embedded into shell scripts and reads commands
- from files or stdin.</P
-><P
->It reads a set of Slonik statements, which are written in a
- scripting language with syntax similar to that of SQL, and performs
- the set of configuration changes on the slony nodes specified in the
- script.</P
-><P
->Nearly all of the real configuration work is actually done by
- calling stored procedures after loading the <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
->
- support base into a database. <SPAN
-CLASS="APPLICATION"
->Slonik</SPAN
-> was created
- because these stored procedures have special requirements as to on
- which particular node in the replication system they are called.
- The absence of named parameters for stored procedures makes it
- rather hard to do this from the <SPAN
-CLASS="APPLICATION"
->psql</SPAN
-> prompt, and
- <SPAN
-CLASS="APPLICATION"
->psql</SPAN
-> lacks the ability to maintain multiple
- connections with open transactions to multiple databases.</P
-><P
->The format of the Slonik <SPAN
-CLASS="QUOTE"
->"language"</SPAN
-> is very similar to
- that of SQL, and the parser is based on a similar set of formatting
- rules for such things as numbers and strings. Note that slonik is
- declarative, using literal values throughout, and does
- <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->not</I
-></SPAN
-> have the notion of variables. It is
- anticipated that Slonik scripts will typically be
- <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->generated</I
-></SPAN
-> by scripts, such as Bash or Perl, and
- these sorts of scripting languages already have perfectly good ways
- of managing variables, doing iteration, and such.</P
-><P
->See also <A
-HREF="slonikcommands.html"
-> Slonik Commands
- </A
->. </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN536"
-></A
-><H2
->Exit Status</H2
-><P
-> <SPAN
-CLASS="APPLICATION"
->slonik</SPAN
-> returns 0 to the shell if it
- finished normally. Scripts may specify return codes.
- </P
-></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="app-slon.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="slonikcommands.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-><SPAN
-CLASS="APPLICATION"
->slon</SPAN
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="c383.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Slonik Command Summary</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/dropthings.html
+++ /dev/null
@@ -1,484 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
-<HTML
-><HEAD
-><TITLE
-> Dropping things from Slony Replication</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
-REV="MADE"
-HREF="mailto:cbbrowne at gmail.com"><LINK
-REL="HOME"
-TITLE="Slony-I 1.1 Administration"
-HREF="slony.html"><LINK
-REL="UP"
-HREF="slonyadmin.html"><LINK
-REL="PREVIOUS"
-TITLE=" Adding Things to Replication"
-HREF="addthings.html"><LINK
-REL="NEXT"
-TITLE="Database Schema Changes (DDL)"
-HREF="ddlchanges.html"><LINK
-REL="STYLESHEET"
-TYPE="text/css"
-HREF="stdstyle.css"><META
-HTTP-EQUIV="Content-Type"></HEAD
-><BODY
-CLASS="SECT1"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->Slony-I 1.1 Administration</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="addthings.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="ddlchanges.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="DROPTHINGS"
->10. Dropping things from Slony Replication</A
-></H1
-><P
->There are several things you might want to do involving dropping
-things from <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> replication. </P
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN995"
->10.1. Dropping A Whole Node</A
-></H2
-><P
->If you wish to drop an entire node from replication, the <A
-HREF="app-slonik.html#SLONIK"
-> slonik </A
-> command <TT
-CLASS="COMMAND"
->DROP NODE</TT
-> should do
-the trick. </P
-><P
->This will lead to <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> dropping the triggers
-(generally that deny the ability to update data), restoring the
-"native" triggers, dropping the schema used by <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
->,
-and the slon process for that node terminating itself. </P
-><P
->As a result, the database should be available for whatever use
-your application makes of the database. </P
-><P
->This is a pretty major operation, with considerable potential to
-cause substantial destruction; make sure you drop the right node! </P
-><P
->The operation will fail if there are any nodes subscribing to
-the node that you attempt to drop, so there is a bit of a failsafe to
-protect you from errors. </P
-><P
-><A
-HREF="faq.html#FAQ17"
-> sl_log_1 isn't getting purged </A
->
-documents some extra maintenance that may need to be done on
-sl_confirm if you are running versions prior to 1.0.5. </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN1008"
->10.2. Dropping An Entire Set</A
-></H2
-><P
->If you wish to stop replicating a particular replication set,
-the <A
-HREF="app-slonik.html#SLONIK"
-> slonik </A
-> command <TT
-CLASS="COMMAND"
->DROP SET</TT
->
-is what you need to use. </P
-><P
->Much as with <TT
-CLASS="COMMAND"
->DROP NODE</TT
->, this leads to
-<SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> dropping the <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> triggers on
-the tables and restoring <SPAN
-CLASS="QUOTE"
->"native"</SPAN
-> triggers. One difference is
-that this takes place on <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->all</I
-></SPAN
-> nodes in the cluster, rather
-than on just one node. Another difference is that this does not clear
-out the <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> cluster's namespace, as there might be
-other sets being serviced. </P
-><P
->This operation is quite a bit more dangerous than <TT
-CLASS="COMMAND"
->DROP
-NODE</TT
->, as there <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->isn't</I
-></SPAN
-> the same sort of <SPAN
-CLASS="QUOTE"
->"failsafe."</SPAN
-> If
-you tell <TT
-CLASS="COMMAND"
->DROP SET</TT
-> to drop the <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->wrong</I
-></SPAN
-> set, there
-isn't anything to prevent potentially career-limiting
-<SPAN
-CLASS="QUOTE"
->"unfortunate results."</SPAN
-> Handle with care... </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN1027"
->10.3. Unsubscribing One Node From One Set</A
-></H2
-><P
->The <TT
-CLASS="COMMAND"
->UNSUBSCRIBE SET</TT
-> operation is a little less
-invasive than either <TT
-CLASS="COMMAND"
->DROP SET</TT
-> or <TT
-CLASS="COMMAND"
->DROP NODE</TT
->; it
-involves dropping <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> triggers and restoring
-"native" triggers on one node, for one replication set. </P
-><P
->Much like with <TT
-CLASS="COMMAND"
->DROP NODE</TT
->, this operation will fail if
-there is a node subscribing to the set on this node.
-
-<DIV
-CLASS="WARNING"
-><P
-></P
-><TABLE
-CLASS="WARNING"
-WIDTH="100%"
-BORDER="0"
-><TR
-><TD
-WIDTH="25"
-ALIGN="CENTER"
-VALIGN="TOP"
-><IMG
-SRC="./images/warning.gif"
-HSPACE="5"
-ALT="Warning"></TD
-><TD
-ALIGN="LEFT"
-VALIGN="TOP"
-><P
->For all of the above operations, <SPAN
-CLASS="QUOTE"
->"turning replication back
-on"</SPAN
-> will require that the node copy in a <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->full</I
-></SPAN
-> fresh set of
-the data on a provider. The fact that the data was recently being
-replicated isn't good enough; <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> will expect to
-refresh the data from scratch.</P
-></TD
-></TR
-></TABLE
-></DIV
-> </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN1041"
->10.4. Dropping A Table From A Set</A
-></H2
-><P
->In <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> 1.0.5 and above, there is a Slonik
-command <TT
-CLASS="COMMAND"
->SET DROP TABLE</TT
-> that allows dropping a single table
-from replication without forcing the user to drop the entire
-replication set. </P
-><P
->If you are running an earlier version, there is a <SPAN
-CLASS="QUOTE"
->"hack"</SPAN
->
-to do this: </P
-><P
->You can fiddle this by hand by finding the table ID for the
-table you want to get rid of, which you can find in sl_table, and then
-run the following three queries, on each host:
-
-<TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="100%"
-><TR
-><TD
-><PRE
-CLASS="PROGRAMLISTING"
-> select _slonyschema.alterTableRestore(40);
- select _slonyschema.tableDropKey(40);
- delete from _slonyschema.sl_table where tab_id = 40;</PRE
-></TD
-></TR
-></TABLE
-> </P
-><P
->The schema will obviously depend on how you defined the
-<SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> cluster. The table ID, in this case, 40, will
-need to change to the ID of the table you want to have go away. </P
-><P
->You'll have to run these three queries on all of the nodes,
-preferably firstly on the origin node, so that the dropping of this
-propagates properly. Implementing this via a <A
-HREF="app-slonik.html#SLONIK"
->slonik </A
-> statement with a new <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> event would
-do that. Submitting the three queries using <TT
-CLASS="COMMAND"
->EXECUTE SCRIPT</TT
->
-could do that; see <A
-HREF="ddlchanges.html"
-> Database Schema Changes</A
-> for more details. Also possible would be to connect to each
-database and submit the queries by hand. </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN1057"
->10.5. Dropping A Sequence From A Set</A
-></H2
-><P
->Just as with <TT
-CLASS="COMMAND"
->SET DROP TABLE</TT
->, version 1.0.5 introduces
-the operation <TT
-CLASS="COMMAND"
->SET DROP SEQUENCE</TT
->. </P
-><P
->If you are running an earlier version, here are instructions as
-to how to drop sequences: </P
-><P
->The data that needs to be deleted to stop <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
->
-from continuing to replicate the two sequences identified with
-Sequence IDs 93 and 59 are thus:
-
-<TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="100%"
-><TR
-><TD
-><PRE
-CLASS="PROGRAMLISTING"
-> delete from _oxrsorg.sl_seqlog where seql_seqid in (93, 59);
- delete from _oxrsorg.sl_sequence where seq_id in (93,59);</PRE
-></TD
-></TR
-></TABLE
-> </P
-><P
-> Those two queries could be submitted to all of the nodes via
-<CODE
-CLASS="FUNCTION"
->ddlscript()</CODE
-> / <TT
-CLASS="COMMAND"
->EXECUTE SCRIPT</TT
->,
-thus eliminating the sequence everywhere <SPAN
-CLASS="QUOTE"
->"at once."</SPAN
-> Or
-they may be applied by hand to each of the nodes.</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="addthings.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slony.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="ddlchanges.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Adding Things to Replication</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slonyadmin.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Database Schema Changes (DDL)</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/installation.html
+++ /dev/null
@@ -1,197 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->Slony-I Installation</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
-REV="MADE"
-HREF="mailto:slony1-general at gborg.postgresql.org"><LINK
-REL="HOME"
-TITLE="Slony-I HEAD_20041221 Documentation"
-HREF="index.html"><LINK
-REL="UP"
-TITLE="Slony-I Introduction"
-HREF="slonyintro.html"><LINK
-REL="PREVIOUS"
-TITLE="System Requirements"
-HREF="requirements.html"><LINK
-REL="NEXT"
-TITLE="Short Version"
-HREF="x225.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="2004-12-22T22:53:46"></HEAD
-><BODY
-CLASS="ARTICLE"
-><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
-> HEAD_20041221 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="requirements.html"
->Fast Backward</A
-></TD
-><TD
-WIDTH="60%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="commandreferencec.html"
->Fast Forward</A
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="x225.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="ARTICLE"
-><DIV
-CLASS="TITLEPAGE"
-><H1
-CLASS="TITLE"
-><A
-NAME="INSTALLATION"
->Slony-I Installation</A
-></H1
-><HR></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="AEN218"
->1. Slony-I Installation</A
-></H1
-><P
->You should have obtained the <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> source from
-the previous step. Unpack it.</P
-><PRE
-CLASS="SCREEN"
->gunzip slony.tar.gz;
-tar xf slony.tar</PRE
-><P
-> This will create a directory under the current directory with
-the <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> sources. Head into that that directory for the rest of
-the installation procedure.</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="x225.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="slonyintro.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Short Version</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/subscribenodes.html
+++ /dev/null
@@ -1,307 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
-<HTML
-><HEAD
-><TITLE
-> Subscribing Nodes</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
-REV="MADE"
-HREF="mailto:cbbrowne at gmail.com"><LINK
-REL="HOME"
-TITLE="Slony-I 1.1 Administration"
-HREF="slony.html"><LINK
-REL="UP"
-HREF="slonyadmin.html"><LINK
-REL="PREVIOUS"
-TITLE="Slon daemons"
-HREF="slonstart.html"><LINK
-REL="NEXT"
-TITLE="Monitoring"
-HREF="monitoring.html"><LINK
-REL="STYLESHEET"
-TYPE="text/css"
-HREF="stdstyle.css"><META
-HTTP-EQUIV="Content-Type"></HEAD
-><BODY
-CLASS="SECT1"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->Slony-I 1.1 Administration</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="slonstart.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="monitoring.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="SUBSCRIBENODES"
->3. Subscribing Nodes</A
-></H1
-><P
->Before you subscribe a node to a set, be sure that you have
-<B
-CLASS="APPLICATION"
-><A
-HREF="app-slon.html#SLON"
-> slon </A
-></B
->
-processes running for both the provider and the new subscribing node. If
-you don't have slons running, nothing will happen, and you'll beat
-your head against a wall trying to figure out what is going on. </P
-><P
->Subscribing a node to a set is done by issuing the <A
-HREF="app-slonik.html#SLONIK"
-> slonik </A
-> command <TT
-CLASS="COMMAND"
->subscribe set</TT
->. It
-may seem tempting to try to subscribe several nodes to a set within a
-single try block like this:
-
-<TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="100%"
-><TR
-><TD
-><PRE
-CLASS="PROGRAMLISTING"
-> try {
- echo 'Subscribing sets';
- subscribe set (id = 1, provider=1, receiver=2, forward=yes);
- subscribe set (id = 1, provider=1, receiver=3, forward=yes);
- subscribe set (id = 1, provider=1, receiver=4, forward=yes);
- } on error {
- echo 'Could not subscribe the sets!';
- exit -1;
- }</PRE
-></TD
-></TR
-></TABLE
->
- </P
-><P
-> But you are just asking for trouble if you try to subscribe
-sets in that fashion. The proper procedure is to subscribe one node at
-a time, and to check the logs and databases before you move onto
-subscribing the next node to the set. It is also worth noting that the
-<SPAN
-CLASS="QUOTE"
->"success"</SPAN
-> within the above <A
-HREF="app-slonik.html#SLONIK"
-><B
-CLASS="APPLICATION"
->slonik</B
-> </A
-> try block does not imply that nodes 2, 3,
-and 4 have all been successfully subscribed. It merely indicates that
-the slonik commands were successfully received by the
-<B
-CLASS="APPLICATION"
->slon</B
-> running on the origin node. </P
-><P
->A typical sort of problem that will arise is that a cascaded
-subscriber is looking for a provider that is not ready yet. In that
-failure case, that subscriber node will <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->never</I
-></SPAN
-> pick up the
-subscriber. It will get <SPAN
-CLASS="QUOTE"
->"stuck"</SPAN
-> waiting for a past event to
-take place. The other nodes will be convinced that it is successfully
-subscribed (because no error report ever made it back to them); a
-request to unsubscribe the node will be <SPAN
-CLASS="QUOTE"
->"blocked"</SPAN
-> because the
-node is stuck on the attempt to subscribe it. </P
-><P
->When you subscribe a node to a set, you should see something
-like this in your <B
-CLASS="APPLICATION"
->slon</B
-> logs for the provider node:
-
-<TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="100%"
-><TR
-><TD
-><PRE
-CLASS="SCREEN"
-> DEBUG2 remoteWorkerThread_3: Received event 3,1059 SUBSCRIBE_SET</PRE
-></TD
-></TR
-></TABLE
-> </P
-><P
->You should also start seeing log entries like this in the
-<B
-CLASS="APPLICATION"
->slon</B
-> logs for the subscribing node:
-
-<TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="100%"
-><TR
-><TD
-><PRE
-CLASS="SCREEN"
-> DEBUG2 remoteWorkerThread_1: copy table public.my_table</PRE
-></TD
-></TR
-></TABLE
-> </P
-><P
->It may take some time for larger tables to be copied from the
-provider node to the new subscriber. If you check the pg_stat_activity
-table on the provider node, you should see a query that is copying the
-table to stdout. </P
-><P
->The table <CODE
-CLASS="ENVAR"
->sl_subscribe</CODE
-> on both the provider, and the new
-subscriber should contain entries for the new subscription:
-
-<TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="100%"
-><TR
-><TD
-><PRE
-CLASS="SCREEN"
-> sub_set | sub_provider | sub_receiver | sub_forward | sub_active
- ---------+--------------+--------------+-------------+------------
- 1 | 1 | 2 | t | t</PRE
-></TD
-></TR
-></TABLE
-> </P
-><P
->A final test is to insert a row into one of the replicated
-tables on the origin node, and verify that the row is copied to the
-new subscriber.</P
-></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="slonstart.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slony.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="monitoring.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Slon daemons</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slonyadmin.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Monitoring</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/slony.html
+++ /dev/null
@@ -1,707 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
-<HTML
-><HEAD
-><TITLE
->Slony-I 1.1 Administration</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
-REV="MADE"
-HREF="mailto:cbbrowne at gmail.com"><LINK
-REL="NEXT"
-HREF="slonyintro.html"><LINK
-REL="STYLESHEET"
-TYPE="text/css"
-HREF="stdstyle.css"><META
-HTTP-EQUIV="Content-Type"></HEAD
-><BODY
-CLASS="BOOK"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="BOOK"
-><A
-NAME="SLONY"
-></A
-><DIV
-CLASS="TITLEPAGE"
-><H1
-CLASS="TITLE"
-><A
-NAME="SLONY"
->Slony-I 1.1 Administration</A
-></H1
-><H3
-CLASS="CORPAUTHOR"
->The Slony Global Development Group</H3
-><H3
-CLASS="AUTHOR"
-><A
-NAME="AEN5"
-></A
->Christopher Browne</H3
-><P
-CLASS="COPYRIGHT"
->Copyright © 2004-2005 The PostgreSQL Global Development Group</P
-><DIV
-CLASS="LEGALNOTICE"
-><A
-NAME="LEGALNOTICE"
-></A
-><P
-><B
->Legal Notice</B
-></P
-><P
-> <SPAN
-CLASS="PRODUCTNAME"
->PostgreSQL</SPAN
-> is Copyright © 2004-2005
- by the PostgreSQL Global Development Group and is distributed under
- the terms of the license of the University of California below.
- </P
-><P
-> Permission to use, copy, modify, and distribute this software and
- its documentation for any purpose, without fee, and without a
- written agreement is hereby granted, provided that the above
- copyright notice and this paragraph and the following two paragraphs
- appear in all copies.
- </P
-><P
-> IN NO EVENT SHALL THE UNIVERSITY OF CALIFORNIA BE LIABLE TO ANY
- PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL
- DAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS
- SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE UNIVERSITY OF CALIFORNIA
- HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- </P
-><P
-> THE UNIVERSITY OF CALIFORNIA SPECIFICALLY DISCLAIMS ANY WARRANTIES,
- INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
- MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE
- PROVIDED HEREUNDER IS ON AN <SPAN
-CLASS="QUOTE"
->"AS-IS"</SPAN
-> BASIS, AND THE
- UNIVERSITY OF CALIFORNIA HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE,
- SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
- </P
-><P
-> Note that <SPAN
-CLASS="TRADEMARK"
->UNIX</SPAN
->™ is a registered trademark of The
- Open Group. <SPAN
-CLASS="TRADEMARK"
->Windows</SPAN
->™ is a registered trademark of
- Microsoft Corporation in the United States and other countries.
- <SPAN
-CLASS="TRADEMARK"
->Solaris</SPAN
->™ is a registered trademark of Sun Microsystems,
- Inc. <SPAN
-CLASS="TRADEMARK"
->Linux</SPAN
->™ is a trademark of Linus Torvalds. </P
-></DIV
-><HR></DIV
-><DIV
-CLASS="TOC"
-><DL
-><DT
-><B
->Table of Contents</B
-></DT
-><DT
-><A
-HREF="slonyintro.html"
-></A
-></DT
-><DD
-><DL
-><DT
->1. <A
-HREF="slonyintro.html#INTRODUCTION"
->Introduction to Slony-I</A
-></DT
-><DD
-><DL
-><DT
->1.1. <A
-HREF="slonyintro.html#AEN28"
->Why yet another replication system?</A
-></DT
-><DT
->1.2. <A
-HREF="slonyintro.html#AEN31"
->What Slony-I is</A
-></DT
-><DT
->1.3. <A
-HREF="slonyintro.html#AEN42"
->Slony-I is not</A
-></DT
-><DT
->1.4. <A
-HREF="slonyintro.html#AEN48"
->Why doesn't Slony-I do automatic fail-over/promotion?</A
-></DT
-><DT
->1.5. <A
-HREF="slonyintro.html#AEN53"
->Current Limitations</A
-></DT
-><DT
->1.6. <A
-HREF="slonyintro.html#SLONYLISTENERCOSTS"
->Slony-I Communications
-Costs</A
-></DT
-></DL
-></DD
-><DT
->2. <A
-HREF="requirements.html"
->Requirements</A
-></DT
-><DD
-><DL
-><DT
->2.1. <A
-HREF="requirements.html#AEN117"
->Software needed</A
-></DT
-><DT
->2.2. <A
-HREF="requirements.html#AEN146"
->Getting <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
->
-Source</A
-></DT
-><DT
->2.3. <A
-HREF="requirements.html#AEN152"
->Time Synchronization</A
-></DT
-><DT
->2.4. <A
-HREF="requirements.html#AEN161"
->Network Connectivity</A
-></DT
-></DL
-></DD
-><DT
->3. <A
-HREF="installation.html"
->Slony-I Installation</A
-></DT
-><DD
-><DL
-><DT
->3.1. <A
-HREF="installation.html#AEN196"
->Short Version</A
-></DT
-><DT
->3.2. <A
-HREF="installation.html#AEN200"
->Configuration</A
-></DT
-><DT
->3.3. <A
-HREF="installation.html#AEN209"
->Example</A
-></DT
-><DT
->3.4. <A
-HREF="installation.html#AEN214"
->Build</A
-></DT
-><DT
->3.5. <A
-HREF="installation.html#AEN223"
->Installing Slony-I</A
-></DT
-></DL
-></DD
-><DT
->4. <A
-HREF="concepts.html"
->Slony-I Concepts</A
-></DT
-><DD
-><DL
-><DT
->4.1. <A
-HREF="concepts.html#AEN241"
->Cluster</A
-></DT
-><DT
->4.2. <A
-HREF="concepts.html#AEN249"
->Node</A
-></DT
-><DT
->4.3. <A
-HREF="concepts.html#AEN262"
->Replication Set</A
-></DT
-><DT
->4.4. <A
-HREF="concepts.html#AEN267"
->Origin, Providers and Subscribers</A
-></DT
-></DL
-></DD
-><DT
->5. <A
-HREF="cluster.html"
->Defining Slony-I Clusters</A
-></DT
-><DT
->6. <A
-HREF="definingsets.html"
->Defining Slony-I Replication
-Sets</A
-></DT
-><DD
-><DL
-><DT
->6.1. <A
-HREF="definingsets.html#AEN297"
->Primary Keys</A
-></DT
-><DT
->6.2. <A
-HREF="definingsets.html#AEN327"
->Grouping tables into sets</A
-></DT
-></DL
-></DD
-></DL
-></DD
-><DT
->I. <A
-HREF="slony-commands.html"
->Slony-I Commands</A
-></DT
-><DD
-><DL
-><DT
-><A
-HREF="app-slon.html"
-><B
-CLASS="APPLICATION"
->slon</B
-></A
-> -- <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> daemon
- </DT
-><DT
-><A
-HREF="app-slonik.html"
-><B
-CLASS="APPLICATION"
->slonik</B
-></A
-> -- <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> command processor
- </DT
-></DL
-></DD
-><DT
-><A
-HREF="slonyadmin.html"
-></A
-></DT
-><DD
-><DL
-><DT
->1. <A
-HREF="slonyadmin.html#ALTPERL"
->Slony-I Administration Scripts</A
-></DT
-><DD
-><DL
-><DT
->1.1. <A
-HREF="slonyadmin.html#AEN508"
->Node/Cluster Configuration - cluster.nodes</A
-></DT
-><DT
->1.2. <A
-HREF="slonyadmin.html#AEN534"
->Set configuration - cluster.set1, cluster.set2</A
-></DT
-><DT
->1.3. <A
-HREF="slonyadmin.html#AEN560"
->build_env.pl</A
-></DT
-><DT
->1.4. <A
-HREF="slonyadmin.html#AEN573"
->create_set.pl</A
-></DT
-><DT
->1.5. <A
-HREF="slonyadmin.html#AEN578"
->drop_node.pl</A
-></DT
-><DT
->1.6. <A
-HREF="slonyadmin.html#AEN581"
->drop_set.pl</A
-></DT
-><DT
->1.7. <A
-HREF="slonyadmin.html#AEN585"
->failover.pl</A
-></DT
-><DT
->1.8. <A
-HREF="slonyadmin.html#AEN588"
->init_cluster.pl</A
-></DT
-><DT
->1.9. <A
-HREF="slonyadmin.html#AEN591"
->merge_sets.pl</A
-></DT
-><DT
->1.10. <A
-HREF="slonyadmin.html#AEN594"
->move_set.pl</A
-></DT
-><DT
->1.11. <A
-HREF="slonyadmin.html#AEN597"
->replication_test.pl</A
-></DT
-><DT
->1.12. <A
-HREF="slonyadmin.html#AEN600"
->restart_node.pl</A
-></DT
-><DT
->1.13. <A
-HREF="slonyadmin.html#AEN603"
->restart_nodes.pl</A
-></DT
-><DT
->1.14. <A
-HREF="slonyadmin.html#AEN606"
->show_configuration.pl</A
-></DT
-><DT
->1.15. <A
-HREF="slonyadmin.html#AEN610"
->slon_kill.pl</A
-></DT
-><DT
->1.16. <A
-HREF="slonyadmin.html#AEN613"
->slon_pushsql.pl</A
-></DT
-><DT
->1.17. <A
-HREF="slonyadmin.html#AEN616"
->slon_start.pl</A
-></DT
-><DT
->1.18. <A
-HREF="slonyadmin.html#AEN619"
->slon_watchdog.pl</A
-></DT
-><DT
->1.19. <A
-HREF="slonyadmin.html#AEN622"
->slon_watchdog2.pl</A
-></DT
-><DT
->1.20. <A
-HREF="slonyadmin.html#AEN626"
->subscribe_set.pl</A
-></DT
-><DT
->1.21. <A
-HREF="slonyadmin.html#AEN629"
->uninstall_nodes.pl</A
-></DT
-><DT
->1.22. <A
-HREF="slonyadmin.html#AEN632"
->unsubscribe_set.pl</A
-></DT
-><DT
->1.23. <A
-HREF="slonyadmin.html#AEN635"
->update_nodes.pl</A
-></DT
-></DL
-></DD
-><DT
->2. <A
-HREF="slonstart.html"
->Slon daemons</A
-></DT
-><DT
->3. <A
-HREF="subscribenodes.html"
->Subscribing Nodes</A
-></DT
-><DT
->4. <A
-HREF="monitoring.html"
->Monitoring</A
-></DT
-><DD
-><DL
-><DT
->4.1. <A
-HREF="monitoring.html#AEN721"
->CONFIG notices</A
-></DT
-><DT
->4.2. <A
-HREF="monitoring.html#AEN726"
->DEBUG Notices</A
-></DT
-></DL
-></DD
-><DT
->5. <A
-HREF="maintenance.html"
->Slony-I Maintenance</A
-></DT
-><DD
-><DL
-><DT
->5.1. <A
-HREF="maintenance.html#AEN748"
->Watchdogs: Keeping Slons Running</A
-></DT
-><DT
->5.2. <A
-HREF="maintenance.html#AEN755"
->Alternative to Watchdog: generate_syncs.sh</A
-></DT
-><DT
->5.3. <A
-HREF="maintenance.html#AEN771"
->Log Files</A
-></DT
-></DL
-></DD
-><DT
->6. <A
-HREF="reshape.html"
->Reshaping a Cluster</A
-></DT
-><DT
->7. <A
-HREF="failover.html"
->Doing switchover and failover with Slony-I</A
-></DT
-><DD
-><DL
-><DT
->7.1. <A
-HREF="failover.html#AEN810"
->Foreword</A
-></DT
-><DT
->7.2. <A
-HREF="failover.html#AEN822"
->Controlled Switchover</A
-></DT
-><DT
->7.3. <A
-HREF="failover.html#AEN845"
->Failover</A
-></DT
-><DT
->7.4. <A
-HREF="failover.html#AEN876"
->After Failover, Reconfiguring node1</A
-></DT
-></DL
-></DD
-><DT
->8. <A
-HREF="listenpaths.html"
->Slony Listen Paths</A
-></DT
-><DD
-><DL
-><DT
->8.1. <A
-HREF="listenpaths.html#AEN898"
->How Listening Can Break</A
-></DT
-><DT
->8.2. <A
-HREF="listenpaths.html#AEN915"
->How The Listen Configuration Should Look</A
-></DT
-><DT
->8.3. <A
-HREF="listenpaths.html#AEN958"
->Automated Listen Path Generation</A
-></DT
-></DL
-></DD
-><DT
->9. <A
-HREF="addthings.html"
->Adding Things to Replication</A
-></DT
-><DT
->10. <A
-HREF="dropthings.html"
->Dropping things from Slony Replication</A
-></DT
-><DD
-><DL
-><DT
->10.1. <A
-HREF="dropthings.html#AEN995"
->Dropping A Whole Node</A
-></DT
-><DT
->10.2. <A
-HREF="dropthings.html#AEN1008"
->Dropping An Entire Set</A
-></DT
-><DT
->10.3. <A
-HREF="dropthings.html#AEN1027"
->Unsubscribing One Node From One Set</A
-></DT
-><DT
->10.4. <A
-HREF="dropthings.html#AEN1041"
->Dropping A Table From A Set</A
-></DT
-><DT
->10.5. <A
-HREF="dropthings.html#AEN1057"
->Dropping A Sequence From A Set</A
-></DT
-></DL
-></DD
-><DT
->11. <A
-HREF="ddlchanges.html"
->Database Schema Changes (DDL)</A
-></DT
-><DT
->12. <A
-HREF="firstdb.html"
->Replicating Your First Database</A
-></DT
-><DD
-><DL
-><DT
->12.1. <A
-HREF="firstdb.html#AEN1161"
->Creating the pgbenchuser</A
-></DT
-><DT
->12.2. <A
-HREF="firstdb.html#AEN1165"
->Preparing the databases</A
-></DT
-><DT
->12.3. <A
-HREF="firstdb.html#AEN1185"
->Configuring the Database for Replication.</A
-></DT
-></DL
-></DD
-><DT
->13. <A
-HREF="help.html"
->More Slony-I Help</A
-></DT
-><DD
-><DL
-><DT
->13.1. <A
-HREF="help.html#AEN1239"
->Other Information Sources</A
-></DT
-></DL
-></DD
-></DL
-></DD
-><DT
-><A
-HREF="faq.html"
->Slony-I FAQ</A
-></DT
-></DL
-></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"
-> </TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-> </TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="slonyintro.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-> </TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-> </TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-></TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/ddlchanges.html
+++ /dev/null
@@ -1,297 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
-<HTML
-><HEAD
-><TITLE
->Database Schema Changes (DDL)</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
-REV="MADE"
-HREF="mailto:cbbrowne at gmail.com"><LINK
-REL="HOME"
-TITLE="Slony-I 1.1 Administration"
-HREF="slony.html"><LINK
-REL="UP"
-HREF="slonyadmin.html"><LINK
-REL="PREVIOUS"
-TITLE=" Dropping things from Slony Replication"
-HREF="dropthings.html"><LINK
-REL="NEXT"
-TITLE="Replicating Your First Database"
-HREF="firstdb.html"><LINK
-REL="STYLESHEET"
-TYPE="text/css"
-HREF="stdstyle.css"><META
-HTTP-EQUIV="Content-Type"></HEAD
-><BODY
-CLASS="SECT1"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->Slony-I 1.1 Administration</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="dropthings.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="firstdb.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="DDLCHANGES"
->11. Database Schema Changes (DDL)</A
-></H1
-><P
->When changes are made to the database schema, <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->e.g.</I
-></SPAN
-> -
-adding fields to a table, it is necessary for this to be handled
-rather carefully, otherwise different nodes may get rather deranged
-because they disagree on how particular tables are built. </P
-><P
->If you pass the changes through <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> via the
-<TT
-CLASS="COMMAND"
->EXECUTE SCRIPT</TT
-> (slonik) /
-<CODE
-CLASS="FUNCTION"
->ddlscript(set,script,node)</CODE
-> (stored function), this allows
-you to be certain that the changes take effect at the same point in
-the transaction streams on all of the nodes. That may not be too
-important if you can take something of an outage to do schema changes,
-but if you want to do upgrades that take place while transactions are
-still winding their way through your systems, this is necessary. </P
-><P
->It's worth making a couple of comments on <SPAN
-CLASS="QUOTE"
->"special things"</SPAN
->
-about <TT
-CLASS="COMMAND"
->EXECUTE SCRIPT</TT
->:
-
-<P
-></P
-><UL
-><LI
-><P
-> The script must not contain transaction
-<TT
-CLASS="COMMAND"
->BEGIN</TT
-> or <TT
-CLASS="COMMAND"
->END</TT
-> statements, as the
-script is already executed inside a transaction. In
-<SPAN
-CLASS="PRODUCTNAME"
->PostgreSQL</SPAN
-> version 8, the introduction of
-nested transactions may change this requirement somewhat, but you must
-still remain aware that the actions in the script are wrapped inside a
-transaction.</P
-></LI
-><LI
-><P
-> If there is <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->anything</I
-></SPAN
-> broken
-about the script, or about how it executes on a particular node, this
-will cause the <A
-HREF="app-slon.html#SLON"
-> <B
-CLASS="APPLICATION"
->slon</B
-></A
-> daemon for that node to panic and crash. If you restart the
-node, it will, more likely than not, try to
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->repeat</I
-></SPAN
-> the DDL script, which will, almost
-certainly, fail the second time just as it did the first time. I have
-found this scenario to lead to a need to go to the
-<SPAN
-CLASS="QUOTE"
->"master"</SPAN
-> node to delete the event to stop it from
-continuing to fail.</P
-></LI
-><LI
-><P
-> For <B
-CLASS="APPLICATION"
->slon</B
-> to, at that
-point, <SPAN
-CLASS="QUOTE"
->"panic"</SPAN
-> is probably the
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->correct</I
-></SPAN
-> answer, as it allows the DBA to head over
-to the database node that is broken, and manually fix things before
-cleaning out the defective event and restarting
-<B
-CLASS="APPLICATION"
->slon</B
->. You can be certain that the updates
-made <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->after</I
-></SPAN
-> the DDL change on the provider node
-are queued up, waiting to head to the subscriber. You don't run the
-risk of there being updates made that depended on the DDL changes in
-order to be correct.</P
-></LI
-></UL
-> </P
-><P
->Unfortunately, this nonetheless implies that the use of the DDL
-facility is somewhat fragile and fairly dangerous. Making DDL changes
-must not be done in a sloppy or cavalier manner. If your applications
-do not have fairly stable SQL schemas, then using
-<SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> for replication is likely to be
-fraught with trouble and frustration.</P
-><P
->There is an article on how to manage Slony-I schema changes
-here:
-<A
-HREF="http://www.varlena.com/varlena/GeneralBits/88.php"
-TARGET="_top"
->Varlena General Bits</A
-></P
-></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="dropthings.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slony.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="firstdb.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Dropping things from Slony Replication</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slonyadmin.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Replicating Your First Database</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/cluster.html
+++ /dev/null
@@ -1,203 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->Defining Slony-I Clusters</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
-REV="MADE"
-HREF="mailto:slony1-general at gborg.postgresql.org"><LINK
-REL="HOME"
-TITLE="Slony-I HEAD_20041221 Documentation"
-HREF="index.html"><LINK
-REL="UP"
-TITLE="Slony-I Installation"
-HREF="installation.html"><LINK
-REL="PREVIOUS"
-TITLE="Slony-I Concepts"
-HREF="concepts.html"><LINK
-REL="NEXT"
-TITLE="Defining Slony-I Replication Sets"
-HREF="definingsets.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="2004-12-22T22:53:46"></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
-> HEAD_20041221 Documentation</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="concepts.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="installation.html"
->Fast Backward</A
-></TD
-><TD
-WIDTH="60%"
-ALIGN="center"
-VALIGN="bottom"
->Slony-I Installation</TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="installation.html"
->Fast Forward</A
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="definingsets.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="CLUSTER"
->8. Defining Slony-I Clusters</A
-></H1
-><P
->A <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> cluster is the basic
-grouping of database instances in which replication takes place. It
-consists of a set of <SPAN
-CLASS="PRODUCTNAME"
->PostgreSQL</SPAN
-> database
-instances in which is defined a namespace specific to that
-cluster.</P
-><P
->Each database instance in which replication is to take place is
-identified by a node number.</P
-><P
->For a simple install, it may be reasonable for the origin to be
-node #1, and for the subscriber to be node #2.</P
-><P
->Some planning should be done, in more complex cases, to ensure
-that the numbering system is kept sane, lest the administrators be
-driven insane. The node numbers should be chosen to somehow
-correspond to the shape of the environment, as opposed to (say) the
-order in which nodes were initialized.</P
-><P
->It may be that in version 1.1, nodes will also have a
-<SPAN
-CLASS="QUOTE"
->"name"</SPAN
-> attribute, so that they may be given more mnemonic names.
-In that case, the node numbers might remain somewhat cryptic; it will
-be the node name that is used to organize the cluster.</P
-></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="concepts.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="definingsets.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-><SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> Concepts</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="installation.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Defining Slony-I Replication Sets</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/slonstart.html
+++ /dev/null
@@ -1,328 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
-<HTML
-><HEAD
-><TITLE
->Slon daemons</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
-REV="MADE"
-HREF="mailto:cbbrowne at gmail.com"><LINK
-REL="HOME"
-TITLE="Slony-I 1.1 Administration"
-HREF="slony.html"><LINK
-REL="UP"
-HREF="slonyadmin.html"><LINK
-REL="PREVIOUS"
-HREF="slonyadmin.html"><LINK
-REL="NEXT"
-TITLE=" Subscribing Nodes"
-HREF="subscribenodes.html"><LINK
-REL="STYLESHEET"
-TYPE="text/css"
-HREF="stdstyle.css"><META
-HTTP-EQUIV="Content-Type"></HEAD
-><BODY
-CLASS="SECT1"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->Slony-I 1.1 Administration</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="slonyadmin.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="subscribenodes.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="SLONSTART"
->2. Slon daemons</A
-></H1
-><P
->The programs that actually perform <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> replication are the
-<B
-CLASS="APPLICATION"
->slon</B
-> daemons. </P
-><P
->You need to run one <B
-CLASS="APPLICATION"
-><A
-HREF="app-slon.html#SLON"
-> slon</A
-></B
-> instance for each node in a
-<SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> cluster, whether you consider that node a
-<SPAN
-CLASS="QUOTE"
->"master"</SPAN
-> or a <SPAN
-CLASS="QUOTE"
->"slave."</SPAN
-> Since a <TT
-CLASS="COMMAND"
->MOVE SET</TT
-> or
-<TT
-CLASS="COMMAND"
->FAILOVER</TT
-> 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:
-
-<P
-></P
-><UL
-><LI
-><P
-> Each <B
-CLASS="APPLICATION"
->slon</B
-> needs to be able to
-communicate quickly with the database whose <SPAN
-CLASS="QUOTE"
->"node controller"</SPAN
-> it
-is. Therefore, if a <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> 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 <SPAN
-CLASS="QUOTE"
->"own node"</SPAN
-> will cause it to
-replicate in a <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->somewhat</I
-></SPAN
-> less timely manner. </P
-></LI
-><LI
-><P
-> The very fastest results would be achieved by having
-each <B
-CLASS="APPLICATION"
->slon</B
-> run on the database server that it is
-servicing. If it runs somewhere within a fast local network,
-performance will not be noticeably degraded. </P
-></LI
-><LI
-><P
-> It is an attractive idea to run many of the
-<B
-CLASS="APPLICATION"
->slon</B
-> 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
-<B
-CLASS="APPLICATION"
->slon</B
-> instances. </P
-></LI
-></UL
-> </P
-><P
->There are two <SPAN
-CLASS="QUOTE"
->"watchdog"</SPAN
-> scripts currently available:
-
-<P
-></P
-><UL
-><LI
-><P
-> <TT
-CLASS="FILENAME"
->tools/altperl/slon_watchdog.pl</TT
-> -
-an <SPAN
-CLASS="QUOTE"
->"early"</SPAN
-> version that basically wraps a loop around the
-invocation of <B
-CLASS="APPLICATION"
-><A
-HREF="app-slon.html#SLON"
-> slon</A
-></B
->, restarting any time it falls over</P
-></LI
-><LI
-><P
-> <TT
-CLASS="FILENAME"
->tools/altperl/slon_watchdog2.pl</TT
->
-- a somewhat more intelligent version that periodically polls the
-database, checking to see if a <TT
-CLASS="COMMAND"
->SYNC</TT
-> has taken place
-recently. We have had VPN connections that occasionally fall over
-without signalling the application, so that the <B
-CLASS="APPLICATION"
-><A
-HREF="app-slon.html#SLON"
-> slon </A
-></B
-> stops working, but doesn't
-actually die; this polling addresses that issue. </P
-></LI
-></UL
-> </P
-><P
->The <TT
-CLASS="FILENAME"
->slon_watchdog2.pl</TT
-> script is probably
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->usually</I
-></SPAN
-> 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 <TT
-CLASS="COMMAND"
->COPY SET</TT
->. The problem that came up in that
-case was that it figured that since it hasn't done a
-<TT
-CLASS="COMMAND"
->SYNC</TT
-> in 2 hours, something was broken requiring
-restarting slon, thereby restarting the <TT
-CLASS="COMMAND"
->COPY SET</TT
->
-event. More recently, the script has been changed to detect
-<TT
-CLASS="COMMAND"
->COPY SET</TT
-> in progress.</P
-></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="slonyadmin.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slony.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="subscribenodes.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slonyadmin.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Subscribing Nodes</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/slonik.html
+++ /dev/null
@@ -1,276 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
-<HTML
-><HEAD
-><TITLE
->slonik</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
-REV="MADE"
-HREF="mailto:cbbrowne at gmail.com"><LINK
-REL="HOME"
-TITLE="Slony-I 1.1 Administration"
-HREF="slony.html"><LINK
-REL="UP"
-TITLE="Slony-I Commands"
-HREF="slony-commands.html"><LINK
-REL="PREVIOUS"
-TITLE="slon"
-HREF="slon.html"><LINK
-REL="NEXT"
-HREF="slonyadmin.html"><LINK
-REL="STYLESHEET"
-TYPE="text/css"
-HREF="stdstyle.css"><META
-HTTP-EQUIV="Content-Type"></HEAD
-><BODY
-CLASS="REFENTRY"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->Slony-I 1.1 Administration</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="slon.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="slonyadmin.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><H1
-><A
-NAME="SLONIK"
-></A
-><B
-CLASS="APPLICATION"
->slonik</B
-></H1
-><DIV
-CLASS="REFNAMEDIV"
-><A
-NAME="AEN416"
-></A
-><H2
->Name</H2
-><B
-CLASS="APPLICATION"
->slonik</B
-> -- <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> command processor
- </DIV
-><DIV
-CLASS="REFSYNOPSISDIV"
-><A
-NAME="AEN423"
-></A
-><H2
->Synopsis</H2
-><P
-><TT
-CLASS="COMMAND"
->slonik</TT
-> [<TT
-CLASS="REPLACEABLE"
-><I
->filename</I
-></TT
->
- ]</P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN428"
-></A
-><H2
->Description</H2
-><P
-> <B
-CLASS="APPLICATION"
->slonik</B
-> is the command processor
- application that is used to set up and modify configurations of
- <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> replication clusters.
- </P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN433"
-></A
-><H2
-> Outline</H2
-><P
->The slonik command line utility is supposed to be used
- embedded into shell scripts and reads commands from files or
- stdin.</P
-><P
->It reads a set of Slonik statements, which are written in a
- scripting language with syntax similar to that of SQL, and performs
- the set of configuration changes on the slony nodes specified in the
- script.</P
-><P
->Nearly all of the real configuration work is actually done by
- calling stored procedures after loading the Slony-I support base
- into a database. Slonik was created because these stored procedures
- have special requirements as to on which particular node in the
- replication system they are called. The absence of named parameters
- for stored procedures makes it rather hard to do this from the psql
- prompt, and psql lacks the ability to maintain multiple connections
- with open transactions to multiple databases.</P
-><P
->The format of the Slonik <SPAN
-CLASS="QUOTE"
->"language"</SPAN
-> is very similar to
- that of SQL, and the parser is based on a similar set of formatting
- rules for such things as numbers and strings. Note that slonik is
- declarative, using literal values throughout, and does
- <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->not</I
-></SPAN
-> have the notion of variables. It is
- anticipated that Slonik scripts will typically be
- <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->generated</I
-></SPAN
-> by scripts, such as Bash or Perl, and
- these sorts of scripting languages already have perfectly good ways
- of managing variables.</P
-><P
->A detailed list of Slonik commands can be found here: <A
-HREF="http://gborg.postgresql.org/project/slony1/genpage.php?slonik_commands"
-TARGET="_top"
-> slonik commands </A
-></P
-></DIV
-><DIV
-CLASS="REFSECT1"
-><A
-NAME="AEN444"
-></A
-><H2
->Exit Status</H2
-><P
-> <B
-CLASS="APPLICATION"
->slonik</B
-> returns 0 to the shell if it
- finished normally. Scripts may specify return codes.
- </P
-></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="slon.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slony.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="slonyadmin.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-><B
-CLASS="APPLICATION"
->slon</B
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slony-commands.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-></TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/listenpaths.html
+++ /dev/null
@@ -1,571 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
-<HTML
-><HEAD
-><TITLE
-> Slony Listen Paths</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
-REV="MADE"
-HREF="mailto:cbbrowne at gmail.com"><LINK
-REL="HOME"
-TITLE="Slony-I 1.1 Administration"
-HREF="slony.html"><LINK
-REL="UP"
-HREF="slonyadmin.html"><LINK
-REL="PREVIOUS"
-TITLE="Doing switchover and failover with Slony-I"
-HREF="failover.html"><LINK
-REL="NEXT"
-TITLE=" Adding Things to Replication"
-HREF="addthings.html"><LINK
-REL="STYLESHEET"
-TYPE="text/css"
-HREF="stdstyle.css"><META
-HTTP-EQUIV="Content-Type"></HEAD
-><BODY
-CLASS="SECT1"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->Slony-I 1.1 Administration</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="failover.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="addthings.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="LISTENPATHS"
->8. Slony Listen Paths</A
-></H1
-><DIV
-CLASS="NOTE"
-><P
-></P
-><TABLE
-CLASS="NOTE"
-WIDTH="100%"
-BORDER="0"
-><TR
-><TD
-WIDTH="25"
-ALIGN="CENTER"
-VALIGN="TOP"
-><IMG
-SRC="./images/note.gif"
-HSPACE="5"
-ALT="Note"></TD
-><TD
-ALIGN="LEFT"
-VALIGN="TOP"
-><P
-> If you are running version <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> 1.1, it
-should be <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->completely unnecessary</I
-></SPAN
-> to read this section as it
-introduces a way to automatically manage this part of its
-configuration. For earlier versions, however, it is needful...</P
-></TD
-></TR
-></TABLE
-></DIV
-><P
->If you have more than two or three nodes, and any degree of
-usage of cascaded subscribers (<SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->e.g.</I
-></SPAN
-> - subscribers that are
-subscribing through a subscriber node), you will have to be fairly
-careful about the configuration of <SPAN
-CLASS="QUOTE"
->"listen paths"</SPAN
-> via the Slonik <TT
-CLASS="COMMAND"
->STORE
-LISTEN</TT
-> and <TT
-CLASS="COMMAND"
->DROP LISTEN</TT
-> statements that control the contents of the
-table sl_listen. </P
-><P
->The <SPAN
-CLASS="QUOTE"
->"listener"</SPAN
-> entries in this table control where each
-node expects to listen in order to get events propagated from other
-nodes. You might think that nodes only need to listen to the
-<SPAN
-CLASS="QUOTE"
->"parent"</SPAN
-> from whom they are getting updates, but in reality,
-they need to be able to receive messages from <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->all</I
-></SPAN
-> nodes in
-order to be able to conclude that SYNCs have been received everywhere,
-and that, therefore, entries in sl_log_1 and sl_log_2 have been
-applied everywhere, and can therefore be purged. This extra
-communication is needful so <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> is able to shift
-origins to other locations. </P
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN898"
->8.1. How Listening Can Break</A
-></H2
-><P
->On one occasion, I had a need to drop a subscriber node (#2) and
-recreate it. That node was the data provider for another subscriber
-(#3) that was, in effect, a <SPAN
-CLASS="QUOTE"
->"cascaded slave."</SPAN
-> Dropping the
-subscriber node initially didn't work, as <A
-HREF="app-slonik.html#SLONIK"
-><TT
-CLASS="COMMAND"
->slonik</TT
-> </A
-> informed me that there was a dependant node.
-I repointed the dependant node to the <SPAN
-CLASS="QUOTE"
->"master"</SPAN
-> node for the
-subscription set, which, for a while, replicated without difficulties. </P
-><P
->I then dropped the subscription on <SPAN
-CLASS="QUOTE"
->"node 2,"</SPAN
-> and started
-resubscribing it. That raised the <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
->
-<TT
-CLASS="COMMAND"
->SET_SUBSCRIPTION</TT
-> event, which started copying tables. At
-that point in time, events stopped propagating to <SPAN
-CLASS="QUOTE"
->"node 3,"</SPAN
-> and
-while it was in perfectly OK shape, no events were making it to it. </P
-><P
->The problem was that node #3 was expecting to receive events
-from node #2, which was busy processing the <TT
-CLASS="COMMAND"
->SET_SUBSCRIPTION</TT
->
-event, and was not passing anything else on. </P
-><P
->We dropped the listener rules that caused node #3 to listen to
-node 2, replacing them with rules where it expected its events to come
-from node #1 (the origin node for the replication set). At that
-moment, <SPAN
-CLASS="QUOTE"
->"as if by magic,"</SPAN
-> node #3 started replicating again, as
-it discovered a place to get <TT
-CLASS="COMMAND"
->SYNC</TT
-> events. </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN915"
->8.2. How The Listen Configuration Should Look</A
-></H2
-><P
->The simple cases tend to be simple to cope with. We need to
-instead look at a more complex node configuration. </P
-><P
->Consider a set of nodes, 1 thru 6, where 1 is the origin,
-where 2-4 subscribe directly to the origin, and where 5 subscribes to
-2, and 6 subscribes to 5. </P
-><P
->Here is a <SPAN
-CLASS="QUOTE"
->"listener network"</SPAN
-> that indicates where each
-node should listen for messages coming from each other node:
-
-<TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="100%"
-><TR
-><TD
-><PRE
-CLASS="SCREEN"
-> 1| 2| 3| 4| 5| 6|
- --------------------------------------------
- 1 0 2 3 4 2 2
- 2 1 0 1 1 5 5
- 3 1 1 0 1 1 1
- 4 1 1 1 0 1 1
- 5 2 2 2 2 0 6
- 6 5 5 5 5 5 0 </PRE
-></TD
-></TR
-></TABLE
-> </P
-><P
->Row 2 indicates all of the listen rules for node 2; it gets
-events for nodes 1, 3, and 4 throw node 1, and gets events for nodes 5
-and 6 from node 5. </P
-><P
->The row of 5's at the bottom, for node 6, indicate that node 6
-listens to node 5 to get events from nodes 1-5. </P
-><P
->The set of slonik <TT
-CLASS="COMMAND"
->SET LISTEN</TT
-> statements to express
-this <SPAN
-CLASS="QUOTE"
->"listener network"</SPAN
-> are as follows:
-
-<TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="100%"
-><TR
-><TD
-><PRE
-CLASS="PROGRAMLISTING"
-> store listen (origin = 1, receiver = 2, provider = 1);
- store listen (origin = 1, receiver = 3, provider = 1);
- store listen (origin = 1, receiver = 4, provider = 1);
- store listen (origin = 1, receiver = 5, provider = 2);
- store listen (origin = 1, receiver = 6, provider = 5);
- store listen (origin = 2, receiver = 1, provider = 2);
- store listen (origin = 2, receiver = 3, provider = 1);
- store listen (origin = 2, receiver = 4, provider = 1);
- store listen (origin = 2, receiver = 5, provider = 2);
- store listen (origin = 2, receiver = 6, provider = 5);
- store listen (origin = 3, receiver = 1, provider = 3);
- store listen (origin = 3, receiver = 2, provider = 1);
- store listen (origin = 3, receiver = 4, provider = 1);
- store listen (origin = 3, receiver = 5, provider = 2);
- store listen (origin = 3, receiver = 6, provider = 5);
- store listen (origin = 4, receiver = 1, provider = 4);
- store listen (origin = 4, receiver = 2, provider = 1);
- store listen (origin = 4, receiver = 3, provider = 1);
- store listen (origin = 4, receiver = 5, provider = 2);
- store listen (origin = 4, receiver = 6, provider = 5);
- store listen (origin = 5, receiver = 1, provider = 2);
- store listen (origin = 5, receiver = 2, provider = 5);
- store listen (origin = 5, receiver = 3, provider = 1);
- store listen (origin = 5, receiver = 4, provider = 1);
- store listen (origin = 5, receiver = 6, provider = 5);
- store listen (origin = 6, receiver = 1, provider = 2);
- store listen (origin = 6, receiver = 2, provider = 5);
- store listen (origin = 6, receiver = 3, provider = 1);
- store listen (origin = 6, receiver = 4, provider = 1);
- store listen (origin = 6, receiver = 5, provider = 6);</PRE
-></TD
-></TR
-></TABLE
-> </P
-><P
->How we read these listen statements is thus... </P
-><P
->When on the <SPAN
-CLASS="QUOTE"
->"receiver"</SPAN
-> node, look to the <SPAN
-CLASS="QUOTE"
->"provider"</SPAN
->
-node to provide events coming from the <SPAN
-CLASS="QUOTE"
->"origin"</SPAN
-> node. </P
-><P
->The tool <TT
-CLASS="FILENAME"
->init_cluster.pl</TT
-> in the <TT
-CLASS="FILENAME"
->altperl</TT
->
-scripts produces optimized listener networks in both the tabular form
-shown above as well as in the form of <A
-HREF="app-slonik.html#SLONIK"
-><B
-CLASS="APPLICATION"
->slonik</B
-> </A
-> statements. </P
-><P
->There are three <SPAN
-CLASS="QUOTE"
->"thorns"</SPAN
-> in this set of roses:
-
-<P
-></P
-><UL
-><LI
-><P
-> If you change the shape of the node set, so that the
-nodes subscribe differently to things, you need to drop sl_listen
-entries and create new ones to indicate the new preferred paths
-between nodes. Until <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
->, there is no automated way
-at this point to do this <SPAN
-CLASS="QUOTE"
->"reshaping."</SPAN
-> </P
-></LI
-><LI
-><P
-> If you <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->don't</I
-></SPAN
-> change the sl_listen entries,
-events will likely continue to propagate so long as all of the nodes
-continue to run well. The problem will only be noticed when a node is
-taken down, <SPAN
-CLASS="QUOTE"
->"orphaning"</SPAN
-> any nodes that are listening through it. </P
-></LI
-><LI
-><P
-> You might have multiple replication sets that have
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->different</I
-></SPAN
-> shapes for their respective trees of subscribers.
-There won't be a single <SPAN
-CLASS="QUOTE"
->"best"</SPAN
-> listener configuration in that
-case. </P
-></LI
-><LI
-><P
-> In order for there to be an sl_listen path, there
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->must</I
-></SPAN
-> be a series of sl_path entries connecting the origin
-to the receiver. This means that if the contents of sl_path do not
-express a <SPAN
-CLASS="QUOTE"
->"connected"</SPAN
-> network of nodes, then some nodes will not
-be reachable. This would typically happen, in practice, when you have
-two sets of nodes, one in one subnet, and another in another subnet,
-where there are only a couple of <SPAN
-CLASS="QUOTE"
->"firewall"</SPAN
-> nodes that can talk
-between the subnets. Cut out those nodes and the subnets stop
-communicating. </P
-></LI
-></UL
-> </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN958"
->8.3. Automated Listen Path Generation</A
-></H2
-><P
-> In <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> version 1.1, a heuristic scheme is
-introduced to automatically generate listener entries. This happens,
-in order, based on three data sources:
-
-<P
-></P
-><UL
-><LI
-><P
-> sl_subscribe entries are the first, most vital
-control as to what listens to what; we <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->know</I
-></SPAN
-> there must be a
-direct path between each subscriber node and its provider. </P
-></LI
-><LI
-><P
-> sl_path entries are the second indicator; if
-sl_subscribe has not already indicated <SPAN
-CLASS="QUOTE"
->"how to listen,"</SPAN
-> then a
-node may listen directly to the event's origin if there is a suitable
-sl_path entry. </P
-></LI
-><LI
-><P
-> Lastly, if there has been no guidance thus far based
-on the above data sources, then nodes can listen indirectly via every
-node that is either a provider for the receiver, or that is using the
-receiver as a provider. </P
-></LI
-></UL
-> </P
-><P
-> Any time sl_subscribe or sl_path are modified,
-<CODE
-CLASS="FUNCTION"
->RebuildListenEntries()</CODE
-> will be called to revise
-the listener paths.</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="failover.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slony.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="addthings.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Doing switchover and failover with Slony-I</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slonyadmin.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Adding Things to Replication</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/x267.html
+++ /dev/null
@@ -1,317 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
-<HTML
-><HEAD
-><TITLE
->Defining Slony-I Replication Sets</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
-REV="MADE"
-HREF="mailto:cbbrowne at gmail.com"><LINK
-REL="HOME"
-TITLE="Slony-I 1.1 Administration"
-HREF="slony.html"><LINK
-REL="UP"
-HREF="t24.html"><LINK
-REL="PREVIOUS"
-TITLE="Defining Slony-I Clusters"
-HREF="cluster.html"><LINK
-REL="NEXT"
-TITLE=" Slony-I Administration Scripts"
-HREF="altperl.html"><LINK
-REL="STYLESHEET"
-TYPE="text/css"
-HREF="stdstyle.css"><META
-HTTP-EQUIV="Content-Type"></HEAD
-><BODY
-CLASS="SECT1"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->Slony-I 1.1 Administration</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="cluster.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="altperl.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="AEN267"
->7. Defining Slony-I Replication Sets</A
-></H1
-><P
->Defining the nodes indicated the shape of the cluster of
-database servers; it is now time to determine what data is to be
-copied between them. The groups of data that are copied are defined
-as "sets." </P
-><P
->A replication set consists of the following:
-<P
-></P
-><UL
-><LI
-><P
-> Keys on tables that are to be replicated that have no
-suitable primary key</P
-></LI
-><LI
-><P
-> Tables that are to be replicated</P
-></LI
-><LI
-><P
-> Sequences that are to be
-replicated</P
-></LI
-></UL
-> </P
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN278"
->7.1. Primary Keys</A
-></H2
-><P
->Slony-I <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->needs</I
-></SPAN
-> to have a primary key on each
-table that is replicated. PK values are used as the primary
-identifier for each tuple that is modified in the source system.
-There are three ways that you can get Slony-I to use a primary key:
-
-<P
-></P
-><UL
-><LI
-><P
-> If the table has a formally identified primary key,
-<TT
-CLASS="COMMAND"
->SET ADD TABLE</TT
-> can be used without any need to reference the
-primary key. <B
-CLASS="APPLICATION"
->Slony-I</B
-> will pick up that there is a
-primary key, and use it. </P
-></LI
-><LI
-><P
-> If the table hasn't got a primary key, but has some
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->candidate</I
-></SPAN
-> primary key, that is, some index on a combination
-of fields that is UNIQUE and NOT NULL, then you can specify the key,
-as in </P
-><P
-><TT
-CLASS="COMMAND"
->SET ADD TABLE (set id = 1, origin = 1, id = 42, full qualified name = 'public.this_table', key = 'this_by_that', comment='this_table has this_by_that as a candidate primary key');</TT
-> </P
-><P
-> Notice that while you need to specify the namespace for the table, you must <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->not</I
-></SPAN
-> specify the namespace for the key, as it infers the namespace from the table. </P
-></LI
-><LI
-><P
-> If the table hasn't even got a candidate primary key,
-you can ask Slony-I to provide one. This is done by first using
-<TT
-CLASS="COMMAND"
->TABLE ADD KEY</TT
-> to add a column populated using a Slony-I
-sequence, and then having the <TT
-CLASS="COMMAND"
->SET ADD TABLE</TT
-> include the
-directive <CODE
-CLASS="OPTION"
->key=serial</CODE
->, to indicate that
-<B
-CLASS="APPLICATION"
->Slony-I</B
->'s own column should be
-used.</P
-></LI
-></UL
-> </P
-><P
-> It is not terribly important whether you pick a
-<SPAN
-CLASS="QUOTE"
->"true"</SPAN
-> primary key or a mere <SPAN
-CLASS="QUOTE"
->"candidate primary
-key;"</SPAN
-> it is, however, recommended that you have one of those
-instead of having Slony-I populate the PK column for you. If you
-don't have a suitable primary key, that means that the table hasn't
-got any mechanism from your application's standpoint of keeping values
-unique. Slony-I may therefore introduce a new failure mode for your
-application, and this implies that you had a way to enter confusing
-data into the database. </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN303"
->7.2. Grouping tables into sets</A
-></H2
-><P
-> It will be vital to group tables together into a single set if
-those tables are related via foreign key constraints. If tables that
-are thus related are <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->not</I
-></SPAN
-> replicated together,
-you'll find yourself in trouble if you switch the <SPAN
-CLASS="QUOTE"
->"master
-provider"</SPAN
-> from one node to another, and discover that the new
-<SPAN
-CLASS="QUOTE"
->"master"</SPAN
-> can't be updated properly because it is missing the
-contents of dependent tables. </P
-><P
-> If a database schema has been designed cleanly, it is likely
-that replication sets will be virtually synonymous with namespaces.
-All of the tables and sequences in a particular namespace will be
-sufficiently related that you will want to replicate them all.
-Conversely, tables found in different schemas will likely NOT be
-related, and therefore should be replicated in separate sets.
-
-
- </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="cluster.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slony.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="altperl.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Defining Slony-I Clusters</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="t24.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Slony-I Administration Scripts</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/definingsets.html
+++ /dev/null
@@ -1,372 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<HTML
-><HEAD
-><TITLE
->Defining Slony-I Replication Sets</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
-REV="MADE"
-HREF="mailto:slony1-general at gborg.postgresql.org"><LINK
-REL="HOME"
-TITLE="Slony-I HEAD_20041221 Documentation"
-HREF="index.html"><LINK
-REL="UP"
-TITLE="Slony-I Installation"
-HREF="installation.html"><LINK
-REL="PREVIOUS"
-TITLE="Defining Slony-I Clusters"
-HREF="cluster.html"><LINK
-REL="NEXT"
-TITLE="Core Slony-I Programs"
-HREF="commandreferencec.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="2004-12-22T22:53:46"></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
-> HEAD_20041221 Documentation</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="cluster.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="installation.html"
->Fast Backward</A
-></TD
-><TD
-WIDTH="60%"
-ALIGN="center"
-VALIGN="bottom"
->Slony-I Installation</TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="installation.html"
->Fast Forward</A
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="commandreferencec.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="DEFININGSETS"
->9. Defining Slony-I Replication Sets</A
-></H1
-><P
->Defining the nodes indicated the shape of the cluster of
-database servers; it is now time to determine what data is to be
-copied between them. The groups of data that are copied are defined
-as <SPAN
-CLASS="QUOTE"
->"sets."</SPAN
-></P
-><P
->A replication set consists of the following:</P
-><P
-></P
-><UL
-><LI
-><P
->Keys on tables that are to be replicated that have no
-suitable primary key</P
-></LI
-><LI
-><P
->Tables that are to be replicated</P
-></LI
-><LI
-><P
->Sequences that are to be replicated</P
-></LI
-></UL
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN339"
->9.1. Primary Keys</A
-></H2
-><P
-><SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->needs</I
-></SPAN
-> to have a
-primary key or candidate thereof on each table that is replicated. PK
-values are used as the primary identifier for each tuple that is
-modified in the source system. There are three ways that you can get
-<SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> to use a primary key:</P
-><P
-></P
-><UL
-><LI
-><P
-> If the table has a formally identified primary key, <TT
-CLASS="COMMAND"
-><A
-HREF="stmtsetaddtable.html"
->SET ADD
-TABLE</A
-></TT
-> can be used without any need to reference the
-primary key. <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> will pick up that there is a
-primary key, and use it.</P
-></LI
-><LI
-><P
-> If the table hasn't got a primary key, but has some
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->candidate</I
-></SPAN
-> primary key, that is, some index on a
-combination of fields that is UNIQUE and NOT NULL, then you can
-specify the key, as in</P
-><PRE
-CLASS="PROGRAMLISTING"
->SET ADD TABLE (set id = 1, origin = 1, id = 42,
- full qualified name = 'public.this_table',
- key = 'this_by_that',
- comment='this_table has this_by_that as a candidate primary key');</PRE
-><P
-> Notice that while you need to specify the namespace for the
-table, you must <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->not</I
-></SPAN
-> specify the namespace for the
-key, as it infers the namespace from the table.</P
-></LI
-><LI
-><P
-> If the table hasn't even got a candidate primary key,
-you can ask <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> to provide one. This is done by
-first using <TT
-CLASS="COMMAND"
-><A
-HREF="stmttableaddkey.html"
-> TABLE ADD KEY</A
-> </TT
-> to add a column populated using a
-<SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> sequence, and then having the <TT
-CLASS="COMMAND"
-> <A
-HREF="stmtsetaddtable.html"
-> SET ADD TABLE</A
-></TT
-> include the
-directive <TT
-CLASS="OPTION"
->key=serial</TT
->, to indicate that
-<SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
->'s own column should be used.</P
-></LI
-></UL
-><P
-> It is not terribly important whether you pick a
-<SPAN
-CLASS="QUOTE"
->"true"</SPAN
-> primary key or a mere <SPAN
-CLASS="QUOTE"
->"candidate primary
-key;"</SPAN
-> it is, however, recommended that you have one of those
-instead of having <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> populate the PK column for
-you. If you don't have a suitable primary key, that means that the
-table hasn't got any mechanism from your application's standpoint of
-keeping values unique. <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> may therefore introduce
-a new failure mode for your application, and this implies that you had
-a way to enter confusing data into the database.</P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN372"
->9.2. Grouping tables into sets</A
-></H2
-><P
-> It will be vital to group tables together into a single set if
-those tables are related via foreign key constraints. If tables that
-are thus related are <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->not</I
-></SPAN
-> replicated together,
-you'll find yourself in trouble if you switch the <SPAN
-CLASS="QUOTE"
->"master
-provider"</SPAN
-> from one node to another, and discover that the new
-<SPAN
-CLASS="QUOTE"
->"master"</SPAN
-> can't be updated properly because it is missing
-the contents of dependent tables.</P
-><P
-> If a database schema has been designed cleanly, it is likely
-that replication sets will be virtually synonymous with namespaces.
-All of the tables and sequences in a particular namespace will be
-sufficiently related that you will want to replicate them all.
-Conversely, tables found in different schemas will likely
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->not</I
-></SPAN
-> be related, and therefore should be replicated in
-separate sets.</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="cluster.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="commandreferencec.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Defining Slony-I Clusters</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="installation.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Core <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> Programs</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/firstdb.html
+++ /dev/null
@@ -1,747 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
-<HTML
-><HEAD
-><TITLE
->Replicating Your First Database</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
-REV="MADE"
-HREF="mailto:cbbrowne at gmail.com"><LINK
-REL="HOME"
-TITLE="Slony-I 1.1 Administration"
-HREF="slony.html"><LINK
-REL="UP"
-HREF="slonyadmin.html"><LINK
-REL="PREVIOUS"
-TITLE="Database Schema Changes (DDL)"
-HREF="ddlchanges.html"><LINK
-REL="NEXT"
-TITLE=" More Slony-I Help "
-HREF="help.html"><LINK
-REL="STYLESHEET"
-TYPE="text/css"
-HREF="stdstyle.css"><META
-HTTP-EQUIV="Content-Type"></HEAD
-><BODY
-CLASS="SECT1"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->Slony-I 1.1 Administration</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="ddlchanges.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="help.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="FIRSTDB"
->12. Replicating Your First Database</A
-></H1
-><P
->In this example, we will be replicating a brand new pgbench
-database. The mechanics of replicating an existing database are
-covered here, however we recommend that you learn how
-<SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> functions by using a fresh new
-non-production database.</P
-><P
->The <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> replication engine is
-trigger-based, allowing us to replicate databases (or portions
-thereof) running under the same postmaster.</P
-><P
->This example will show how to replicate the pgbench database
-running on localhost (master) to the pgbench slave database also
-running on localhost (slave). We make a couple of assumptions about
-your PostgreSQL configuration:
-
-<P
-></P
-><UL
-><LI
-><P
-> You have <CODE
-CLASS="OPTION"
->tcpip_socket=true</CODE
-> in your
-<TT
-CLASS="FILENAME"
->postgresql.conf</TT
-> and</P
-></LI
-><LI
-><P
-> You have enabled access in your cluster(s) via
-<TT
-CLASS="FILENAME"
->pg_hba.conf</TT
-></P
-></LI
-></UL
-></P
-><P
-> The <CODE
-CLASS="ENVAR"
->REPLICATIONUSER</CODE
-> needs to be a PostgreSQL superuser.
-This is typically postgres or pgsql.</P
-><P
->You should also set the following shell variables:
-
-<P
-></P
-><UL
-><LI
-><P
-> <CODE
-CLASS="ENVAR"
->CLUSTERNAME</CODE
->=slony_example</P
-></LI
-><LI
-><P
-> <CODE
-CLASS="ENVAR"
->MASTERDBNAME</CODE
->=pgbench</P
-></LI
-><LI
-><P
-> <CODE
-CLASS="ENVAR"
->SLAVEDBNAME</CODE
->=pgbenchslave</P
-></LI
-><LI
-><P
-> <CODE
-CLASS="ENVAR"
->MASTERHOST</CODE
->=localhost</P
-></LI
-><LI
-><P
-> <CODE
-CLASS="ENVAR"
->SLAVEHOST</CODE
->=localhost</P
-></LI
-><LI
-><P
-> <CODE
-CLASS="ENVAR"
->REPLICATIONUSER</CODE
->=pgsql</P
-></LI
-><LI
-><P
-> <CODE
-CLASS="ENVAR"
->PGBENCHUSER</CODE
->=pgbench</P
-></LI
-></UL
-></P
-><P
->Here are a couple of examples for setting variables in common shells:
-
-<P
-></P
-><UL
-><LI
-><P
-> bash, sh, ksh
- <TT
-CLASS="COMMAND"
->export CLUSTERNAME=slony_example</TT
-></P
-></LI
-><LI
-><P
-> (t)csh:
- <TT
-CLASS="COMMAND"
->setenv CLUSTERNAME slony_example</TT
-></P
-></LI
-></UL
-> </P
-><P
-><DIV
-CLASS="WARNING"
-><P
-></P
-><TABLE
-CLASS="WARNING"
-WIDTH="100%"
-BORDER="0"
-><TR
-><TD
-WIDTH="25"
-ALIGN="CENTER"
-VALIGN="TOP"
-><IMG
-SRC="./images/warning.gif"
-HSPACE="5"
-ALT="Warning"></TD
-><TD
-ALIGN="LEFT"
-VALIGN="TOP"
-><P
-> If you're changing these variables to use
-different hosts for <CODE
-CLASS="ENVAR"
->MASTERHOST</CODE
-> and <CODE
-CLASS="ENVAR"
->SLAVEHOST</CODE
->, be sure
-<SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->not</I
-></SPAN
-> to use localhost for either of them. This will result
-in an error similar to the following: </P
-><P
-><TT
-CLASS="COMMAND"
->ERROR remoteListenThread_1: db_getLocalNodeId() returned 2 - wrong database? </TT
-></P
-></TD
-></TR
-></TABLE
-></DIV
-></P
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN1161"
->12.1. Creating the pgbenchuser</A
-></H2
-><P
-><TT
-CLASS="COMMAND"
->createuser -A -D $PGBENCHUSER</TT
-> </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN1165"
->12.2. Preparing the databases</A
-></H2
-><TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="100%"
-><TR
-><TD
-><PRE
-CLASS="PROGRAMLISTING"
-> createdb -O $PGBENCHUSER -h $MASTERHOST $MASTERDBNAME
- createdb -O $PGBENCHUSER -h $SLAVEHOST $SLAVEDBNAME
- pgbench -i -s 1 -U $PGBENCHUSER -h $MASTERHOST $MASTERDBNAME</PRE
-></TD
-></TR
-></TABLE
-><P
->Because <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> depends on the databases having the pl/pgSQL procedural
-language installed, we better install it now. It is possible that you have
-installed pl/pgSQL into the template1 database in which case you can skip this
-step because it's already installed into the $MASTERDBNAME.
-
-<TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="100%"
-><TR
-><TD
-><PRE
-CLASS="PROGRAMLISTING"
-> createlang plpgsql -h $MASTERHOST $MASTERDBNAME</PRE
-></TD
-></TR
-></TABLE
-> </P
-><P
-><SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> does not yet automatically copy table definitions from a
-master when a slave subscribes to it, so we need to import this data.
-We do this with <B
-CLASS="APPLICATION"
->pg_dump</B
->.
-
-<TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="100%"
-><TR
-><TD
-><PRE
-CLASS="PROGRAMLISTING"
-> pg_dump -s -U $REPLICATIONUSER -h $MASTERHOST $MASTERDBNAME | psql -U $REPLICATIONUSER -h $SLAVEHOST $SLAVEDBNAME</PRE
-></TD
-></TR
-></TABLE
-> </P
-><P
->To illustrate how <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> allows for on the fly
-replication subscription, let's start up <B
-CLASS="APPLICATION"
->pgbench</B
->. If
-you run the <B
-CLASS="APPLICATION"
->pgbench</B
-> application in the foreground of a
-separate terminal window, you can stop and restart it with different
-parameters at any time. You'll need to re-export the variables again
-so they are available in this session as well. </P
-><P
->The typical command to run <B
-CLASS="APPLICATION"
->pgbench</B
-> would look like:
-
-<TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="100%"
-><TR
-><TD
-><PRE
-CLASS="PROGRAMLISTING"
-> pgbench -s 1 -c 5 -t 1000 -U $PGBENCHUSER -h $MASTERHOST $MASTERDBNAME</PRE
-></TD
-></TR
-></TABLE
-> </P
-><P
->This will run <B
-CLASS="APPLICATION"
->pgbench</B
-> with 5 concurrent clients
-each processing 1000 transactions against the <B
-CLASS="APPLICATION"
->pgbench</B
->
-database running on localhost as the pgbench user. </P
-></DIV
-><DIV
-CLASS="SECT2"
-><H2
-CLASS="SECT2"
-><A
-NAME="AEN1185"
->12.3. Configuring the Database for Replication.</A
-></H2
-><P
->Creating the configuration tables, stored procedures, triggers
-and configuration is all done through the <A
-HREF="app-slonik.html#SLONIK"
-><B
-CLASS="APPLICATION"
->slonik</B
-> </A
-> tool. It is a specialized scripting aid
-that mostly calls stored procedures in the master/slave (node)
-databases. The script to create the initial configuration for the
-simple master-slave setup of our pgbench database looks like this:
-
-<TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="100%"
-><TR
-><TD
-><PRE
-CLASS="PROGRAMLISTING"
-> #!/bin/sh
-
- slonik <<_EOF_
- #--
- # define the namespace the replication system uses in our example it is
- # slony_example
- #--
- cluster name = $CLUSTERNAME;
-
- #--
- # admin conninfo's are used by slonik to connect to the nodes one for each
- # node on each side of the cluster, the syntax is that of PQconnectdb in
- # the C-API
- # --
- node 1 admin conninfo = 'dbname=$MASTERDBNAME host=$MASTERHOST user=$REPLICATIONUSER';
- node 2 admin conninfo = 'dbname=$SLAVEDBNAME host=$SLAVEHOST user=$REPLICATIONUSER';
-
- #--
- # init the first node. Its id MUST be 1. This creates the schema
- # _$CLUSTERNAME containing all replication system specific database
- # objects.
-
- #--
- init cluster ( id=1, comment = 'Master Node');
-
- #--
- # Because the history table does not have a primary key or other unique
- # constraint that could be used to identify a row, we need to add one.
- # The following command adds a bigint column named
- # _Slony-I_$CLUSTERNAME_rowID to the table. It will have a default value
- # of nextval('_$CLUSTERNAME.s1_rowid_seq'), and have UNIQUE and NOT NULL
- # constraints applied. All existing rows will be initialized with a
- # number
- #--
- table add key (node id = 1, fully qualified name = 'public.history');
-
- #--
- # Slony-I organizes tables into sets. The smallest unit a node can
- # subscribe is a set. The following commands create one set containing
- # all 4 pgbench tables. The master or origin of the set is node 1.
- #--
- create set (id=1, origin=1, comment='All pgbench tables');
- set add table (set id=1, origin=1, id=1, fully qualified name = 'public.accounts', comment='accounts table');
- set add table (set id=1, origin=1, id=2, fully qualified name = 'public.branches', comment='branches table');
- set add table (set id=1, origin=1, id=3, fully qualified name = 'public.tellers', comment='tellers table');
- set add table (set id=1, origin=1, id=4, fully qualified name = 'public.history', comment='history table', key = serial);
-
- #--
- # Create the second node (the slave) tell the 2 nodes how to connect to
- # each other and how they should listen for events.
- #--
-
- store node (id=2, comment = 'Slave node');
- store path (server = 1, client = 2, conninfo='dbname=$MASTERDBNAME host=$MASTERHOST user=$REPLICATIONUSER');
- store path (server = 2, client = 1, conninfo='dbname=$SLAVEDBNAME host=$SLAVEHOST user=$REPLICATIONUSER');
- store listen (origin=1, provider = 1, receiver =2);
- store listen (origin=2, provider = 2, receiver =1);
- _EOF_</PRE
-></TD
-></TR
-></TABLE
-> </P
-><P
->Is the <B
-CLASS="APPLICATION"
->pgbench</B
-> still running? If not start it
-again. </P
-><P
->At this point we have 2 databases that are fully prepared. One
-is the master database in which <B
-CLASS="APPLICATION"
->pgbench</B
-> is busy
-accessing and changing rows. It's now time to start the replication
-daemons. </P
-><P
->On $MASTERHOST the command to start the replication engine is
-
-<TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="100%"
-><TR
-><TD
-><PRE
-CLASS="PROGRAMLISTING"
-> slon $CLUSTERNAME "dbname=$MASTERDBNAME user=$REPLICATIONUSER host=$MASTERHOST"</PRE
-></TD
-></TR
-></TABLE
-> </P
-><P
->Likewise we start the replication system on node 2 (the slave)
-
-<TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="100%"
-><TR
-><TD
-><PRE
-CLASS="PROGRAMLISTING"
-> slon $CLUSTERNAME "dbname=$SLAVEDBNAME user=$REPLICATIONUSER host=$SLAVEHOST"</PRE
-></TD
-></TR
-></TABLE
-> </P
-><P
->Even though we have the <B
-CLASS="APPLICATION"
-><A
-HREF="app-slon.html#SLON"
-> slon</A
-></B
-> running on both the master and slave, and they
-are both spitting out diagnostics and other messages, we aren't
-replicating any data yet. The notices you are seeing is the
-synchronization of cluster configurations between the 2
-<B
-CLASS="APPLICATION"
-><A
-HREF="app-slon.html#SLON"
-> slon </A
-></B
->
-processes. </P
-><P
->To start replicating the 4 pgbench tables (set 1) from the
-master (node id 1) the the slave (node id 2), execute the following
-script.
-
-<TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="100%"
-><TR
-><TD
-><PRE
-CLASS="PROGRAMLISTING"
-> #!/bin/sh
- slonik <<_EOF_
- # ----
- # This defines which namespace the replication system uses
- # ----
- cluster name = $CLUSTERNAME;
-
- # ----
- # Admin conninfo's are used by the slonik program to connect
- # to the node databases. So these are the PQconnectdb arguments
- # that connect from the administrators workstation (where
- # slonik is executed).
- # ----
- node 1 admin conninfo = 'dbname=$MASTERDBNAME host=$MASTERHOST user=$REPLICATIONUSER';
- node 2 admin conninfo = 'dbname=$SLAVEDBNAME host=$SLAVEHOST user=$REPLICATIONUSER';
-
- # ----
- # Node 2 subscribes set 1
- # ----
- subscribe set ( id = 1, provider = 1, receiver = 2, forward = no);
- _EOF_</PRE
-></TD
-></TR
-></TABLE
-> </P
-><P
->Any second now, the replication daemon on $SLAVEHOST will start
-to copy the current content of all 4 replicated tables. While doing
-so, of course, the pgbench application will continue to modify the
-database. When the copy process is finished, the replication daemon
-on <CODE
-CLASS="ENVAR"
->$SLAVEHOST</CODE
-> will start to catch up by applying the
-accumulated replication log. It will do this in little steps, 10
-seconds worth of application work at a time. Depending on the
-performance of the two systems involved, the sizing of the two
-databases, the actual transaction load and how well the two databases
-are tuned and maintained, this catchup process can be a matter of
-minutes, hours, or eons.</P
-><P
->You have now successfully set up your first basic master/slave
-replication system, and the 2 databases should, once the slave has
-caught up, contain identical data. That's the theory, at least. In
-practice, it's good to build confidence by verifying that the datasets
-are in fact the same.</P
-><P
->The following script will create ordered dumps of the 2
-databases and compare them. Make sure that <B
-CLASS="APPLICATION"
->pgbench</B
-> has
-completed its testing, and that your slon sessions have caught up.
-
-<TABLE
-BORDER="0"
-BGCOLOR="#E0E0E0"
-WIDTH="100%"
-><TR
-><TD
-><PRE
-CLASS="PROGRAMLISTING"
-> #!/bin/sh
- echo -n "**** comparing sample1 ... "
- psql -U $REPLICATIONUSER -h $MASTERHOST $MASTERDBNAME >dump.tmp.1.$$ <<_EOF_
- select 'accounts:'::text, aid, bid, abalance, filler
- from accounts order by aid;
- select 'branches:'::text, bid, bbalance, filler
- from branches order by bid;
- select 'tellers:'::text, tid, bid, tbalance, filler
- from tellers order by tid;
- select 'history:'::text, tid, bid, aid, delta, mtime, filler,
- "_Slony-I_${CLUSTERNAME}_rowID"
- from history order by "_Slony-I_${CLUSTERNAME}_rowID";
- _EOF_
- psql -U $REPLICATIONUSER -h $SLAVEHOST $SLAVEDBNAME >dump.tmp.2.$$ <<_EOF_
- select 'accounts:'::text, aid, bid, abalance, filler
- from accounts order by aid;
- select 'branches:'::text, bid, bbalance, filler
- from branches order by bid;
- select 'tellers:'::text, tid, bid, tbalance, filler
- from tellers order by tid;
- select 'history:'::text, tid, bid, aid, delta, mtime, filler,
- "_Slony-I_${CLUSTERNAME}_rowID"
- from history order by "_Slony-I_${CLUSTERNAME}_rowID";
- _EOF_
-
- if diff dump.tmp.1.$$ dump.tmp.2.$$ >$CLUSTERNAME.diff ; then
- echo "success - databases are equal."
- rm dump.tmp.?.$$
- rm $CLUSTERNAME.diff
- else
- echo "FAILED - see $CLUSTERNAME.diff for database differences"
- fi</PRE
-></TD
-></TR
-></TABLE
-></P
-><P
->Note that there is somewhat more sophisticated documentation of
-the process in the <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> source code tree
-in a file called
-<TT
-CLASS="FILENAME"
->slony-I-basic-mstr-slv.txt</TT
->.</P
-><P
->If this script returns <TT
-CLASS="COMMAND"
->FAILED</TT
-> please contact the
-developers at <A
-HREF="http://slony.info/"
-TARGET="_top"
->http://slony.info/</A
-></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="ddlchanges.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slony.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="help.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Database Schema Changes (DDL)</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slonyadmin.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->More Slony-I Help</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/slony-commands.html
+++ /dev/null
@@ -1,184 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
-<HTML
-><HEAD
-><TITLE
->Slony-I Commands</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
-REV="MADE"
-HREF="mailto:cbbrowne at gmail.com"><LINK
-REL="HOME"
-TITLE="Slony-I 1.1 Administration"
-HREF="slony.html"><LINK
-REL="PREVIOUS"
-TITLE="Defining Slony-I Replication
-Sets"
-HREF="definingsets.html"><LINK
-REL="NEXT"
-TITLE="slon"
-HREF="app-slon.html"><LINK
-REL="STYLESHEET"
-TYPE="text/css"
-HREF="stdstyle.css"><META
-HTTP-EQUIV="Content-Type"></HEAD
-><BODY
-CLASS="REFERENCE"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->Slony-I 1.1 Administration</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="definingsets.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="app-slon.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="REFERENCE"
-><A
-NAME="SLONY-COMMANDS"
-></A
-><DIV
-CLASS="TITLEPAGE"
-><H1
-CLASS="TITLE"
->I. Slony-I Commands</H1
-><DIV
-CLASS="TOC"
-><DL
-><DT
-><B
->Table of Contents</B
-></DT
-><DT
-><A
-HREF="app-slon.html"
-><B
-CLASS="APPLICATION"
->slon</B
-></A
-> -- <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> daemon
- </DT
-><DT
-><A
-HREF="app-slonik.html"
-><B
-CLASS="APPLICATION"
->slonik</B
-></A
-> -- <SPAN
-CLASS="PRODUCTNAME"
->Slony-I</SPAN
-> command processor
- </DT
-></DL
-></DIV
-></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="definingsets.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slony.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="app-slon.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Defining Slony-I Replication
-Sets</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-> </TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><B
-CLASS="APPLICATION"
->slon</B
-></TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
--- doc/adminguide/slonconfig.html
+++ /dev/null
@@ -1,304 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd">
-<HTML
-><HEAD
-><TITLE
->Slon Configuration Options</TITLE
-><META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
-REV="MADE"
-HREF="mailto:cbbrowne at gmail.com"><LINK
-REL="HOME"
-TITLE="Slony-I 1.1 Administration"
-HREF="slony.html"><LINK
-REL="UP"
-HREF="t24.html"><LINK
-REL="PREVIOUS"
-TITLE="Slon daemons"
-HREF="slonstart.html"><LINK
-REL="NEXT"
-TITLE=" Subscribing Nodes"
-HREF="subscribenodes.html"><LINK
-REL="STYLESHEET"
-TYPE="text/css"
-HREF="stdstyle.css"><META
-HTTP-EQUIV="Content-Type"></HEAD
-><BODY
-CLASS="SECT1"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->Slony-I 1.1 Administration</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="slonstart.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
-></TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="subscribenodes.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="SECT1"
-><H1
-CLASS="SECT1"
-><A
-NAME="SLONCONFIG"
->10. Slon Configuration Options</A
-></H1
-><P
->Slon parameters: </P
-><P
-> usage: slon [options] clustername conninfo </P
-><P
-><TT
-CLASS="COMMAND"
->Options:
--d debuglevel verbosity of logging (1..8)
--s milliseconds SYNC check interval (default 10000)
--t milliseconds SYNC interval timeout (default 60000)
--g num maximum SYNC group size (default 6)
--c num how often to vacuum in cleanup cycles
--p filename slon pid file
--f filename slon configuration file</TT
->
-
-<P
-></P
-><UL
-><LI
-><P
-><CODE
-CLASS="OPTION"
->-d</CODE
-> </P
-><P
->The eight levels of logging are:
-<P
-></P
-><UL
-><LI
-><P
->Error</P
-></LI
-><LI
-><P
->Warn</P
-></LI
-><LI
-><P
->Config</P
-></LI
-><LI
-><P
->Info</P
-></LI
-><LI
-><P
->Debug1</P
-></LI
-><LI
-><P
->Debug2</P
-></LI
-><LI
-><P
->Debug3</P
-></LI
-><LI
-><P
->Debug4</P
-></LI
-></UL
->
- </P
-></LI
-><LI
-><P
-><CODE
-CLASS="OPTION"
->-s</CODE
-> </P
-><P
->A SYNC event will be sent at least this often, regardless of whether update activity is detected. </P
-><P
->Short sync times keep the master on a "short leash," updating the slaves more frequently. If you have replicated sequences that are frequently updated _without_ there being tables that are affected, this keeps there from being times when only sequences are updated, and therefore <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->no</I
-></SPAN
-> syncs take place. </P
-><P
->Longer sync times allow there to be fewer events, which allows somewhat better efficiency. </P
-></LI
-><LI
-><P
-><CODE
-CLASS="OPTION"
->-t</CODE
-> </P
-><P
->The time before the SYNC check interval times out. </P
-></LI
-><LI
-><P
-><CODE
-CLASS="OPTION"
->-g</CODE
-> </P
-><P
->Number of SYNC events to try to cram together. The default is 6, which is probably suitable for small systems that can devote only very limited bits of memory to slon. If you have plenty of memory, it would be reasonable to increase this, as it will increase the amount of work done in each transaction, and will allow a subscriber that is behind by a lot to catch up more quickly. </P
-><P
->Slon processes usually stay pretty small; even with large value for this option, slon would be expected to only grow to a few MB in size. </P
-></LI
-><LI
-><P
-><CODE
-CLASS="OPTION"
->-c</CODE
-> </P
-><P
->How often to vacuum (<SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->e.g.</I
-></SPAN
-> - how many cleanup cycles to run before vacuuming). </P
-><P
->Set this to zero to disable slon-initiated vacuuming. If you are using something like <B
-CLASS="APPLICATION"
->pg_autovacuum</B
-> to initiate vacuums, you may not need for slon to initiate vacuums itself. If you are not, there are some tables Slony-I uses that collect a <SPAN
-CLASS="emphasis"
-><I
-CLASS="EMPHASIS"
->lot</I
-></SPAN
-> of dead tuples that should be vacuumed frequently. </P
-></LI
-><LI
-><P
-><CODE
-CLASS="OPTION"
->-p</CODE
-> </P
-><P
-> The location of the PID file for the slon process. </P
-></LI
-><LI
-><P
-><CODE
-CLASS="OPTION"
->-f</CODE
-> </P
-><P
->The location of the slon configuration file.</P
-></LI
-></UL
->
-
-
- </P
-></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="slonstart.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="slony.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="subscribenodes.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Slon daemons</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="t24.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Subscribing Nodes</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
Index: README
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/README,v
retrieving revision 1.1
retrieving revision 1.2
diff -Ldoc/adminguide/README -Ldoc/adminguide/README -u -w -r1.1 -r1.2
--- doc/adminguide/README
+++ doc/adminguide/README
@@ -1,6 +1,4 @@
-This will become an "administrative guide" to the use of Slony-I.
-
-At present, it consists of copies of the Wiki at
+This was sourced from the Wiki at
http://cbbrowne.dyndns.info:8741/cgi-bin/twiki/view/Sandbox/SlonyIAdministration
-That will eventually be transformed into DocBook.
+It has been transformed into DocBook SGML as is used for PostgreSQL documentation.
- Previous message: [Slony1-commit] By cbbrowne: Plenty of modifications to documentation; lots of textual
- Next message: [Slony1-commit] By cbbrowne: Added in stored function for generating SYNC events
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-commit mailing list