Home CVS Mailinglists Documentation Download
[Slony1-commit] By cbbrowne: Add a whole bunch of index entries to admin guide to make
CVS User Account cvsuser
Wed Apr 13 22:23:01 PDT 2005 
Log Message:
-----------
Add a whole bunch of index entries to admin guide to make the index
more useful

Modified Files:
--------------
    slony1-engine/doc/adminguide:
        bookindex.sgml (r1.4 -> r1.5)
        cluster.sgml (r1.9 -> r1.10)
        concepts.sgml (r1.11 -> r1.12)
        ddlchanges.sgml (r1.13 -> r1.14)
        failover.sgml (r1.13 -> r1.14)
        faq.sgml (r1.25 -> r1.26)
        firstdb.sgml (r1.11 -> r1.12)
        listenpaths.sgml (r1.15 -> r1.16)
        logshipping.sgml (r1.6 -> r1.7)
        plainpaths.sgml (r1.5 -> r1.6)
        slonik_ref.sgml (r1.19 -> r1.20)
        subscribenodes.sgml (r1.11 -> r1.12)
        versionupgrade.sgml (r1.4 -> r1.5)

-------------- next part --------------
Index: versionupgrade.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/versionupgrade.sgml,v
retrieving revision 1.4
retrieving revision 1.5
diff -Ldoc/adminguide/versionupgrade.sgml -Ldoc/adminguide/versionupgrade.sgml -u -w -r1.4 -r1.5
--- doc/adminguide/versionupgrade.sgml
+++ doc/adminguide/versionupgrade.sgml
@@ -1,6 +1,8 @@
 <!-- $Id$ -->
 <sect1 id="versionupgrade"><title>Using &slony1; for &postgres; Upgrades</title>
 
+<indexterm><primary>&slony1; for &postgres; version upgrades</primary></indexterm>
+
 <para> A number of people have found
 &slony1; useful for helping perform upgrades
 between major &postgres; releases
Index: slonik_ref.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slonik_ref.sgml,v
retrieving revision 1.19
retrieving revision 1.20
diff -Ldoc/adminguide/slonik_ref.sgml -Ldoc/adminguide/slonik_ref.sgml -u -w -r1.19 -r1.20
--- doc/adminguide/slonik_ref.sgml
+++ doc/adminguide/slonik_ref.sgml
@@ -1,5 +1,6 @@
 <article id="slonikref">
 <title>Slonik Command Summary</title>
+
    <sect1><title>Introduction</title>
     
     <para>
Index: cluster.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/cluster.sgml,v
retrieving revision 1.9
retrieving revision 1.10
diff -Ldoc/adminguide/cluster.sgml -Ldoc/adminguide/cluster.sgml -u -w -r1.9 -r1.10
--- doc/adminguide/cluster.sgml
+++ doc/adminguide/cluster.sgml
@@ -1,6 +1,9 @@
 <!-- $Id$ -->
 <sect1 id="cluster">
 <title>Defining &slony1; Clusters</title>
+<indexterm>
+ <primary>cluster</primary>
+</indexterm>
 
 <para>A &slony1; cluster is the basic grouping of database instances
 in which replication takes place.  It consists of a set of &postgres;
Index: ddlchanges.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/ddlchanges.sgml,v
retrieving revision 1.13
retrieving revision 1.14
diff -Ldoc/adminguide/ddlchanges.sgml -Ldoc/adminguide/ddlchanges.sgml -u -w -r1.13 -r1.14
--- doc/adminguide/ddlchanges.sgml
+++ doc/adminguide/ddlchanges.sgml
@@ -2,6 +2,11 @@
 <sect1 id="ddlchanges">
 <title>Database Schema Changes (DDL)</title>
 
+<indexterm>
+ <primary> DDL changes </primary>
+ <secondary> changing the database schema </secondary>
+</indexterm>
+
 <para>When changes are made to the database schema,
 <emphasis>e.g.</emphasis> - adding fields to a table, it is necessary
 for this to be handled rather carefully, otherwise different nodes may
Index: failover.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/failover.sgml,v
retrieving revision 1.13
retrieving revision 1.14
diff -Ldoc/adminguide/failover.sgml -Ldoc/adminguide/failover.sgml -u -w -r1.13 -r1.14
--- doc/adminguide/failover.sgml
+++ doc/adminguide/failover.sgml
@@ -1,7 +1,6 @@
 <!-- $Id$ -->
 <sect1 id="failover">
 <title>Doing switchover and failover with &slony1;</title>
-
 <sect2><title>Foreword</title>
 
 <para>&slony1; is an asynchronous replication system.  Because of
