Quite a number of revisions to the "Best Practices" documentation.

machack666 · Oct 17, 2006 · 8af7e2c · 8af7e2c
1 parent a71a03e
commit 8af7e2c
Showing 1 changed file with 29 additions and 19 deletions.
diff --git a/doc/adminguide/bestpractices.sgml b/doc/adminguide/bestpractices.sgml
@@ -1,4 +1,4 @@
-<!-- $Id: bestpractices.sgml,v 1.23 2006-08-02 18:34:57 cbbrowne Exp $ --> 
+<!-- $Id: bestpractices.sgml,v 1.24 2006-10-17 18:45:15 cbbrowne Exp $ --> 
 <sect1 id="bestpractices">
 <title> &slony1; <quote>Best Practices</quote> </title>
 <indexterm><primary>best practices for &slony1; usage</primary></indexterm>
@@ -29,19 +29,20 @@ of policies you might want to consider. </para>
 system, with the result that there are almost an innumerable set of
 places where problems can arise.  </para> 
 
-<para> As a natural result, maintaining a clean environment is really
-valuable, as any sort of environmental <quote>messiness</quote> can
-either cause unexpected problems or mask the real problem. </para>
+<para> As a natural result, maintaining a clean, consistent
+environment is really valuable, as any sort of environmental
+<quote>messiness</quote> can either cause unexpected problems or mask
+the real problem. </para>
 
 <para> Numerous users have reported problems resulting from mismatches
 between &slony1; versions, local libraries, and &postgres; libraries.
-Details count; you need to be clear on what hosts are running what
+Details count: you need to be clear on what hosts are running what
 versions of what software. </para>
 
-<para> This is normally a matter of being meticulous about checking
-what versions of software are in place everywhere, and is the natural
-result of having a distributed system comprised of a large number of
-components that need to match. </para>
+<para> This is normally a matter of being disciplined about how your
+software is deployed, and the challenges represent a natural
+consequence of being a distributed system comprised of a large number
+of components that need to match. </para>
 </listitem>
 
 <listitem><para> If a slonik script does not run as expected in a
@@ -74,7 +75,7 @@ Daylight Savings Time. </para>
 <para> The <quote>geographically unbiased</quote> choice seems to be
 <command><envar>TZ</envar>=UTC</command> or
 <command><envar>TZ</envar>=GMT</command>, and to make sure that
-systems are <quote>in sync</quote> by using NTP to syncchronize clocks
+systems are <quote>in sync</quote> by using NTP to synchronize clocks
 throughout the environment. </para>
 
 <para> See also <xref linkend="times">.</para>
@@ -118,11 +119,13 @@ should be of what should fail to what, as opposed to trying to
 automate it.  But knowing what to do ahead of time cuts down on the
 number of mistakes made.</para>
 
-<para> At Afilias, some internal <citation>The 3AM Unhappy DBA's Guide
-to...</citation> guides have been created to provide checklists of
-what to do when certain <quote>unhappy</quote> events take place; this
-sort of material is highly specific to the applications running, so
-you would need to generate your own such documents.
+<para> At Afilias, a variety of internal <citation>The 3AM Unhappy
+DBA's Guide to...</citation> guides have been created to provide
+checklists of what to do when certain <quote>unhappy</quote> events
+take place.  This sort of material is highly specific to the
+environment and the set of applications running there, so you would
+need to generate your own such documents.  This is one of the vital
+components of any disaster recovery preparations.
 </para>
 </listitem>
 
@@ -197,7 +200,9 @@ load work. </para>
 <para> In early versions of &slony1;, it was frequently the case that
 connections could get a bit <quote>deranged</quote> which restarting
 &lslon;s would clean up.  This has become much more rare, but it has
-occasionally proven useful to restart the &lslon;.</para> </listitem>
+occasionally proven useful to restart the &lslon;.  If there has been
+any <quote>network derangement</quote>, this can clear up the issue of
+defunct database connections.  </para> </listitem>
 
 <listitem>
 <para>The <link linkend="ddlchanges"> Database Schema Changes </link>
@@ -516,8 +521,8 @@ recreating each index <quote>ex nihilo</quote>, as the latter can take
 substantial advantage of sort memory. </para>
 
 <para> In &slony1; version 1.1.5 and later versions, indices are
-dropped and recreated automatically, which mostly eliminates the need
-for this.</para>
+dropped and recreated automatically, which effectively invalidates
+this practice.</para>
 </listitem>
 
 <listitem><para> If there are large numbers of updates taking place as
@@ -552,7 +557,12 @@ careful selection of &lslon; parameters:</para>
 <quote>master</quote> node, an index on <function> sl_log_1(log_xid)
 </function>.  If it doesn't exist, as the &slony1; instance was set up
 before version 1.1.1, see <filename> slony1_base.sql </filename> for
-the exact form that the index setup should take. </para> </listitem>
+the exact form that the index setup should take. </para> 
+
+<para> In 1.2, there is a process that runs automatically to add
+partial indexes by origin node number, which should be the optimal
+form for such an index to take.  </para>
+</listitem>
 
 <listitem><para> On the subscriber's &lslon;, increase
 the number of <command>SYNC</command> events processed together, with