CVS User Account cvsuser
Wed Jul 5 11:12:51 PDT 2006
Log Message:
-----------
Per discussion on list about FORWARDING, add more details to SUBSCRIBE SET
indicating why you may want FORWARDING turned to true/false.

Modified Files:
--------------
    slony1-engine/doc/adminguide:
        man.sgml (r1.7 -> r1.8)
        slonik_ref.sgml (r1.50 -> r1.51)
        slony.sgml (r1.29 -> r1.30)

-------------- next part --------------
Index: man.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/man.sgml,v
retrieving revision 1.7
retrieving revision 1.8
diff -Ldoc/adminguide/man.sgml -Ldoc/adminguide/man.sgml -u -w -r1.7 -r1.8
--- doc/adminguide/man.sgml
+++ doc/adminguide/man.sgml
@@ -42,6 +42,8 @@
   <!ENTITY funstoretrigger "<function>storetrigger(integer,name)</function>">
   <!ENTITY funsubscribeset "<function>subscribeset(integer,integer,integer,boolean)</function>">
   <!ENTITY slnode "<envar>sl_node</envar>">
+  <!ENTITY sllog1 "<envar>sl_log_1</envar>">
+  <!ENTITY sllog2 "<envar>sl_log_2</envar>">
   <!ENTITY slconfirm "<envar>sl_confirm</envar>">
   <!ENTITY bestpracticelink "Best Practice">
   <!ENTITY pglistener "<envar>pg_listener</envar>">
Index: slonik_ref.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slonik_ref.sgml,v
retrieving revision 1.50
retrieving revision 1.51
diff -Ldoc/adminguide/slonik_ref.sgml -Ldoc/adminguide/slonik_ref.sgml -u -w -r1.50 -r1.51
--- doc/adminguide/slonik_ref.sgml
+++ doc/adminguide/slonik_ref.sgml
@@ -1923,6 +1923,49 @@
 );
     </programlisting>
    </refsect1>
+
+   <refsect1> <title> Forwarding Behaviour </title>
+
+    <para> The <command>FORWARD=boolean</command> flag indicates
+    whether the subscriber will store log information in tables
+    &sllog1; and &sllog2;.  Several implications fall from
+    this...</para>
+
+    <para> By storing the data in these tables on the subscriber,
+    there is some additional processing burden.  If you are certain
+    that you would never want to <xref linkend="stmtmoveset"> or <xref
+    linkend="stmtfailover"> to a particular subscriber, it is worth
+    considering turning off forwarding on that node.  </para>
+
+    <para> There is, however, a case where having forwarding turned
+    off opens up a perhaps-unexpected failure condition; a rule of
+    thumb should be that <emphasis>all nodes that connect directly to
+    the origin</emphasis> should have forwarding turned on.  Supposing
+    one such <quote>direct subscriber</quote> has forwarding turned
+    off, it is possible for that node to be forcibly lost in a case of
+    failover.  The problem comes if that node gets ahead of other
+    nodes.</para>
+
+    <para> Let's suppose that the origin, node 1 is at SYNC number
+    88901, a non-forwarding node, node 2 has processed up to SYNC
+    88897, and other forwarding nodes, 3, 4, and 5, have only
+    processed data up to SYNC 88895.  At that moment, the disk system
+    on the origin node catches fire.  Node 2 has the
+    <emphasis>data</emphasis> up to SYNC 88897, but there is no
+    remaining node that contains, in &sllog1; or &sllog2;, the data
+    for SYNCs 88896 and 88897, so there is no way to bring nodes 3-5
+    up to that point.</para>
+
+    <para> At that point, there are only two choices: To drop node 2,
+    because there is no way to continue managing it, or to drop all
+    nodes <emphasis>but</emphasis> 2, because there is no way to bring
+    them up to SYNC 88897.</para>
+
+    <para> That dilemma may be avoided by making sure that all nodes
+    directly subscribing to the origin have forwarding turned
+    on. </para>
+
+   </refsect1>
    <refsect1> <title> Locking Behaviour </title>
 
     <para> This operation does <emphasis>not</emphasis> require
Index: slony.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slony.sgml,v
retrieving revision 1.29
retrieving revision 1.30
diff -Ldoc/adminguide/slony.sgml -Ldoc/adminguide/slony.sgml -u -w -r1.29 -r1.30
--- doc/adminguide/slony.sgml
+++ doc/adminguide/slony.sgml
@@ -42,6 +42,8 @@
   <!ENTITY bestpracticelink "<link linkend=bestpractices>Best Practice</link>">
   <!ENTITY rmissingoids "<link linkend=missingoids>error messages indicating missing OIDs</link>">
   <!ENTITY slnode "<xref linkend=table.sl-node>">
+  <!ENTITY sllog1 "<xref linkend=table.sl-log-1>">
+  <!ENTITY sllog2 "<xref linkend=table.sl-log-2>">
   <!ENTITY slconfirm "<xref linkend=table.sl-confirm>">
   <!ENTITY rplainpaths "<xref linkend=plainpaths>">
   <!ENTITY rlistenpaths "<xref linkend=listenpaths>">



More information about the Slony1-commit mailing list