@@ -28,6 +27,10 @@
 
 <sect2><title> Controlled Switchover</title>
 
+<indexterm>
+ <primary>Controlled switchover</primary>
+</indexterm>
+
 <para> We assume a current <quote>origin</quote> as node1 with one
 <quote>subscriber</quote> as node2 (<emphasis>e.g.</emphasis> -
 slave).  A web application on a third server is accessing the database
@@ -85,6 +88,10 @@
 </sect2>
 <sect2><title> Failover</title>
 
+<indexterm>
+ <primary>failover upon system failure</primary>
+</indexterm>
+
 <para> If some more serious problem occurs on the
 <quote>origin</quote> server, it may be necessary to <xref
 linkend="stmtfailover"> to a backup server.  This is a highly
Index: concepts.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/concepts.sgml,v
retrieving revision 1.11
retrieving revision 1.12
diff -Ldoc/adminguide/concepts.sgml -Ldoc/adminguide/concepts.sgml -u -w -r1.11 -r1.12
--- doc/adminguide/concepts.sgml
+++ doc/adminguide/concepts.sgml
@@ -15,9 +15,12 @@
 
 <sect2>
 <title>Cluster</title>
+<indexterm>
+ <primary>cluster</primary>
+</indexterm>
 
-<para>In &slony1; terms, a Cluster is a named set of &postgres;
-database instances; replication takes place between those
+<para>In &slony1; terms, a <quote>cluster</quote> is a named set of
+&postgres; database instances; replication takes place between those
 databases.</para>
 
 <para>The cluster name is specified in each and every Slonik script via the directive:</para>
@@ -31,6 +34,10 @@
 </sect2>
 <sect2><title>Node</title>
 
+<indexterm>
+ <primary>node</primary>
+</indexterm>
+
 <para>A &slony1; Node is a named &postgres; database that will be participating in replication.</para>
 
 <para>It is defined, near the beginning of each Slonik script, using the directive:</para>
@@ -50,6 +57,10 @@
 </sect2>
 <sect2><title> Replication Set</title>
 
+<indexterm>
+ <primary>replication set</primary>
+</indexterm>
+
 <para>A replication set is defined as a set of tables and sequences
 that are to be replicated between nodes in a
 &slony1; cluster.</para>
@@ -60,12 +71,24 @@
 
 <sect2><title> Origin, Providers and Subscribers</title>
 
+<indexterm>
+ <primary>origin node</primary>
+</indexterm>
+
+<indexterm>
+ <primary>provider node</primary>
+</indexterm>
+
 <para>Each replication set has some origin node, which is the
 <emphasis>only</emphasis> place where user applications are permitted
 to modify data in the tables that are being replicated.  This might
 also be termed the <quote>master provider</quote>; it is the main
 place from which data is provided.</para>
 
+<indexterm>
+ <primary>subscriber node</primary>
+</indexterm>
+
 <para>Other nodes in the cluster subscribe to the replication set,
 indicating that they want to receive the data.</para>
 
Index: bookindex.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/bookindex.sgml,v
retrieving revision 1.4
retrieving revision 1.5
diff -Ldoc/adminguide/bookindex.sgml -Ldoc/adminguide/bookindex.sgml -u -w -r1.4 -r1.5
--- doc/adminguide/bookindex.sgml
+++ doc/adminguide/bookindex.sgml
@@ -19,11 +19,35 @@
       sequences of pages into a range.
 -->
 
+<indexdiv><title>Symbols</title>
+
+<indexentry>
+  <primaryie> DDL changes 
+  </primaryie>
+  <secondaryie> changing the database schema ,
+    <ulink url="ddlchanges.html" role="AEN1452">Database Schema Changes (DDL)</ulink>
+  </secondaryie>
+</indexentry>
+
+<indexentry>
+  <primaryie> Frequently Asked Questions about Slony-I,
+    <ulink url="faq.html" role="AEN2036"></ulink>
+  </primaryie>
+</indexentry>
+
+</indexdiv>
 <indexdiv><title>C</title>
 
 <indexentry>
+  <primaryie>cluster,
+    <ulink url="concepts.html#AEN341" role="AEN343">Cluster</ulink>,
+    <ulink url="cluster.html" role="AEN402">Defining Slony-I Clusters</ulink>
+  </primaryie>
+</indexentry>
+
+<indexentry>
   <primaryie>cluster_name configuration parameter,
-    <ulink url="slon-config-connection.html" role="AEN2950">Connection settings</ulink>
+    <ulink url="slon-config-connection.html" role="AEN3053">Connection settings</ulink>
   </primaryie>
 </indexentry>
 
