Log Message:
-----------
Add in preliminary document on log shipping

Added Files:
-----------
    slony1-engine/doc/adminguide:
        logshipping.sgml (r1.1)

-------------- next part --------------
--- /dev/null
+++ doc/adminguide/logshipping.sgml
@@ -0,0 +1,90 @@
+<!-- $Id: logshipping.sgml,v 1.1 2005/02/21 04:45:47 cbbrowne Exp $ -->
+<sect1 id="logshipping">
+<title>Log Shipping - &slony1; with Files</title>
+
+<para> One of the new features for 1.1 is the ability to serialize the
+updates to go out into log files that can be kept in a spool
+directory.
+
+<para> The spool files could then be transferred via whatever means
+was desired to a <quote>slave system,</quote> whether that be via FTP,
+rsync, or perhaps even by pushing them onto a 1GB <quote>USB
+key</quote> to be sent to the destination by clipping it to the ankle
+of some sort of <quote>avian transport</quote> system.
+
+<para> There are plenty of neat things you can do with a data stream
+in this form, including:
+
+<itemizedlist>
+  <listitem><para> Using it to replicate to nodes that <emphasis>aren't</emphasis> securable
+  <listitem><para> Supporting a different form of PITR
+  <listitem><para> If disaster strikes, you can look at the logs of queries
+     themselves
+  <listitem><para> This is a neat scheme for building load for tests...
+  <listitem><para> We have a data <quote>escrow</quote> system that would become incredibly
+     cheaper given log shipping
+</itemizedlist>
+
+<qandaset>
+<qandaentry>
+
+<question> <para> Where are the <quote>spool files</quote> for a
+subscription set generated?
+</question>
+
+<answer> <para> Any <link linkend="slon"> slon </link> node can
+generate them by adding the <option>-a</option> option.
+</answer>
+</qandaentry>
+<qandaentry>
+<question> <para> What takes place when a failover/MOVE SET takes place?</para></question>
+
+<answer><para> Nothing special.  So long as the archiving node remains a
+		subscriber, it will continue to generate
+		logs.</para></answer>
+</qandaentry>
+
+<qandaentry>
+<question> <para> What if we run out of <quote>spool space</quote>?
+</para></question>
+
+<answer><para> The node will stop accepting SYNCs until this problem
+		is alleviated.  The database being subscribed to
+		will also fall behind.
+</para></answer>
+</qandaentry>
+<qandaentry>
+<question> <para> How do we set up a subscription?
+</para></question>
+
+<answer><para> The script in <filename>tools</filename> called
+<application>slony1_dump.sh</application> is a shell script that dumps
+the <quote>present</quote> state of the subscriber node.</para>
+
+<para> You need to start the <application><link linkend="slon"> slon
+</link></application> for the subscriber node with logging turned on.
+At any point after that, you can run
+<application>slony1_dump.sh</application>, which will pull the state
+of that subscriber as of some SYNC event.  Once the dump completes,
+all the SYNC logs generated from the time that dump
+<emphasis>started</emphasis> may be added to the dump in order to get
+a <quote>log shipping subscriber.</quote> </para></answer>
+</qandaentry>
+
+</qandaset>
+</sect1>
+<!-- Keep this comment at the end of the file
+Local variables:
+mode:sgml
+sgml-omittag:nil
+sgml-shorttag:t
+sgml-minimize-attributes:nil
+sgml-always-quote-attributes:t
+sgml-indent-step:1
+sgml-indent-data:t
+sgml-parent-document:"book.sgml"
+sgml-exposed-tags:nil
+sgml-local-catalogs:("/usr/lib/sgml/catalog")
+sgml-local-ecat-files:nil
+End:
+-->