@@ -31,13 +55,19 @@
   <primaryie>configuration
   </primaryie>
   <secondaryie>of the slon daemon,
-    <ulink url="runtime-config.html" role="AEN2853">Run-time Configuration</ulink>
+    <ulink url="runtime-config.html" role="AEN2951"></ulink>
   </secondaryie>
 </indexentry>
 
 <indexentry>
   <primaryie>conn_info configuration parameter,
-    <ulink url="slon-config-connection.html" role="AEN2959">Connection settings</ulink>
+    <ulink url="slon-config-connection.html" role="AEN3063">Connection settings</ulink>
+  </primaryie>
+</indexentry>
+
+<indexentry>
+  <primaryie>Controlled switchover,
+    <ulink url="failover.html#AEN921" role="AEN923"> Controlled Switchover</ulink>
   </primaryie>
 </indexentry>
 
@@ -46,7 +76,16 @@
 
 <indexentry>
   <primaryie>desired_sync_time configuration parameter,
-    <ulink url="slon-config-interval.html" role="AEN3017">Event Tuning</ulink>
+    <ulink url="slon-config-interval.html" role="AEN3133">Event Tuning</ulink>
+  </primaryie>
+</indexentry>
+
+</indexdiv>
+<indexdiv><title>F</title>
+
+<indexentry>
+  <primaryie>failover upon system failure,
+    <ulink url="failover.html#AEN948" role="AEN950"> Failover</ulink>
   </primaryie>
 </indexentry>
 
@@ -54,26 +93,50 @@
 <indexdiv><title>L</title>
 
 <indexentry>
+  <primaryie>listen paths,
+    <ulink url="listenpaths.html" role="AEN995">Slony-I listen paths</ulink>
+  </primaryie>
+</indexentry>
+
+<indexentry>
   <primaryie>log_level configuration parameter,
-    <ulink url="runtime-config.html#SLON-CONFIG-LOGGING" role="AEN2902">Logging</ulink>
+    <ulink url="runtime-config.html#SLON-CONFIG-LOGGING" role="AEN3002">Logging</ulink>
   </primaryie>
 </indexentry>
 
 <indexentry>
   <primaryie>log_pid configuration parameter,
-    <ulink url="runtime-config.html#SLON-CONFIG-LOGGING" role="AEN2911">Logging</ulink>
+    <ulink url="runtime-config.html#SLON-CONFIG-LOGGING" role="AEN3011">Logging</ulink>
   </primaryie>
 </indexentry>
 
 <indexentry>
   <primaryie>log_timestamp configuration parameter,
-    <ulink url="runtime-config.html#SLON-CONFIG-LOGGING" role="AEN2920">Logging</ulink>
+    <ulink url="runtime-config.html#SLON-CONFIG-LOGGING" role="AEN3020">Logging</ulink>
   </primaryie>
 </indexentry>
 
 <indexentry>
   <primaryie>log_timestamp_format configuration parameter,
-    <ulink url="runtime-config.html#SLON-CONFIG-LOGGING" role="AEN2929">Logging</ulink>
+    <ulink url="runtime-config.html#SLON-CONFIG-LOGGING" role="AEN3029">Logging</ulink>
+  </primaryie>
+</indexentry>
+
+</indexdiv>
+<indexdiv><title>N</title>
+
+<indexentry>
+  <primaryie>node,
+    <ulink url="concepts.html#AEN355" role="AEN357">Node</ulink>
+  </primaryie>
+</indexentry>
+
+</indexdiv>
+<indexdiv><title>O</title>
+
+<indexentry>
+  <primaryie>origin node,
+    <ulink url="concepts.html#AEN383" role="AEN385"> Origin, Providers and Subscribers</ulink>
   </primaryie>
 </indexentry>
 
@@ -82,7 +145,28 @@
 
 <indexentry>
   <primaryie>pid_file configuration parameter,
-    <ulink url="runtime-config.html#SLON-CONFIG-LOGGING" role="AEN2938">Logging</ulink>
+    <ulink url="runtime-config.html#SLON-CONFIG-LOGGING" role="AEN3041">Logging</ulink>
+  </primaryie>
+</indexentry>
+
+<indexentry>
+  <primaryie>provider node,
+    <ulink url="concepts.html#AEN383" role="AEN387"> Origin, Providers and Subscribers</ulink>
+  </primaryie>
+</indexentry>
+
+</indexdiv>
+<indexdiv><title>R</title>
+
+<indexentry>
+  <primaryie>replicating a first database,
+    <ulink url="slonyadmin.html#FIRSTDB" role="AEN509">Replicating Your First Database</ulink>
+  </primaryie>
+</indexentry>
+
+<indexentry>
+  <primaryie>replication set,
+    <ulink url="concepts.html#AEN375" role="AEN377"> Replication Set</ulink>
   </primaryie>
 </indexentry>
 
@@ -102,44 +186,62 @@
 </indexentry>
 
 <indexentry>
+  <primaryie>Slony-I for PostgreSQL version upgrades,
+    <ulink url="versionupgrade.html" role="AEN1883">Using Slony-I for PostgreSQL Upgrades</ulink>
+  </primaryie>
+</indexentry>
+
+<indexentry>
   <primaryie>sql_on_connection configuration parameter,
-    <ulink url="slon-config-connection.html" role="AEN2968">Connection settings</ulink>
+    <ulink url="slon-config-connection.html" role="AEN3073">Connection settings</ulink>
+  </primaryie>
+</indexentry>
+
+<indexentry>
+  <primaryie>subscriber node,
+    <ulink url="concepts.html#AEN383" role="AEN392"> Origin, Providers and Subscribers</ulink>
+  </primaryie>
+</indexentry>
+
+<indexentry>
+  <primaryie>subscribing nodes,
+    <ulink url="subscribenodes.html" role="AEN673">Subscribing Nodes</ulink>
   </primaryie>
 </indexentry>
 
 <indexentry>
   <primaryie>sync_group_maxsize configuration parameter,
-    <ulink url="slon-config-interval.html" role="AEN2998">Event Tuning</ulink>
+    <ulink url="slon-config-interval.html" role="AEN3109">Event Tuning</ulink>
   </primaryie>
 </indexentry>
 
 <indexentry>
   <primaryie>sync_interval configuration parameter,
-    <ulink url="slon-config-interval.html" role="AEN2980">Event Tuning</ulink>
+    <ulink url="slon-config-interval.html" role="AEN3086">Event Tuning</ulink>
   </primaryie>
 </indexentry>
 
 <indexentry>
   <primaryie>sync_interval_timeout configuration parameter,
-    <ulink url="slon-config-interval.html" role="AEN2989">Event Tuning</ulink>
+    <ulink url="slon-config-interval.html" role="AEN3095">Event Tuning</ulink>
   </primaryie>
 </indexentry>
 
 <indexentry>
   <primaryie>syslog configuration parameter,
-    <ulink url="runtime-config.html#SLON-CONFIG-LOGGING" role="AEN2875">Logging</ulink>
+    <ulink url="runtime-config.html#SLON-CONFIG-LOGGING" role="AEN2974">Logging</ulink>
   </primaryie>
 </indexentry>
 
 <indexentry>
   <primaryie>syslog_facility configuration parameter,
-    <ulink url="runtime-config.html#SLON-CONFIG-LOGGING" role="AEN2884">Logging</ulink>
+    <ulink url="runtime-config.html#SLON-CONFIG-LOGGING" role="AEN2983">Logging</ulink>
   </primaryie>
 </indexentry>
 
 <indexentry>
   <primaryie>syslog_ident configuration parameter,
-    <ulink url="runtime-config.html#SLON-CONFIG-LOGGING" role="AEN2893">Logging</ulink>
+    <ulink url="runtime-config.html#SLON-CONFIG-LOGGING" role="AEN2993">Logging</ulink>
   </primaryie>
 </indexentry>
 
@@ -148,7 +250,7 @@
 
 <indexentry>
   <primaryie>vac_frequency configuration parameter,
-    <ulink url="slon-config-interval.html" role="AEN3007">Event Tuning</ulink>
+    <ulink url="slon-config-interval.html" role="AEN3123">Event Tuning</ulink>
   </primaryie>
 </indexentry>
 
Index: firstdb.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/firstdb.sgml,v
retrieving revision 1.11
retrieving revision 1.12
diff -Ldoc/adminguide/firstdb.sgml -Ldoc/adminguide/firstdb.sgml -u -w -r1.11 -r1.12
--- doc/adminguide/firstdb.sgml
+++ doc/adminguide/firstdb.sgml
@@ -1,6 +1,8 @@
 <!-- $Id$ -->
 <sect1 id="firstdb"><title>Replicating Your First Database</title>
 
+<indexterm><primary>replicating a first database</primary></indexterm>
+
 <para>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 &slony1;
Index: plainpaths.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/plainpaths.sgml,v
retrieving revision 1.5
retrieving revision 1.6
diff -Ldoc/adminguide/plainpaths.sgml -Ldoc/adminguide/plainpaths.sgml -u -w -r1.5 -r1.6
--- doc/adminguide/plainpaths.sgml
+++ doc/adminguide/plainpaths.sgml
@@ -13,11 +13,11 @@
 <quote/administrative workstation/ to all of the nodes in a &slony1;
 cluster.
 
-<para> It is <emphasis/vital/ that you have connections from the
-central location where you run <xref linkend="slonik"> 
-to each and every node in the network.  These connections are only
-used briefly, to submit the few <acronym/SQL/ requests required to
-control the administration of the cluster.
+<para> It is <emphasis>vital</emphasis> that you have connections from
+the central location where you run <xref linkend="slonik"> to each and
+every node in the network.  These connections are only used briefly,
+to submit the few <acronym>SQL</acronym> requests required to control
+the administration of the cluster.
 
 <para> Since these communications paths are only used briefly, it may
 be quite reasonable to <quote>hack together</quote> temporary
Index: subscribenodes.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/subscribenodes.sgml,v
retrieving revision 1.11
retrieving revision 1.12
diff -Ldoc/adminguide/subscribenodes.sgml -Ldoc/adminguide/subscribenodes.sgml -u -w -r1.11 -r1.12
--- doc/adminguide/subscribenodes.sgml
+++ doc/adminguide/subscribenodes.sgml
@@ -1,6 +1,8 @@
 <!-- $Id$ -->
 <sect1 id="subscribenodes"> <title>Subscribing Nodes</title>
 
+<indexterm><primary>subscribing nodes</primary></indexterm>
+
 <para>Before you subscribe a node to a set, be sure that you have
 <xref linkend="slon"> processes running for both the provider and the
 new subscribing node. If you don't have slons running, nothing will
Index: logshipping.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/logshipping.sgml,v
retrieving revision 1.6
retrieving revision 1.7
diff -Ldoc/adminguide/logshipping.sgml -Ldoc/adminguide/logshipping.sgml -u -w -r1.6 -r1.7
--- doc/adminguide/logshipping.sgml
+++ doc/adminguide/logshipping.sgml
@@ -2,9 +2,9 @@
 <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> One of the new features for &slony1; 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,
Index: faq.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/faq.sgml,v
retrieving revision 1.25
retrieving revision 1.26
diff -Ldoc/adminguide/faq.sgml -Ldoc/adminguide/faq.sgml -u -w -r1.25 -r1.26
--- doc/adminguide/faq.sgml
+++ doc/adminguide/faq.sgml
@@ -1,5 +1,6 @@
 <!-- $Id$ -->
 <qandaset>
+<indexterm><primary> Frequently Asked Questions about &slony1;</primary></indexterm>
 
 <qandaentry>
 
Index: listenpaths.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/listenpaths.sgml,v
retrieving revision 1.15
retrieving revision 1.16
diff -Ldoc/adminguide/listenpaths.sgml -Ldoc/adminguide/listenpaths.sgml -u -w -r1.15 -r1.16
--- doc/adminguide/listenpaths.sgml
+++ doc/adminguide/listenpaths.sgml
@@ -1,5 +1,8 @@
 <!-- $Id$ -->
 <sect1 id="listenpaths"><title>&slony1; listen paths</title>
+
+<indexterm><primary>listen paths</primary></indexterm>
+
 <note><para> If you are running version
 &slony1; 1.1 or later it should be
 <emphasis>completely unnecessary</emphasis> to read this section as it
@@ -28,7 +31,7 @@
 <productname>Slony-I</productname> is able to shift origins to other
 locations.</para>
 
-<sect2><title>how listening can break</title>
+<sect2><title>How listening can break</title>
 
 <para>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
@@ -55,7 +58,7 @@
 moment, <quote>as if by magic</quote>, node #3 started replicating again, as
 it discovered a place to get <command>sync</command> events.</para>
 </sect2>
-<sect2><title>how the listen configuration should look</title>
+<sect2><title>How the listen configuration should look</title>
 
 <para>The simple cases tend to be simple to cope with.  We need to
 instead look at a more complex node configuration.</para>
@@ -172,8 +175,8 @@
 <sect2 id="autolisten"><title>Automated Listen Path Generation</title>
 
 <para> In &slony1; version 1.1, a heuristic scheme is introduced to
-automatically generate listener entries.  This happens, in order,
-based on three data sources:
+automatically generate <envar>sl_listen</envar> entries.  This
+happens, in order, based on three data sources:
 
 <itemizedlist>
More information about the Slony1-commit mailing list

Content © 2007 Slony Development Group - Hosting provided by Command Prompt, Inc.