Wed Dec 22 20:44:31 PST 2004
- Previous message: [Slony1-commit] By darcyb: Carry the docbook stuff through to the frontend
- Next message: [Slony1-commit] By cbbrowne: Added commentary on what happens to triggers and rules
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Log Message:
-----------
Validate using make check
Modified Files:
--------------
slony1-engine/doc/adminguide:
addthings.sgml (r1.4 -> r1.5)
adminscripts.sgml (r1.7 -> r1.8)
bookindex.sgml (r1.1 -> r1.2)
cluster.sgml (r1.5 -> r1.6)
concepts.sgml (r1.5 -> r1.6)
ddlchanges.sgml (r1.4 -> r1.5)
defineset.sgml (r1.6 -> r1.7)
dropthings.sgml (r1.5 -> r1.6)
failover.sgml (r1.5 -> r1.6)
faq.sgml (r1.5 -> r1.6)
firstdb.sgml (r1.5 -> r1.6)
help.sgml (r1.5 -> r1.6)
installation.sgml (r1.5 -> r1.6)
intro.sgml (r1.3 -> r1.4)
legal.sgml (r1.2 -> r1.3)
listenpaths.sgml (r1.6 -> r1.7)
maintenance.sgml (r1.5 -> r1.6)
monitoring.sgml (r1.4 -> r1.5)
prerequisites.sgml (r1.4 -> r1.5)
reference.sgml (r1.3 -> r1.4)
reshape.sgml (r1.5 -> r1.6)
slon.sgml (r1.2 -> r1.3)
slonik.sgml (r1.4 -> r1.5)
slonik_ref.sgml (r1.4 -> r1.5)
slony.sgml (r1.6 -> r1.7)
startslons.sgml (r1.4 -> r1.5)
subscribenodes.sgml (r1.5 -> r1.6)
-------------- next part --------------
Index: slon.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slon.sgml,v
retrieving revision 1.2
retrieving revision 1.3
diff -Ldoc/adminguide/slon.sgml -Ldoc/adminguide/slon.sgml -u -w -r1.2 -r1.3
--- doc/adminguide/slon.sgml
+++ doc/adminguide/slon.sgml
@@ -1,10 +1,10 @@
+<!-- $Id -->
<refentry id="app-slon">
<refmeta>
<refentrytitle id="app-slon-title"><application>slon</application></refentrytitle>
<manvolnum>1</manvolnum>
<refmiscinfo>Application</refmiscinfo>
</refmeta>
-
<refnamediv>
<refname><application id="slon">slon</application></refname>
<refpurpose>
@@ -20,14 +20,13 @@
<cmdsynopsis>
<command>slon</command>
<arg rep="repeat"><replaceable class="parameter">option</replaceable></arg>
- <arg><replaceable class="parameter">clustername</replaceable>
- <arg><replaceable class="parameter">conninfo</replaceable></arg></arg>
+ <arg><replaceable class="parameter">clustername</replaceable></arg>
+ <arg><replaceable class="parameter">conninfo</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
-
<para>
<application>slon</application> is the daemon application that
<quote>runs</quote> <productname>Slony-I</productname>
@@ -42,46 +41,50 @@
<variablelist>
<varlistentry>
- <term><option>-d <replaceable class="parameter">debuglevel</replaceable></></term>
+ <term><option>-d</option><replaceable class="parameter">debuglevel</replaceable><//arg></term>
<listitem>
<para>
Specifies the level of verbosity that <application>slon</application> should
use when logging its activity.
</para>
- <para>The eight levels of logging are:
+ <para>
+ The eight levels of logging are:
<itemizedlist>
- <listitem><Para>Error
- <listitem><Para>Warn
- <listitem><Para>Config
- <listitem><Para>Info
- <listitem><Para>Debug1
- <listitem><Para>Debug2
- <listitem><Para>Debug3
- <listitem><Para>Debug4
+ <listitem><Para>Error</Para></listitem>
+ <listitem><Para>Warn</Para></listitem>
+ <listitem><Para>Config</Para></listitem>
+ <listitem><Para>Info</Para></listitem>
+ <listitem><Para>Debug1</Para></listitem>
+ <listitem><Para>Debug2</Para></listitem>
+ <listitem><Para>Debug3</Para></listitem>
+ <listitem><Para>Debug4</Para></listitem>
</itemizedlist>
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term><option>-s <replaceable class="parameter">SYNC check interval</replaceable></></term>
+ <term><option>-s</option><replaceable class="parameter">SYNC check interval</replaceable><//arg></term>
<listitem>
<para>
Specifies the interval, in milliseconds, in which
- <application/slon/ should add a SYNC even if none has been
+ <application>slon</application> should add a SYNC even if none has been
mandated by data creation. Default is 10000 ms.
</para>
- <para>Short sync times keep the master on a <quote/short leash,/
+ <para>
+ Short sync times keep the master on a <quote>short leash</quote>,
updating the slaves more frequently. If you have replicated
- sequences that are frequently updated <emphasis/without/ there
+ sequences that are frequently updated <emphasis>without</emphasis> there
being tables that are affected, this keeps there from being times
- when only sequences are updated, and therefore <emphasis/no/
- syncs take place.
+ when only sequences are updated, and therefore <emphasis>no</emphasis>
+ syncs take place
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term><option>-t <replaceable class="parameter">SYNC interval timeout</replaceable></></term>
+ <term><option>-t</option><replaceable class="parameter">SYNC interval timeout</replaceable><//arg></term>
<listitem>
<para>
Default is 60000 ms.
@@ -90,7 +93,7 @@
</varlistentry>
<varlistentry>
- <term><option>-g <replaceable class="parameter">group size</replaceable></></term>
+ <term><option>-g</option><replaceable class="parameter">group size</replaceable><//arg></term>
<listitem>
<para>
Maximum SYNC group size; defaults to 6. Thus, if a particular
@@ -98,41 +101,40 @@
into groups of 6. This would be expected to reduce transaction
overhead due to having fewer transactions to <command>COMMIT</command>.
</para>
-
- <para>The default of 6 is probably suitable for small systems
+ <para>
+ 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.</para>
-
- <para>Slon processes usually stay pretty small; even with large
+ more quickly.
+ </para>
+ <para>
+ 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.</para>
-
+ few MB in size.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term><option>-c <replaceable class="parameter">cleanup cycles</replaceable></></term>
+ <term><option>-c</option><replaceable class="parameter">cleanup cycles</replaceable><//arg></term>
<listitem>
<para>
How often to <command>VACUUM</command> in cleanup cycles.
</para>
-
- <para>Set this to zero to disable slon-initiated vacuuming. If
- you are using something like
- <application>pg_autovacuum</application> 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
- <emphasis>lot</emphasis> of dead tuples that should be vacuumed
- frequently.</para>
-
+ <para>
+ Set this to zero to disable slon-initiated vacuuming. If
+ you are using something like <application>pg_autovacuum</application>
+ 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
+ <emphasis>lot</emphasis> of dead tuples that should be vacuumed frequently.
+ </para>
</listitem>
</varlistentry>
<varlistentry>
- <term><option>-p <replaceable class="parameter">PID filename</replaceable></></term>
+ <term><option>-p</option><replaceable class="parameter">PID filename</replaceable><//arg></term>
<listitem>
<para>
PID filename.
@@ -141,20 +143,17 @@
</varlistentry>
<varlistentry>
- <term><option>-f <replaceable class="parameter">config file</replaceable></></term>
- <listitem><para>
+ <term><option>-f</option><replaceable class="parameter">config file</replaceable><//arg></term>
+ <listitem>
+ <para>
File containing <application>slon</application> configuration.
</para>
</listitem>
</varlistentry>
-
</variablelist>
</refsect1>
-
-
<refsect1>
<title>Exit Status</title>
-
<para>
<application>slon</application> returns 0 to the shell if it
finished normally. It returns -1 if it encounters any fatal error.
@@ -162,7 +161,6 @@
</refsect1>
</refentry>
-
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
Index: defineset.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/defineset.sgml,v
retrieving revision 1.6
retrieving revision 1.7
diff -Ldoc/adminguide/defineset.sgml -Ldoc/adminguide/defineset.sgml -u -w -r1.6 -r1.7
--- doc/adminguide/defineset.sgml
+++ doc/adminguide/defineset.sgml
@@ -1,12 +1,13 @@
-<sect1 id="definingsets"> <title>Defining Slony-I Replication
-Sets</title>
+<!-- $Id -->
+<sect1 id="definingsets">
+<title>Defining Slony-I Replication Sets</title>
<para>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 <quote>sets.</quote>
+as <quote>sets.</quote></para>
-<para>A replication set consists of the following:
+<para>A replication set consists of the following:</para>
<itemizedlist>
<listitem><para> Keys on tables that are to be replicated that have no
@@ -19,24 +20,23 @@
<sect2><title> Primary Keys</title>
-<para><productname/Slony-I/ <emphasis>needs</emphasis> to have a
+<para><productname>Slony-I</productname> <emphasis>needs</emphasis> 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
-<productname/Slony-I/ to use a primary key:
+<productname>Slony-I</productname> to use a primary key:</para>
<itemizedlist>
-<listitem><para> If the table has a formally identified primary key,
-<command> <link linkend="stmtsetaddtable"> SET ADD
+<listitem><para> If the table has a formally identified primary key, <command><link linkend="stmtsetaddtable">SET ADD
TABLE</link></command> can be used without any need to reference the
-primary key. <productname/Slony-I/ will pick up that there is a
-primary key, and use it.
+primary key. <productname>Slony-I</productname> will pick up that there is a
+primary key, and use it.</para></listitem>
<listitem><para> If the table hasn't got a primary key, but has some
<emphasis>candidate</emphasis> 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
+specify the key, as in</para>
<programlisting>
SET ADD TABLE (set id = 1, origin = 1, id = 42,
@@ -47,29 +47,29 @@
<para> Notice that while you need to specify the namespace for the
table, you must <emphasis>not</emphasis> specify the namespace for the
-key, as it infers the namespace from the table.
+key, as it infers the namespace from the table.</para></listitem>
<listitem><para> If the table hasn't even got a candidate primary key,
-you can ask <productname/Slony-I/ to provide one. This is done by
+you can ask <productname>Slony-I</productname> to provide one. This is done by
first using <command><link linkend="stmttableaddkey"> TABLE ADD KEY
</link> </command> to add a column populated using a
-<productname/Slony-I/ sequence, and then having the <command> <link
+<productname>Slony-I</productname> sequence, and then having the <command> <link
linkend="stmtsetaddtable"> SET ADD TABLE</link></command> include the
directive <option>key=serial</option>, to indicate that
-<productname/Slony-I/'s own column should be used.</para></listitem>
+<productname>Slony-I</productname>'s own column should be used.</para></listitem>
</itemizedlist>
<para> It is not terribly important whether you pick a
<quote>true</quote> primary key or a mere <quote>candidate primary
key;</quote> it is, however, recommended that you have one of those
-instead of having <productname/Slony-I/ populate the PK column for
+instead of having <productname>Slony-I</productname> 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. <productname/Slony-I/ may therefore introduce
+keeping values unique. <productname>Slony-I</productname> 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.</para>
-
+</sect2>
<sect2><title> Grouping tables into sets</title>
<para> It will be vital to group tables together into a single set if
@@ -85,9 +85,9 @@
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
-<emphasis/not/ be related, and therefore should be replicated in
+<emphasis>not</emphasis> be related, and therefore should be replicated in
separate sets.</para>
-
+</sect2>
</sect1>
<!-- Keep this comment at the end of the file
Index: adminscripts.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/adminscripts.sgml,v
retrieving revision 1.7
retrieving revision 1.8
diff -Ldoc/adminguide/adminscripts.sgml -Ldoc/adminguide/adminscripts.sgml -u -w -r1.7 -r1.8
--- doc/adminguide/adminscripts.sgml
+++ doc/adminguide/adminscripts.sgml
@@ -1,47 +1,49 @@
-<chapter id="altperl">
-<title/ Slony-I Administration Scripts/
-
-<para>In the <filename/altperl/ directory in the <application/CVS/
-tree, there is a sizable set of <application/Perl/ scripts that may be
-used to administer a set of <productname/Slony-I/ instances, which
-support having arbitrary numbers of nodes.
+<!-- $Id -->
+<article id="altperl">
+<title>Slony-I Administration Scripts</title>
+
+<para>In the <filename>altperl</filename> directory in the <application>CVS</application>
+tree, there is a sizable set of <application>Perl</application> scripts that may be
+used to administer a set of <productname>Slony-I</productname> instances, which
+support having arbitrary numbers of nodes.</para>
<para>Most of them generate Slonik scripts that are then to be passed
-on to the <link linkend="slonik"> <application/slonik/ </link> utility
-to be submitted to all of the <productname/Slony-I/ nodes in a
+on to the <link linkend="slonik"><application>slonik</application></link> utility
+to be submitted to all of the <productname>Slony-I</productname> nodes in a
particular cluster. At one time, this embedded running <link
linkend="slonik"> slonik </link> on the slonik scripts.
Unfortunately, this turned out to be a pretty large calibre
-<quote/foot gun,/ as minor typos on the command line led, on a couple
-of occasions, to pretty calamitous actions, so the behaviour has been
+<quote>foot gun</quote>, as minor typos on the command line led, on a couple
+of occasions, to pretty calamitous actions, so the behavior has been
changed so that the scripts simply submit output to standard output.
-An administrator should review the script <emphasis/before/ submitting
-it to <link linkend="slonik"> slonik </link>.
+An administrator should review the script <emphasis>before</emphasis> submitting
+it to <link linkend="slonik">slonik</link>.</para>
<sect1><title> Node/Cluster Configuration - cluster.nodes</title>
-<para>The UNIX environment variable <envar/SLONYNODES/ is used to
+<para>The UNIX environment variable <envar>SLONYNODES</envar> is used to
determine what Perl configuration file will be used to control the
-shape of the nodes in a <productname/Slony-I/ cluster.
+shape of the nodes in a <productname>Slony-I</productname> cluster.</para>
-<para>What variables are set up...
+<para>What variables are set up.
<itemizedlist>
-<listitem><Para> <envar/$SETNAME/=orglogs; # What is the name of the replication set?
-<listitem><Para> <envar/$LOGDIR/='/opt/OXRS/log/LOGDBS'; # What is the base directory for logs?
-<listitem><Para> <envar/$SLON_BIN_PATH/='/opt/dbs/pgsql74/bin'; # Where to look for slony binaries
-<listitem><Para> <envar/$APACHE_ROTATOR/="/opt/twcsds004/OXRS/apache/rotatelogs"; # If set, where to find Apache log rotator
+<listitem><para><envar>$SETNAME</envar>=orglogs; # What is the name of the replication set?</para></listitem>
+<listitem><para><envar>$LOGDIR</envar>='/opt/OXRS/log/LOGDBS'; # What is the base directory for logs?</para></listitem>
+<listitem><para><envar>$SLON_BIN_PATH</envar>='/opt/dbs/pgsql74/bin'; # Where to look for Slony-I binaries</para></listitem>
+<listitem><para><envar>$APACHE_ROTATOR</envar>="/opt/twcsds004/OXRS/apache/rotatelogs"; # If set, where to find Apache log rotator</para></listitem>
</itemizedlist>
-
-<para>You then define the set of nodes that are to be replicated using
-a set of calls to <function/add_node()/.
+</para>
+<para>
+You then define the set of nodes that are to be replicated using a set of calls to <function>add_node()</function>.
+</para>
<para><command>
add_node (host => '10.20.30.40', dbname => 'orglogs', port => 5437,
user => 'postgres', node => 4, parent => 1);
</command></para>
-<para>The set of parameters for <function/add_node()/ are thus:
+<para>The set of parameters for <function>add_node()</function> are thus:</para>
<programlisting>
my %PARAMS = (host=> undef, # Host name
@@ -57,154 +59,155 @@
</sect1>
<sect1><title> Set configuration - cluster.set1, cluster.set2</title>
-<para>The UNIX environment variable <envar/SLONYSET/ is used to
+<para>The UNIX environment variable <envar>SLONYSET</envar> is used to
determine what Perl configuration file will be used to determine what
-objects will be contained in a particular replication set.
+objects will be contained in a particular replication set.</para>
<para>Unlike <envar>SLONYNODES</envar>, which is essential for
-<emphasis>all</emphasis> of the <link linkend="slonik"> slonik
-</link>-generating scripts, this only needs to be set when running
+<emphasis>all</emphasis> of the <link linkend="slonik">slonik</link>-generating scripts, this only needs to be set when running
<filename>create_set.pl</filename>, as that is the only script used to
control what tables will be in a particular replication set.</para>
-<para>What variables are set up...
+<para>What variables are set up.</para>
<itemizedlist>
-<listitem><Para> $TABLE_ID = 44;
-<para> Each table must be identified by a unique number; this variable controls where numbering starts
-<listitem><Para> @PKEYEDTABLES
+<listitem><para>$TABLE_ID = 44;</para>
+<para> Each table must be identified by a unique number; this variable controls where numbering starts</para>
+</listitem>
+<listitem><para>@PKEYEDTABLES</para>
<para> An array of names of tables to be replicated that have a
-defined primary key so that Slony-I can automatically select its key
-
-<listitem><Para> %KEYEDTABLES
-
+defined primary key so that Slony-I can automatically select its key</para>
+</listitem>
+<listitem><para>%KEYEDTABLES</para>
<para> 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."
-
-<listitem><Para> @SERIALTABLES
+index suitable as a "candidate primary key."</para>
+</listitem>
+<listitem><para>@SERIALTABLES</para>
<para> 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
-
-<listitem><Para> @SEQUENCES
-
-<para> An array of names of sequences that are to be replicated
+sequence that Slony-I generates</para>
+</listitem>
+<listitem><para>@SEQUENCES</para>
+<para> An array of names of sequences that are to be replicated</para>
+</listitem>
</itemizedlist>
</sect1>
-<sect1><title/ build_env.pl/
+<sect1><title>build_env.pl</title>
<para>Queries a database, generating output hopefully suitable for
-<filename/slon.env/ consisting of:
+<filename>slon.env</filename> consisting of:</para>
<itemizedlist>
-<listitem><Para> a set of <function/add_node()/ calls to configure the cluster
-<listitem><Para> The arrays <envar/@KEYEDTABLES/, <envar/@SERIALTABLES/, and <envar/@SEQUENCES/
+<listitem><para> a set of <function>add_node()</function> calls to configure the cluster</para></listitem>
+<listitem><para> The arrays <envar>@KEYEDTABLES</envar>, <envar>@SERIALTABLES</envar>, and <envar>@SEQUENCES</envar></para></listitem>
</itemizedlist>
</sect1>
-<sect1><title/ create_set.pl/
+<sect1><title>create_set.pl</title>
-<para>This requires <envar/SLONYSET/ to be set as well as
-<envar/SLONYNODES/; it is used to generate the Slonik script to set up
+<para>This requires <envar>SLONYSET</envar> to be set as well as
+<envar>SLONYNODES</envar>; it is used to generate the <command>slonik</command> script to set up
a replication set consisting of a set of tables and sequences that are
-to be replicated.
+to be replicated.</para>
</sect1>
-<sect1><title/ drop_node.pl/
+<sect1><title>drop_node.pl</title>
-<para>Generates Slonik script to drop a node from a Slony-I cluster.
+<para>Generates Slonik script to drop a node from a Slony-I cluster.</para>
</sect1>
-<sect1><title/ drop_set.pl/
+<sect1><title>drop_set.pl</title>
-<para>Generates Slonik script to drop a replication set (<emphasis/e.g./ - set of tables and sequences) from a Slony-I cluster.
+<para>Generates Slonik script to drop a replication set (<emphasis>e.g.</emphasis> - set of tables and sequences) from a Slony-I cluster.</para>
</sect1>
-<sect1><title/ failover.pl/
+<sect1><title>failover.pl</title>
-<para>Generates Slonik script to request failover from a dead node to some new origin
+<para>Generates Slonik script to request failover from a dead node to some new origin</para>
</sect1>
-<sect1><title/ init_cluster.pl/
+<sect1><title>init_cluster.pl</title>
<para>Generates Slonik script to initialize a whole Slony-I cluster,
including setting up the nodes, communications paths, and the listener
-routing.
+routing.</para>
</sect1>
-<sect1><title/ merge_sets.pl/
+<sect1><title>merge_sets.pl</title>
-<para>Generates Slonik script to merge two replication sets together.
+<para>Generates Slonik script to merge two replication sets together.</para>
</sect1>
-<sect1><title/ move_set.pl/
+<sect1><title>move_set.pl</title>
-<para>Generates Slonik script to move the origin of a particular set to a different node.
+<para>Generates Slonik script to move the origin of a particular set to a different node.</para>
</sect1>
-<sect1><title/ replication_test.pl/
+<sect1><title>replication_test.pl</title>
-<para>Script to test whether Slony-I is successfully replicating data.
+<para>Script to test whether Slony-I is successfully replicating data.</para>
</sect1>
-<sect1><title/ restart_node.pl/
+<sect1><title>restart_node.pl</title>
<para>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.
+slon daemons died.</para>
</sect1>
-<sect1><title/ restart_nodes.pl/
+<sect1><title>restart_nodes.pl</title>
<para>Generates Slonik script to restart all nodes in the cluster. Not
-particularly useful...
+particularly useful.</para>
</sect1>
-<sect1><title/ show_configuration.pl/
+<sect1><title>show_configuration.pl</title>
-<para>Displays an overview of how the environment (e.g. - <envar/SLONYNODES/) is set
-to configure things.
+<para>Displays an overview of how the environment (e.g. - <envar>SLONYNODES</envar>) is set
+to configure things.</para>
</sect1>
-<sect1><title/ slon_kill.pl/
+<sect1><title>slon_kill.pl</title>
<para>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!
+course!</para>
</sect1>
-<sect1><title/ slon_pushsql.pl/
+<sect1><title>slon_pushsql.pl</title>
-<para>Generates Slonik script to push DDL changes to a replication set.
+<para>Generates Slonik script to push DDL changes to a replication set.</para>
</sect1>
-<sect1><title/ slon_start.pl/
+<sect1><title>slon_start.pl</title>
<para>This starts a slon daemon for the specified cluster and node, and uses
-slon_watchdog.pl to keep it running.
+slon_watchdog.pl to keep it running.</para>
</sect1>
-<sect1><title/ slon_watchdog.pl/
+<sect1><title>slon_watchdog.pl</title>
-<para>Used by slon_start.pl...
+<para>Used by <command>slon_start.pl</command>.</para>
-</sect1><sect1><title/ slon_watchdog2.pl/
+</sect1><sect1><title>slon_watchdog2.pl</title>
<para>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.
+20 minutes or more.</para>
<para>This is helpful if there is an unreliable network connection such that
-the slon sometimes stops working without becoming aware of it...
+the slon sometimes stops working without becoming aware of it.</para>
-</sect1><sect1><title/ subscribe_set.pl/
+</sect1>
+<sect1><title>subscribe_set.pl</title>
-<para>Generates Slonik script to subscribe a particular node to a particular replication set.
+<para>Generates Slonik script to subscribe a particular node to a particular replication set.</para>
-</sect1><sect1><title/ uninstall_nodes.pl/
+</sect1><sect1><title>uninstall_nodes.pl</title>
<para>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!
+a VERY unsafe script!</para>
-</sect1><sect1><title/ unsubscribe_set.pl/
+</sect1><sect1><title>unsubscribe_set.pl</title>
-<para>Generates Slonik script to unsubscribe a node from a replication set.
+<para>Generates Slonik script to unsubscribe a node from a replication set.</para>
-</sect1><sect1><title/ update_nodes.pl/
+</sect1>
+<sect1><title>update_nodes.pl</title>
<para>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 <productname/Slony-I/ to another.
-
+from one version of <productname>Slony-I</productname> to another.</para>
+</sect1>
<sect1 id="regenlisten"><title> regenerate-listens.pl</title>
<para> This script connects to a <productname>Slony-I</productname>
@@ -216,9 +219,8 @@
<para> See the documentation on <link linkend="autolisten"> Automated
Listen Path Generation </link> for more details on how this
works.</para>
-
</sect1>
-
+</article>
<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
Index: slonik_ref.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slonik_ref.sgml,v
retrieving revision 1.4
retrieving revision 1.5
diff -Ldoc/adminguide/slonik_ref.sgml -Ldoc/adminguide/slonik_ref.sgml -u -w -r1.4 -r1.5
--- doc/adminguide/slonik_ref.sgml
+++ doc/adminguide/slonik_ref.sgml
@@ -1,15 +1,15 @@
-<ARTICLE id="slonikcommands">
-<title>Slonik Command Summary</title>
+<!-- $Id -->
+<article>
<sect1 id="slonikintro">
<title>Slonik Command Summary</title>
-<sect2><title/Introduction/
+<sect2><title>Introduction</title>
<para>
<application>Slonik</application> is a command line utility designed
specifically to setup and modify configurations of the
<productname>Slony-I</productname> replication system.
</para>
-
+</sect2>
<sect2 id="outline">
<title>General outline</title>
@@ -42,9 +42,6 @@
maintain multiple connections with open transactions.</para></listitem>
</itemizedlist>
</para>
-<para>
-
-</para>
<sect3><title>Commands</title>
<para>
The slonik command language is format free. Commands begin with
@@ -64,7 +61,7 @@
<listitem><para>boolean values {TRUE|ON|YES} or {FALSE|OFF|NO}</para></listitem>
<listitem><para>keywords for special cases</para></listitem>
</itemizedlist>
-</para>
+</para></sect3>
<sect3><title>Comments</title>
<para>
Comments begin at a hash sign (#) and extend to the end of the line.
@@ -81,29 +78,31 @@
[on error { commands; }
[on success { commands; }
</programlisting>
+</para>
<para> Those commands are grouped together into one transaction per
participating node.
</para>
-<!-- ************************************************************ -->
-
+</sect3>
+</sect2>
+</sect1>
<reference id="hdrcmds">
<title>Slonik Preamble Commands</title>
<partintro>
<para>
- The following commands must appear as a <quote/preamble/ at the very
- top of every <application/slonik/ command script. They do not cause any
+ The following commands must appear as a <quote>preamble</quote> at the very
+ top of every <application>slonik</application> command script. They do not cause any
direct action on any of the nodes in the replication system,
but affect the execution of the entire script.
</para>
</partintro>
-<!-- **************************************** -->
+
<refentry id ="clustername"><refmeta><refentrytitle>CLUSTER NAME</refentrytitle> </refmeta>
<refnamediv><refname>CLUSTER NAME</refname>
-<refpurpose> preamble - identifying <productname/Slony-I/ cluster </refpurpose>
+<refpurpose> preamble - identifying <productname>Slony-I</productname> cluster</refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
<command>CLUSTER NAME = </command>
@@ -113,8 +112,8 @@
<refsect1>
<title>Description</title>
<para>
- Must be the very first command in every <application/slonik/ script. Defines
- the namespace in which all <productname/Slony-I/ specific functions,
+ Must be the very first command in every <application>slonik</application> script. Defines
+ the namespace in which all <productname>Slony-I</productname> specific functions,
procedures, tables and sequences are defined. The namespace
name is built by prefixing the given string literal with an
underscore. This namespace will be identical in all databases
@@ -158,22 +157,22 @@
<refsect1>
<title>Description</title>
<para>
- Describes how the <application/slonik/ utility can reach a nodes database in
+ Describes how the <application>slonik</application> utility can reach a nodes database in
the cluster from where it is run (likely the DBA's
workstation). The conninfo string is the string agrument given
- to the <function/PQconnectdb()/ libpq function. The user used to connect
+ to the <function>PQconnectdb()</function> libpq function. The user used to connect
must be the special replication superuser, as some of the
actions performed later may include operations that are
strictly reserved for database superusers by PostgreSQL.
</para>
<para>
- The <application/slonik/ utility will not try to connect to the databases
+ The <application>slonik</application> utility will not try to connect to the databases
unless some subsequent command requires the connection.
</Para>
<para>
- Note: As mentioned in the original documents, <productname/Slony-I/ is designed as an
+ Note: As mentioned in the original documents, <productname>Slony-I</productname> is designed as an
enterprise replication system for data centers. It has been
assumed throughout the entire development that the database
servers and administrative workstations involved in
@@ -253,7 +252,7 @@
<para>
Terminates script execution immediately, rolling back every
open transaction on all database connections. The
- <application/slonik/ utility
+ <application>slonik</application> utility
will return the given value as its program termination code.
</para>
</Refsect1>
@@ -281,7 +280,7 @@
</refsynopsisdiv>
<refsect1>
<title>Description</title>
- <para> Initialize the first node in a new <productname/Slony-I/
+ <para> Initialize the first node in a new <productname>Slony-I</productname>
replication cluster. The initialization process consists of creating
the cluster namespace, loading all the base tables, functions,
procedures and initializing the node.
@@ -324,7 +323,7 @@
<refnamediv><refname>STORE NODE</refname>
-<refpurpose> Initialize <productname/Slony-I/ node </refpurpose>
+<refpurpose> Initialize <productname>Slony-I</productname> node </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
<command>STORE NODE (options);</command>
@@ -354,7 +353,7 @@
<varlistentry><term><literal> SPOOLNODE = boolean </literal></term>
<listitem><para>Specifies that the new node is a virtual spool node
- for file archiving of replication log. If true <application/slonik/
+ for file archiving of replication log. If true <application>slonik</application>
will not attempt to initialize a database with the replication
schema.</para></listitem>
@@ -381,7 +380,7 @@
<refnamediv><refname>DROP NODE</refname>
-<refpurpose> Decommission <productname/Slony-I/ node </refpurpose>
+<refpurpose> Decommission <productname>Slony-I</productname> node </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
<command>DROP NODE (options);</command>
@@ -418,7 +417,7 @@
<refnamediv><refname>UNINSTALL NODE</refname>
-<refpurpose> Decommission <productname/Slony-I/ node </refpurpose>
+<refpurpose> Decommission <productname>Slony-I</productname> node </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
<command>UNINSTALL NODE (options);</command>
@@ -429,8 +428,8 @@
<para>
Restores all tables to the unlocked state, with all original
- user triggers, constraints and rules, eventually added <productname/Slony-I/
- specific serial key columns dropped and the <productname/Slony-I/ schema
+ user triggers, constraints and rules, eventually added <productname>Slony-I</productname>
+ specific serial key columns dropped and the <productname>Slony-I</productname> schema
dropped. The node becomes a standalone database. The data is
left untouched.
@@ -454,7 +453,7 @@
<refnamediv><refname>RESTART NODE</refname>
-<refpurpose> Restart <productname/Slony-I/ node </refpurpose>
+<refpurpose> Restart <productname>Slony-I</productname> node </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
@@ -491,7 +490,7 @@
<refnamediv><refname>STORE PATH</refname>
-<refpurpose> Configure <productname/Slony-I/ node </refpurpose>
+<refpurpose> Configure <productname>Slony-I</productname> node </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
@@ -508,19 +507,19 @@
overwritten.</para>
<para> The conninfo string must contain all information to connect to the
- database as the replication superuser. The names <quote/server/ or
- <quote/client/ have nothing to do with the particular role of a node
+ database as the replication superuser. The names <quote>server</quote> or
+ <quote>client</quote> have nothing to do with the particular role of a node
within the cluster configuration. It should be simply viewed as
- <quote/the server/ has the message or data that <quote/the client
- is supposed to get./ For a simple 2 node setup, paths into both
+ the <quote>server</quote> has the message or data that the <quote>client
+ is supposed to get</quote>. For a simple 2 node setup, paths into both
directions must be configured.
</para>
<para>
It does not do any harm to configure path information from every
node to every other node (full cross product). The connections
are not established unless they are required to actually transfer
- events or confirmations because of <emphasis/listen/ entries or data
- because of <emphasis/subscriptions/.
+ events or confirmations because of <emphasis>listen</emphasis> entries or data
+ because of <emphasis>subscriptions</emphasis>.
<variablelist>
<varlistentry><term><literal> SERVER = ival </literal></term>
@@ -530,7 +529,7 @@
<listitem><para> Node ID of the replication daemon connecting.</para></listitem>
</varlistentry>
<varlistentry><term><literal> CONNINFO = string </literal></term>
- <listitem><para> <function/PQconnectdb()/ argument to establish the connection.</para></listitem>
+ <listitem><para> <function>PQconnectdb()</function> argument to establish the connection.</para></listitem>
</varlistentry>
<varlistentry><term><literal> CONNRETRY = ival </literal></term>
<listitem><para> Number of seconds to wait before another attempt to
@@ -556,7 +555,7 @@
<refnamediv><refname>DROP PATH</refname>
-<refpurpose> Configure <productname/Slony-I/ node </refpurpose>
+<refpurpose> Configure <productname>Slony-I</productname> node </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
@@ -566,8 +565,8 @@
<refsect1>
<title>Description</title>
-<para> Remove the connection information between <quote/server/ and
- <quote/client/.
+<para> Remove the connection information between <quote>server</quote> and
+ <quote>client</quote>.
@@ -582,7 +581,7 @@
<listitem><para> The ID of the node used to create the configuration
event that tells all existing nodes about dropping the path.
- Defaults to the <quote/client/, if omitted.
+ Defaults to the <quote>client</quote>, if omitted.
</para>
</varlistentry>
</variablelist>
@@ -602,7 +601,7 @@
<refnamediv><refname>STORE LISTEN</refname>
-<refpurpose> Configure <productname/Slony-I/ node </refpurpose>
+<refpurpose> Configure <productname>Slony-I</productname> node </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
@@ -612,9 +611,9 @@
<refsect1>
<title>Description</title>
-<para> A <quote/listen/ entry causes a node (receiver) to query an
+<para> A <quote>listen</quote> entry causes a node (receiver) to query an
event provider for events that originate from a specific node, as well
-as confirmations from every existing node. It requires a <quote/path/
+as confirmations from every existing node. It requires a <quote>path</quote>
to exist so that the receiver (as client) can connect to the provider
(as server).
@@ -627,7 +626,7 @@
the origin of the data set should listen for events from the
origin in the opposite direction. A node can listen for events
from one and the same origin on different providers at the
- same time. However, to process <command/SYNC/ events from that
+ same time. However, to process <command>SYNC</command> events from that
origin, all data providers must have the same or higher sync
status, so this will not result in any faster replication
behaviour.
@@ -663,7 +662,7 @@
<refnamediv><refname>DROP LISTEN</refname>
-<refpurpose> Configure <productname/Slony-I/ node </refpurpose>
+<refpurpose> Configure <productname>Slony-I</productname> node </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
@@ -673,7 +672,7 @@
<refsect1>
<title>Description</title>
-<para> Remove a <quote/listen/ configuration entry. </para>
+<para> Remove a <quote>listen</quote> configuration entry. </para>
<variablelist>
<varlistentry><term><literal> ORIGIN = ival </literal></term>
@@ -703,7 +702,7 @@
<refnamediv><refname>TABLE ADD KEY</refname>
-<refpurpose> Configure <productname/Slony-I/ set </refpurpose>
+<refpurpose> Configure <productname>Slony-I</productname> set </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
@@ -714,8 +713,8 @@
<title>Description</title>
<para>
- In the <productname/Slony-I/ replication system, every replicated table is
- required to have at least one <command/UNIQUE/ constraint
+ In the <productname>Slony-I</productname> replication system, every replicated table is
+ required to have at least one <command>UNIQUE</command> constraint
whose columns are declared <command>NOT NULL.</command> Any
primary key satisfies this
requirement.
@@ -759,7 +758,7 @@
<refnamediv><refname>CREATE SET</refname>
-<refpurpose> Configure <productname/Slony-I/ set </refpurpose>
+<refpurpose> Configure <productname>Slony-I</productname> set </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
@@ -770,7 +769,7 @@
<title>Description</title>
<para>
- In the <productname/Slony-I/ replication system, replicated tables are
+ In the <productname>Slony-I</productname> replication system, replicated tables are
organized in sets. As a general rule of thumb, a set should
contain all the tables of one application, that have
relationships. In a well designed application, this is equal
@@ -779,9 +778,9 @@
<para>
The smallest unit one node can subscribe for replication from
another node is a set. A set always has an origin. In
- classical replication terms, that would be the <quote/master./
- Since in <productname/Slony-I/ a node can be the <quote/master/ over one set,
- while receiving replication data in the <quote/slave/ role for
+ classical replication terms, that would be the <quote>master</quote>.
+ Since in <productname>Slony-I</productname> a node can be the <quote>master</quote> over one set,
+ while receiving replication data in the <quote>slave</quote> role for
another at the same time, this terminology may easily become
misleading and should therefore be replaced with <quote>set
origin</quote> and <quote>subscriber</quote>.
@@ -817,7 +816,7 @@
<refnamediv><refname>DROP SET</refname>
-<refpurpose> Configure <productname/Slony-I/ set </refpurpose>
+<refpurpose> Configure <productname>Slony-I</productname> set </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
@@ -828,7 +827,7 @@
<title>Description</title>
<para>
- Drop a set of tables from the <productname/Slony-I/ configuration. This
+ Drop a set of tables from the <productname>Slony-I</productname> configuration. This
automatically unsubscribes all nodes from the set and restores
the original triggers and rules on all subscribers.
</para>
@@ -858,7 +857,7 @@
<refnamediv><refname>MERGE SET</refname>
-<refpurpose> Reconfigure <productname/Slony-I/ sets </refpurpose>
+<refpurpose> Reconfigure <productname>Slony-I</productname> sets </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
@@ -878,7 +877,7 @@
</para>
<para>
This request will fail if the two sets do not have
- <emphasis/exactly/ the same set of subscribers. </para>
+ <emphasis>exactly</emphasis> the same set of subscribers. </para>
<variablelist>
<varlistentry><term><literal> ID = ival </literal></term>
@@ -909,7 +908,7 @@
<refnamediv><refname>SET ADD TABLE</refname>
-<refpurpose> Configure <productname/Slony-I/ set </refpurpose>
+<refpurpose> Configure <productname>Slony-I</productname> set </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
@@ -930,7 +929,7 @@
<listitem><para> ID of the set to which the table is to be added. </para>
</varlistentry>
<varlistentry><term><literal> ORIGIN = ival </literal></term>
- <listitem><para> Origin node for the set. A future version of <application/slonik/
+ <listitem><para> Origin node for the set. A future version of <application>slonik</application>
might figure out this information by itself.</para>
</varlistentry>
<varlistentry><term><literal> ID = ival </literal></term>
@@ -941,7 +940,7 @@
order in which the tables are locked in a <link
linkend="stmtlockset">LOCK SET</link> command for example. So
these numbers should represent any applicable table hierarchy to
- make sure the <application/slonik/ command scripts do not deadlock
+ make sure the <application>slonik</application> command scripts do not deadlock
at any critical moment.
</varlistentry>
<varlistentry><term><literal> FULLY QUALIFIED NAME = 'string' </literal></term>
@@ -985,7 +984,7 @@
<refnamediv><refname>SET ADD SEQUENCE</refname>
-<refpurpose> Configure <productname/Slony-I/ set </refpurpose>
+<refpurpose> Configure <productname>Slony-I</productname> set </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
@@ -1006,12 +1005,12 @@
<listitem><para> ID of the set to which the sequence is to be added. </para>
</varlistentry>
<varlistentry><term><literal> ORIGIN = ival </literal></term>
- <listitem><para> Origin node for the set. A future version of <application/slonik/
+ <listitem><para> Origin node for the set. A future version of <application>slonik</application>
might figure out this information by itself.</para>
</varlistentry>
<varlistentry><term><literal> ID = ival </literal></term>
- <listitem><para> Unique ID of the sequence. <note><para> Note that this ID needs to be unique <emphasis/across sequences/ throughout the cluster; the numbering of tables is separate, so you might have a table with ID 20 and a sequence with ID 20, and they would be recognized as separate. </note>
+ <listitem><para> Unique ID of the sequence. <note><para> Note that this ID needs to be unique <emphasis>across sequences</emphasis> throughout the cluster; the numbering of tables is separate, so you might have a table with ID 20 and a sequence with ID 20, and they would be recognized as separate. </note>
</varlistentry>
<varlistentry><term><literal> FULLY QUALIFIED NAME = 'string' </literal></term>
@@ -1044,7 +1043,7 @@
<refnamediv><refname>SET DROP TABLE</refname>
-<refpurpose> Configure <productname/Slony-I/ set </refpurpose>
+<refpurpose> Configure <productname>Slony-I</productname> set </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
@@ -1065,7 +1064,7 @@
<variablelist>
<varlistentry><term><literal> ORIGIN = ival </literal></term>
- <listitem><para> Origin node for the set. A future version of <application/slonik/
+ <listitem><para> Origin node for the set. A future version of <application>slonik</application>
might figure out this information by itself.</para>
</varlistentry>
<varlistentry><term><literal> ID = ival </literal></term>
@@ -1093,7 +1092,7 @@
<refnamediv><refname>SET DROP SEQUENCE</refname>
-<refpurpose> Configure <productname/Slony-I/ set </refpurpose>
+<refpurpose> Configure <productname>Slony-I</productname> set </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
@@ -1107,7 +1106,7 @@
Drops an existing user sequence from a replication set.
<variablelist>
<varlistentry><term><literal> ORIGIN = ival </literal></term>
- <listitem><para> Origin node for the set. A future version of <application/slonik/
+ <listitem><para> Origin node for the set. A future version of <application>slonik</application>
might figure out this information by itself.</para>
</varlistentry>
<varlistentry><term><literal> ID = ival </literal></term>
@@ -1134,7 +1133,7 @@
<refnamediv><refname>SET MOVE TABLE</refname>
-<refpurpose> Reconfigure <productname/Slony-I/ set </refpurpose>
+<refpurpose> Reconfigure <productname>Slony-I</productname> set </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
@@ -1157,7 +1156,7 @@
<variablelist>
<varlistentry><term><literal> ORIGIN = ival </literal></term>
- <listitem><para> Current origin of the set. A future version of <application/slonik/
+ <listitem><para> Current origin of the set. A future version of <application>slonik</application>
might figure out this information by itself.</para>
</varlistentry>
<varlistentry><term><literal> ID = ival </literal></term>
@@ -1187,7 +1186,7 @@
<refnamediv><refname>SET MOVE SEQUENCE</refname>
-<refpurpose> Reconfigure <productname/Slony-I/ set </refpurpose>
+<refpurpose> Reconfigure <productname>Slony-I</productname> set </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
@@ -1211,7 +1210,7 @@
<variablelist>
<varlistentry><term><literal> ORIGIN = ival </literal></term>
- <listitem><para> Origin node for the set. A future version of <application/slonik/
+ <listitem><para> Origin node for the set. A future version of <application>slonik</application>
might figure out this information by itself.</para>
</varlistentry>
<varlistentry><term><literal> ID = ival </literal></term>
@@ -1245,7 +1244,7 @@
<refnamediv><refname>STORE TRIGGER</refname>
-<refpurpose> Configure <productname/Slony-I/ set </refpurpose>
+<refpurpose> Configure <productname>Slony-I</productname> set </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
@@ -1268,7 +1267,7 @@
<varlistentry><term><literal> TRIGGER NAME = 'string' </literal></term>
<listitem><para> The name of the trigger as it appears in the
- <envar/pg_trigger/ system catalog.
+ <envar>pg_trigger</envar> system catalog.
</varlistentry>
<varlistentry><term><literal> EVENT NODE = ival </literal></term>
@@ -1298,7 +1297,7 @@
<refnamediv><refname>DROP TRIGGER</refname>
-<refpurpose> Reconfigure <productname/Slony-I/ set </refpurpose>
+<refpurpose> Reconfigure <productname>Slony-I</productname> set </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
@@ -1318,7 +1317,7 @@
<varlistentry><term><literal> TRIGGER NAME = 'string' </literal></term>
<listitem><para> The name of the trigger as it appears in the
- <envar/pg_trigger/ system catalog.
+ <envar>pg_trigger</envar> system catalog.
</varlistentry>
<varlistentry><term><literal> EVENT NODE = ival </literal></term>
@@ -1347,7 +1346,7 @@
<refnamediv><refname>SUBSCRIBE SET</refname>
-<refpurpose> Start replication of <productname/Slony-I/ set </refpurpose>
+<refpurpose> Start replication of <productname>Slony-I</productname> set </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
@@ -1363,7 +1362,7 @@
<para> The application tables contained in the set must already exist
and should ideally be empty. The current version of
-<productname/Slony-I/ will <emphasis/not/ attempt to copy the schema
+<productname>Slony-I</productname> will <emphasis>not</emphasis> attempt to copy the schema
of the set. The replication daemon will start copying the current
content of the set from the given provider and then try to catch up
with any update activity that happened during that copy process. After
@@ -1371,12 +1370,12 @@
using triggers, against accidental updates by the application.
</para>
-<para> If the tables on the subscriber are <emphasis/not/ empty, then
-the <command/COPY SET/ process winds up doing more work than should be
+<para> If the tables on the subscriber are <emphasis>not</emphasis> empty, then
+the <command>COPY SET</command> process winds up doing more work than should be
strictly necessary:
<itemizedlist>
-<listitem><para> It deletes all <quote/old/ entries in the table
-<listitem><para> Those old entries clutter up the table until it is next <command/VACUUM/ed <emphasis/after/ the subscription process is complete
+<listitem><para> It deletes all <quote>old</quote> entries in the table
+<listitem><para> Those old entries clutter up the table until it is next <command>VACUUM</command>ed <emphasis>after</emphasis> the subscription process is complete
<listitem><para> The indices for the table will contain entries for the old, deleted entries, which will slow the process of inserting new entries into the index.
</itemizedlist>
@@ -1388,7 +1387,7 @@
replication network. The normal reason to revise this
information is that you want a node to subscribe to a <emphasis>
different </emphasis> provider node, or for a node to become a
- <quote/forwarding/ subscriber so it may later become the
+ <quote>forwarding</quote> subscriber so it may later become the
provider
for a later subscriber. </note>
@@ -1439,7 +1438,7 @@
<refnamediv><refname>UNSUBSCRIBE SET</refname>
-<refpurpose> End replication of <productname/Slony-I/ set </refpurpose>
+<refpurpose> End replication of <productname>Slony-I</productname> set </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
@@ -1491,7 +1490,7 @@
<refnamediv><refname>LOCK SET</refname>
-<refpurpose> Configuration of <productname/Slony-I/ set </refpurpose>
+<refpurpose> Configuration of <productname>Slony-I</productname> set </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
<command>LOCK SET (options);</command>
@@ -1544,7 +1543,7 @@
<refnamediv><refname>UNLOCK SET</refname>
-<refpurpose> Configuration of <productname/Slony-I/ set </refpurpose>
+<refpurpose> Configuration of <productname>Slony-I</productname> set </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
<command>UNLOCK SET (options);</command>
@@ -1587,7 +1586,7 @@
<refnamediv><refname>MOVE SET</refname>
-<refpurpose> Reconfiguration of <productname/Slony-I/ set </refpurpose>
+<refpurpose> Reconfiguration of <productname>Slony-I</productname> set </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
<command>MOVE SET (options);</command>
@@ -1614,11 +1613,11 @@
activity.
</para>
<para>
- This is <emphasis/not/ failover, as it requires a functioning
+ This is <emphasis>not</emphasis> failover, as it requires a functioning
old origin node (you needed to lock the set on the old
- origin). You would probably prefer to <command/MOVE SET/
- instead of <command/FAILOVER/, if at all possible, as
- <command/FAILOVER/ winds up discarding the old origin node as
+ origin). You would probably prefer to <command>MOVE SET</command>
+ instead of <command>FAILOVER</command>, if at all possible, as
+ <command>FAILOVER</command> winds up discarding the old origin node as
being corrupted.
@@ -1657,7 +1656,7 @@
<refnamediv><refname>FAILOVER</refname>
-<refpurpose> Reconfiguration of <productname/Slony-I/ set </refpurpose>
+<refpurpose> Reconfiguration of <productname>Slony-I</productname> set </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
<command>FAILOVER (options);</command>
@@ -1668,7 +1667,7 @@
<para>
The failover command causes the backup node to take over all
- sets that currently originate on the failed node. <Application/Slonik/ will
+ sets that currently originate on the failed node. <Application>Slonik</Application> will
contact all other direct subscribers of the failed node to
determine which node has the highest sync status for each
set. If another node has a higher sync status than the backup
@@ -1719,7 +1718,7 @@
<refnamediv><refname>EXECUTE SCRIPT</refname>
-<refpurpose> Reconfiguration of <productname/Slony-I/ set </refpurpose>
+<refpurpose> Reconfiguration of <productname>Slony-I</productname> set </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
<command>EXECUTE SCRIPT (options);</command>
@@ -1733,11 +1732,11 @@
the replication transaction stream.</para>
<para> The specified event origin must be the origin of the set. The
-script file must not contain any <command/START/ or <command/COMMIT
+script file must not contain any <command>START</command> or <command>COMMIT</command>
TRANSACTION/ calls. (This may change in PostgreSQL 8.0 once nested
transactions, aka savepoints, are supported) In addition,
non-deterministic DML statements (like updating a field with
-<function/CURRENT_TIMESTAMP/) must be avoided, since the data changes
+<function>CURRENT_TIMESTAMP</function>) must be avoided, since the data changes
done by the script are explicitly not replicated. </para>
<variablelist>
@@ -1749,10 +1748,10 @@
<listitem><para> The name of the file containing the SQL script to
execute. This might be a relative path, relative to the location of
- the <application/slonik/ instance you are running, or, preferably,
- an absolute path on the system where <application/slonik/ is to run.
+ the <application>slonik</application> instance you are running, or, preferably,
+ an absolute path on the system where <application>slonik</application> is to run.
- <para> The <emphasis/contents/ of the file are propagated as part of
+ <para> The <emphasis>contents</emphasis> of the file are propagated as part of
the event, so the file does not need to be accessible on any of the
nodes.
@@ -1788,62 +1787,61 @@
</Refentry>
-<!-- **************************************** -->
-
<refentry id ="stmtwaitevent"><refmeta><refentrytitle>WAIT FOR EVENT</refentrytitle> </refmeta>
<refnamediv><refname>WAIT FOR EVENT</refname>
-<refpurpose> Reconfiguration of <productname/Slony-I/ set </refpurpose>
+<refpurpose> Reconfiguration of <productname>Slony-I</productname> set </refpurpose>
<refsynopsisdiv>
<cmdsynopsis>
<command>WAIT FOR EVENT (options);</command>
</cmdsynopsis>
</refsynopsisdiv>
+
<refsect1>
<title>Description</title>
-<para> Waits for event Confirmation.
+<para> Waits for event Confirmation.</para>
-<para> <Application/Slonik/ remembers the last event generated on
+<para> <Application>slonik</Application> remembers the last event generated on
every node during script execution (events generated by earlier calls
are currently not checked). In certain situations it is necessary that
events generated on one node (such as <command>CREATE SET</command>)
are processed on another node before issuing more commands (for
-instance, <link linkend="stmtsubscribeset"><command/SUBSCRIBE
-SET/</link>). <COMMAND>WAIT FOR EVENT</COMMAND> may be used to cause
-the <application/slonik/ script to wait until the subscriber node is
+instance, <link linkend="stmtsubscribeset"><command>SUBSCRIBE
+SET</command></link>). <COMMAND>WAIT FOR EVENT</COMMAND> may be used to cause
+the <application>slonik</application> script to wait until the subscriber node is
ready for the next action.
</para>
<para> <command>WAIT FOR EVENT</command> must be called outside of any
-<command/try/ block in order to work, since new confirm messages don't
-become visible within a transaction.
+<command>try</command> block in order to work, since new confirm messages don't
+become visible within a transaction.</para>
<variablelist>
<varlistentry><term><literal> ORIGIN = ival | ALL </literal></term>
- <listitem><para> The origin of the event(s) to wait for.
+ <listitem><para> The origin of the event(s) to wait for.</para></listitem>
</varlistentry>
<varlistentry><term><literal> CONFIRMED = ival | ALL </literal></term>
- <listitem><para> The node ID of the receiver that must confirm the event(s).
+ <listitem><para> The node ID of the receiver that must confirm the event(s).</para></listitem>
</varlistentry>
<varlistentry><term><literal> WAIT ON = ival </literal></term>
- <listitem><para> The ID of the node where the sl_confirm table is to be checked. The default value is 1.
+ <listitem><para> The ID of the node where the sl_confirm table is to be checked. The default value is 1.</para></listitem>
</varlistentry>
<varlistentry><term><literal> TIMEOUT = ival </literal></term>
<listitem><para> The number of seconds to wait. Default is 600 (10
- minutes). <command/TIMEOUT = 0/ causes the script to wait
- indefinitely.
+ minutes). <command>TIMEOUT = 0</command> causes the script to wait
+ indefinitely.</para></listitem>
</varlistentry>
</variablelist>
-
</Refsect1>
+
<Refsect1><Title>Example</Title>
<Programlisting>
WAIT FOR EVENT (
@@ -1854,8 +1852,8 @@
</Programlisting>
</Refsect1>
</Refentry>
-</reference>
+</reference>
<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
Index: help.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/help.sgml,v
retrieving revision 1.5
retrieving revision 1.6
diff -Ldoc/adminguide/help.sgml -Ldoc/adminguide/help.sgml -u -w -r1.5 -r1.6
--- doc/adminguide/help.sgml
+++ doc/adminguide/help.sgml
@@ -1,4 +1,7 @@
-<sect1 id="help"> <title> More Slony-I Help </title>
+<!-- $Id -->
+<article>
+<sect1 id="help">
+<title>More Slony-I Help</title>
<para>If you are having problems with Slony-I, you have several
options for help:
@@ -44,9 +47,9 @@
Slonik script</para></listitem>
</itemizedlist>
-
</sect2>
</sect1>
+</article>
<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
Index: cluster.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/cluster.sgml,v
retrieving revision 1.5
retrieving revision 1.6
diff -Ldoc/adminguide/cluster.sgml -Ldoc/adminguide/cluster.sgml -u -w -r1.5 -r1.6
--- doc/adminguide/cluster.sgml
+++ doc/adminguide/cluster.sgml
@@ -1,4 +1,6 @@
-<sect1 id="cluster"> <title>Defining Slony-I Clusters</title>
+<!-- $Id -->
+<sect1 id="cluster">
+<title>Defining Slony-I Clusters</title>
<para>A <productname>Slony-I</productname> cluster is the basic
grouping of database instances in which replication takes place. It
@@ -7,21 +9,21 @@
cluster.</para>
<para>Each database instance in which replication is to take place is
-identified by a node number.
+identified by a node number.</para>
<para>For a simple install, it may be reasonable for the origin to be
-node #1, and for the subscriber to be node #2.
+node #1, and for the subscriber to be node #2.</para>
<para>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.
+order in which nodes were initialized.</para>
<para>It may be that in version 1.1, nodes will also have a
-<quote/name/ attribute, so that they may be given more mnemonic names.
+<quote>name</quote> 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.
+be the node name that is used to organize the cluster.</para>
</sect1>
<!-- Keep this comment at the end of the file
Index: concepts.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/concepts.sgml,v
retrieving revision 1.5
retrieving revision 1.6
diff -Ldoc/adminguide/concepts.sgml -Ldoc/adminguide/concepts.sgml -u -w -r1.5 -r1.6
--- doc/adminguide/concepts.sgml
+++ doc/adminguide/concepts.sgml
@@ -1,74 +1,76 @@
-<sect1 id="concepts"> <title><productname/Slony-I/ Concepts</title>
+<!-- $Id -->
+<sect1 id="concepts">
+<title><productname>Slony-I</productname> Concepts</title>
-<para>In order to set up a set of <productname/Slony-I/ replicas, it is necessary to
-understand the following major abstractions that it uses:
+<para>In order to set up a set of <productname>Slony-I</productname> replicas, it is necessary to
+understand the following major abstractions that it uses:</para>
<itemizedlist>
- <listitem><para> Cluster
- <listitem><para> Node
- <listitem><para> Replication Set
- <listitem><para> Origin, Providers and Subscribers
+ <listitem><para>Cluster</para></listitem>
+ <listitem><para>Node</para></listitem>
+ <listitem><para>Replication Set</para></listitem>
+ <listitem><para>Origin, Providers and Subscribers</para></listitem>
</itemizedlist>
-<sect2><title>Cluster</title>
+<sect2>
+<title>Cluster</title>
-<para>In <productname/Slony-I/ terms, a Cluster is a named set of PostgreSQL
-database instances; replication takes place between those databases.
+<para>In <productname>Slony-I</productname> terms, a Cluster is a named set of PostgreSQL
+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>The cluster name is specified in each and every Slonik script via the directive:</para>
<programlisting>
cluster name = 'something';
</programlisting>
-<para>If the Cluster name is <envar/something/, then <productname/Slony-I/ will
-create, in each database instance in the cluster, the namespace/schema
-<envar/_something/.
-
+<para>If the Cluster name is <envar>something</envar>, then <productname>Slony-I</productname> will
+create, in each database instance in the cluster, the namespace/schema <envar>_something.</envar></para>
+</sect2>
<sect2><title> Node</title>
-<para>A <productname/Slony-I/ Node is a named PostgreSQL database that will be participating in replication.
+<para>A <productname>Slony-I</productname> Node is a named PostgreSQL database that will be participating in replication.</para>
-<para>It is defined, near the beginning of each Slonik script, using the directive:
+<para>It is defined, near the beginning of each Slonik script, using the directive:</para>
<programlisting>
NODE 1 ADMIN CONNINFO = 'dbname=testdb host=server1 user=slony';
</programlisting>
-<para>The <link linkend="admconninfo"> <command/CONNINFO/</link>
+<para>The <link linkend="admconninfo"><command>CONNINFO</command></link>
information indicates a string argument that will ultimately be passed
-to the <function>PQconnectdb()</function> libpq function.
+to the <function>PQconnectdb()</function> libpq function.</para>
-<para>Thus, a <productname/Slony-I/ cluster consists of:
+<para>Thus, a <productname>Slony-I</productname> cluster consists of:</para>
<itemizedlist>
- <listitem><para> A cluster name
- <listitem><para> A set of <productname/Slony-I/ nodes, each of which has a namespace based on that cluster name
+ <listitem><para> A cluster name</para></listitem>
+ <listitem><para> A set of <productname>Slony-I</productname> nodes, each of which has a namespace based on that cluster name</para></listitem>
</itemizedlist>
-
+</sect2>
<sect2><title> Replication Set</title>
<para>A replication set is defined as a set of tables and sequences
-that are to be replicated between nodes in a <productname/Slony-I/ cluster.
-
-<para>You may have several sets, and the <quote/flow/ of replication does
-not need to be identical between those sets.
+that are to be replicated between nodes in a <productname>Slony-I</productname> cluster.</para>
+<para>You may have several sets, and the <quote>flow</quote> of replication does
+not need to be identical between those sets.</para>
+</sect2>
<sect2><title> Origin, Providers and Subscribers</title>
<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/; it is the main place from
-which data is provided.
+also be termed the <quote>master provider</quote>; it is the main place from
+which data is provided.</para>
<para>Other nodes in the cluster will subscribe to the replication
-set, indicating that they want to receive the data.
+set, indicating that they want to receive the data.</para>
-<para>The origin node will never be considered a <quote/subscriber./
+<para>The origin node will never be considered a <quote>subscriber.</quote>
(Ignoring the case where the cluster is reshaped, and the origin is
-moved to another node.) But <productname/Slony-I/ supports the notion of cascaded
+moved to another node.) But <productname>Slony-I</productname> supports the notion of cascaded
subscriptions, that is, a node that is subscribed to the origin may
-also behave as a <quote/provider/ to other nodes in the cluster.
-
+also behave as a <quote>provider</quote> to other nodes in the cluster.</para>
+</sect2>
</sect1>
<!-- Keep this comment at the end of the file
Index: maintenance.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/maintenance.sgml,v
retrieving revision 1.5
retrieving revision 1.6
diff -Ldoc/adminguide/maintenance.sgml -Ldoc/adminguide/maintenance.sgml -u -w -r1.5 -r1.6
--- doc/adminguide/maintenance.sgml
+++ doc/adminguide/maintenance.sgml
@@ -1,19 +1,21 @@
+<!-- $Id -->
+<article>
<sect1 id="maintenance"> <title>Slony-I Maintenance</title>
-<para><productname/Slony-I/ actually does most of its necessary
+<para><productname>Slony-I</productname> actually does most of its necessary
maintenance itself, in a <quote>cleanup</quote> thread:
<itemizedlist>
<listitem><para> Deletes old data from various tables in the
-<productname/Slony-I/ cluster's namespace, notably entries in
-sl_log_1, sl_log_2 (not yet used), and sl_seqlog.
+<productname>Slony-I</productname> cluster's namespace, notably entries in
+sl_log_1, sl_log_2 (not yet used), and sl_seqlog.</para></listitem>
-<listitem><para> Vacuum certain tables used by <productname/Slony-I/.
+<listitem><para> Vacuum certain tables used by <productname>Slony-I</productname>.
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 <productname/Slony-I/ raises plenty of events, which
-leads to that table having plenty of dead tuples.
+down because <productname>Slony-I</productname> raises plenty of events, which
+leads to that table having plenty of dead tuples.</para>
<para> 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
@@ -27,64 +29,67 @@
<para>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.</para>
+pg_listener growing large and will slow replication.</para></listitem>
</itemizedlist>
+</para>
<sect2><title> Watchdogs: Keeping Slons Running</title>
-<para>There are a couple of <quote/watchdog/ scripts available that
-monitor things, and restart the <application/slon/ processes should
-they happen to die for some reason, such as a network <quote/glitch/
-that causes loss of connectivity.
-
-<para>You might want to run them...
+<para>There are a couple of <quote>watchdog</quote> scripts available that
+monitor things, and restart the <application>slon</application> processes should
+they happen to die for some reason, such as a network <quote>glitch</quote>
+that causes loss of connectivity.</para>
+<para>You might want to run them...</para>
+</sect2>
<sect2><title>Alternative to Watchdog: generate_syncs.sh</title>
-<para>A new script for <productname/Slony-I/ 1.1 is
-<application/generate_syncs.sh/, which addresses the following kind of
-situation.
+<para>A new script for <productname>Slony-I</productname> 1.1 is
+<application>generate_syncs.sh</application>, which addresses the following kind of
+situation.</para>
<para>Supposing you have some possibly-flakey server where the
-<application/slon/ daemon that might not run all the time, you might
-return from a weekend away only to discover the following situation...
+<application>slon</application> daemon that might not run all the time, you might
+return from a weekend away only to discover the following situation.</para>
-<para>On Friday night, something went <quote/bump/ and while the
-database came back up, none of the <application/slon/ daemons
+<para>On Friday night, something went <quote>bump</quote> and while the
+database came back up, none of the <application>slon</application> daemons
survived. Your online application then saw nearly three days worth of
-reasonably heavy transaction load.
+reasonably heavy transaction load.</para>
<para>When you restart slon on Monday, it hasn't done a SYNC on the
-master since Friday, so that the next <quote/SYNC set/ comprises all
-of the updates between Friday and Monday. Yuck.
+master since Friday, so that the next <quote>SYNC set</quote> comprises all
+of the updates between Friday and Monday. Yuck.</para>
-<para>If you run <application/generate_syncs.sh/ as a cron job every
-20 minutes, it will force in a periodic <command/SYNC/ on the origin, which
+<para>If you run <application>generate_syncs.sh</application> as a cron job every
+20 minutes, it will force in a periodic <command>SYNC</command> 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.
-
-<para>Note that if <command/SYNC/s <emphasis>are</emphasis> running
-regularly, this script won't bother doing anything.
+the cleanup a lot less unpleasant.</para>
+<para>Note that if <command>SYNC</command>s <emphasis>are</emphasis> running
+regularly, this script won't bother doing anything.</para>
+</sect2>
<sect2><title> Log Files</title>
-<para><link linkend="slon"> <application/slon/ </link> daemons
+<para><link linkend="slon"> <application>slon</application></link> daemons
generate some more-or-less verbose log files, depending on what
debugging level is turned on. You might assortedly wish to:
<itemizedlist>
-<listitem><para> Use a log rotator like <productname/Apache/
-<application/rotatelogs/ to have a sequence of log files so that no
-one of them gets too big;
+<listitem><para> Use a log rotator like <productname>Apache</productname>
+<application>rotatelogs</application> to have a sequence of log files so that no
+one of them gets too big;</para></listitem>
-<listitem><para> Purge out old log files, periodically.</para>
+<listitem><para> Purge out old log files, periodically.</para></listitem>
</itemizedlist>
+</para>
</sect2>
</sect1>
+</article>
<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
Index: firstdb.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/firstdb.sgml,v
retrieving revision 1.5
retrieving revision 1.6
diff -Ldoc/adminguide/firstdb.sgml -Ldoc/adminguide/firstdb.sgml -u -w -r1.5 -r1.6
--- doc/adminguide/firstdb.sgml
+++ doc/adminguide/firstdb.sgml
@@ -1,4 +1,6 @@
-<sect1 id="firstdb"><title/Replicating Your First Database/
+<!-- $Id -->
+<article>
+<sect1 id="firstdb"><title>Replicating Your First Database</title>
<para>In this example, we will be replicating a brand new pgbench
database. The mechanics of replicating an existing database are
@@ -31,40 +33,48 @@
<para>You should also set the following shell variables:
<itemizedlist>
-<listitem><para> <envar/CLUSTERNAME/=slony_example
-<listitem><para> <envar/MASTERDBNAME/=pgbench
-<listitem><para> <envar/SLAVEDBNAME/=pgbenchslave
-<listitem><para> <envar/MASTERHOST/=localhost
-<listitem><para> <envar/SLAVEHOST/=localhost
-<listitem><para> <envar/REPLICATIONUSER/=pgsql
-<listitem><para> <envar/PGBENCHUSER/=pgbench
+<listitem><para> <envar>CLUSTERNAME</envar>=slony_example</para></listitem>
+<listitem><para> <envar>MASTERDBNAME</envar>=pgbench</para></listitem>
+<listitem><para> <envar>SLAVEDBNAME</envar>=pgbenchslave</para></listitem>
+<listitem><para> <envar>MASTERHOST</envar>=localhost</para></listitem>
+<listitem><para> <envar>SLAVEHOST</envar>=localhost</para></listitem>
+<listitem><para> <envar>REPLICATIONUSER</envar>=pgsql</para></listitem>
+<listitem><para> <envar>PGBENCHUSER</envar>=pgbench</para></listitem>
</itemizedlist>
+</para>
<para>Here are a couple of examples for setting variables in common shells:
<itemizedlist>
-<listitem><Para> bash, sh, ksh
- <command/export CLUSTERNAME=slony_example/
-<listitem><Para> (t)csh:
- <command/setenv CLUSTERNAME slony_example/
+<listitem>
+ <para>bash, sh, ksh
+ <command>export CLUSTERNAME=slony_example</command></para>
+</listitem>
+<listitem>
+ <para>(t)csh:
+ <command>setenv CLUSTERNAME slony_example</command></para>
+</listitem>
</itemizedlist>
+</para>
<para><warning><Para> If you're changing these variables to use
-different hosts for <envar/MASTERHOST/ and <envar/SLAVEHOST/, be sure
-<emphasis/not/ to use localhost for either of them. This will result
-in an error similar to the following:
+different hosts for <envar>MASTERHOST</envar> and <envar>SLAVEHOST</envar>, be sure
+<emphasis>not</emphasis> to use localhost for either of them. This will result
+in an error similar to the following:</para>
<para><command>
ERROR remoteListenThread_1: db_getLocalNodeId() returned 2 - wrong database?
-</command>
+</command></para>
</warning></para>
-<sect2><title/ Creating the pgbenchuser/
+
+<sect2><title>Creating the pgbenchuser</title>
<para><command>
createuser -A -D $PGBENCHUSER
</command>
-
-<sect2><title/ Preparing the databases/
+</para>
+</sect2>
+<sect2><title>Preparing the databases</title>
<programlisting>
createdb -O $PGBENCHUSER -h $MASTERHOST $MASTERDBNAME
@@ -72,48 +82,51 @@
pgbench -i -s 1 -U $PGBENCHUSER -h $MASTERHOST $MASTERDBNAME
</programlisting>
-<para>Because <productname/Slony-I/ depends on the databases having the pl/pgSQL procedural
+<para>Because <productname>Slony-I</productname> 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.
+step because it's already installed into the <envar>$MASTERDBNAME</envar>.
<programlisting>
createlang plpgsql -h $MASTERHOST $MASTERDBNAME
</programlisting>
-
-<para><productname/Slony-I/ does not yet automatically copy table definitions from a
+</para>
+<para><productname>Slony-I</productname> 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 <application/pg_dump/.
+We do this with <application>pg_dump</application>.
<programlisting>
pg_dump -s -U $REPLICATIONUSER -h $MASTERHOST $MASTERDBNAME | psql -U $REPLICATIONUSER -h $SLAVEHOST $SLAVEDBNAME
</programlisting>
+</para>
-<para>To illustrate how <productname/Slony-I/ allows for on the fly
-replication subscription, let's start up <application/pgbench/. If
-you run the <application/pgbench/ application in the foreground of a
+<para>To illustrate how <productname>Slony-I</productname> allows for on the fly
+replication subscription, let's start up <application>pgbench</application>. If
+you run the <application>pgbench</application> 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.
-
-<para>The typical command to run <application/pgbench/ would look like:
+</para>
+<para>The typical command to run <application>pgbench</application> would look like:
<programlisting>
pgbench -s 1 -c 5 -t 1000 -U $PGBENCHUSER -h $MASTERHOST $MASTERDBNAME
</programlisting>
+</para>
-<para>This will run <application/pgbench/ with 5 concurrent clients
-each processing 1000 transactions against the <application/pgbench/
+<para>This will run <application>pgbench</application> with 5 concurrent clients
+each processing 1000 transactions against the <application>pgbench</application>
database running on localhost as the pgbench user.
+</para></sect2>
-<sect2><title/ Configuring the Database for Replication./
+<sect2><title>Configuring the Database for Replication.</title>
<para>Creating the configuration tables, stored procedures, triggers
-and configuration is all done through the <link linkend="slonik">
-<application/slonik/ </link> 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:
+and configuration is all done through the
+<link linkend="slonik"><application>slonik</application></link> 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:
<programlisting>
#!/bin/sh
@@ -176,28 +189,27 @@
_EOF_
</programlisting>
-<para>Is the <application/pgbench/ still running? If not start it
-again.
-
+<para>Is the <application>pgbench</application> still running? If not start it
+again.</para>
<para>At this point we have 2 databases that are fully prepared. One
-is the master database in which <application/pgbench/ is busy
+is the master database in which <application>pgbench</application> is busy
accessing and changing rows. It's now time to start the replication
-daemons.
+daemons.</para>
<para>On $MASTERHOST the command to start the replication engine is
<programlisting>
slon $CLUSTERNAME "dbname=$MASTERDBNAME user=$REPLICATIONUSER host=$MASTERHOST"
</programlisting>
-
+</para>
<para>Likewise we start the replication system on node 2 (the slave)
<programlisting>
slon $CLUSTERNAME "dbname=$SLAVEDBNAME user=$REPLICATIONUSER host=$SLAVEHOST"
</programlisting>
-
-<para>Even though we have the <application><link linkend="slon"> slon
-</link></application> running on both the master and slave, and they
+</para>
+<para>Even though we have the <application><link linkend="slon">slon</link></application>
+ 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
@@ -231,8 +243,8 @@
subscribe set ( id = 1, provider = 1, receiver = 2, forward = no);
_EOF_
</programlisting>
-
-<para>Any second now, the replication daemon on $SLAVEHOST will start
+</para>
+<para>Any second now, the replication daemon on <envar>$SLAVEHOST</envar> 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
@@ -251,7 +263,7 @@
are in fact the same.</para>
<para>The following script will create ordered dumps of the 2
-databases and compare them. Make sure that <application/pgbench/ has
+databases and compare them. Make sure that <application>pgbench</application> has
completed its testing, and that your slon sessions have caught up.
<programlisting>
@@ -287,7 +299,8 @@
else
echo "FAILED - see $CLUSTERNAME.diff for database differences"
fi
-</programlisting></para>
+</programlisting>
+</para>
<para>Note that there is somewhat more sophisticated documentation of
the process in the <productname>Slony-I</productname> source code tree
@@ -299,6 +312,7 @@
http://slony.info/</ulink></para>
</sect1>
+</article>
<!-- Keep this comment at the end of the file
Local variables:
Index: bookindex.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/bookindex.sgml,v
retrieving revision 1.1
retrieving revision 1.2
diff -Ldoc/adminguide/bookindex.sgml -Ldoc/adminguide/bookindex.sgml -u -w -r1.1 -r1.2
--- doc/adminguide/bookindex.sgml
+++ doc/adminguide/bookindex.sgml
@@ -1,3 +1,4 @@
+<!-- $Id -->
<index>
<!-- This file was produced by collateindex.pl. -->
Index: prerequisites.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/prerequisites.sgml,v
retrieving revision 1.4
retrieving revision 1.5
diff -Ldoc/adminguide/prerequisites.sgml -Ldoc/adminguide/prerequisites.sgml -u -w -r1.4 -r1.5
--- doc/adminguide/prerequisites.sgml
+++ doc/adminguide/prerequisites.sgml
@@ -1,15 +1,16 @@
+<!-- $Id -->
<article id="requirements">
<title>System Requirements</title>
<sect1>
<title>System Requirements</title>
<para>Any platform that can run PostgreSQL should be able to run
-<productname>Slony-I</productname>.
+<productname>Slony-I</productname>.</para>
<para>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,
-<trademark/Solaris/-2.8-SPARC, <trademark/Solaris/-2.9-SPARC, AIX 5.1
-and OpenBSD-3.5-sparc64.
+<trademark>Solaris</trademark>-2.8-SPARC, <trademark>Solaris</trademark>-2.9-SPARC, AIX 5.1
+and OpenBSD-3.5-sparc64.</para>
<para>There have been reports of success at running
<productname>Slony-I</productname> hosts that are running PostgreSQL
@@ -20,7 +21,7 @@
run on <trademark>Windows</trademark>, but a <application><link
linkend="slon"> slon </link></application> running on one of the
Unix-like systems has no reason to have difficulty connect to a
-PostgreSQL instance running on <trademark>Windows</trademark>.
+PostgreSQL instance running on <trademark>Windows</trademark>.</para>
<para> It ought to be possible to port <application><link
linkend="slon"> slon </link></application> and <application><link
@@ -38,45 +39,45 @@
<title> Software needed</title>
<para>
<itemizedlist>
-
<listitem><para> GNU make. Other make programs will not work. GNU
make is often installed under the name <command>gmake</command>; 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 <command>make</command>) To test to see if your make is GNU
make enter <command>make version</command>. Version 3.76 or later
-will suffice; previous versions may not.
+will suffice; previous versions may not.</para></listitem>
<listitem><para> You need an ISO/ANSI C compiler. Recent versions of
-<application>GCC</application> work.
+<application>GCC</application> work.</para></listitem>
<listitem><para> You also need a recent version of PostgreSQL
<emphasis>source</emphasis>. <productname>Slony-I</productname>
-depends on namespace support so you must have version 7.3.3 or newer
+depends on namespace support so you must have PostgreSQL version 7.3.3 or newer
to be able to build and use <productname>Slony-I</productname>. Rod
Taylor has <quote>hacked up</quote> a version of
<productname>Slony-I</productname> 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 <application><productname>Slony-I</productname></application>
-release.
+release.</para></listitem>
<listitem><para> 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 <ulink
url="http://www.gnu.org/order/ftp.html">
http://www.gnu.org/order/ftp.html </ulink> for a list) or at <ulink
-url="ftp://ftp.gnu.org/gnu"> ftp://ftp.gnu.org/gnu </ulink> .)
+url="ftp://ftp.gnu.org/gnu"> ftp://ftp.gnu.org/gnu </ulink> .)</para></listitem>
<listitem><para> If you need to obtain PostgreSQL source, you can
download it from your favorite PostgreSQL mirror. See <ulink
url="http://www.postgresql.org/mirrors-www.html">
-http://www.postgresql.org/mirrors-www.html </ulink> for a list.
+http://www.postgresql.org/mirrors-www.html </ulink> for a list.</para></listitem>
</itemizedlist>
-
+</para>
<para>Also check to make sure you have sufficient disk space. You
will need approximately 5MB for the source tree during build and
-installation.</sect1>
+installation.</para>
+</sect1>
<sect1>
<title> Getting <productname>Slony-I</productname>Source</title>
@@ -96,15 +97,15 @@
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 <quote>master</quote>
-provider node as their time server.
+provider node as their time server.</para>
<para> It is possible for <productname>Slony-I</productname> to
function even in the face of there being some time discrepancies, but
having systems <quote>in sync</quote> is usually pretty important for
-distributed applications.
+distributed applications.</para>
<para> See <ulink url="http://www.ntp.org/"> www.ntp.org </ulink> for
-more details about NTP (Network Time Protocol).
+more details about NTP (Network Time Protocol).</para>
</sect1>
@@ -117,7 +118,7 @@
B to A. It is recommended that all nodes in a
<productname>Slony-I</productname> cluster allow this sort of
bidirection communications from any node in the cluster to any other
-node in the cluster.
+node in the cluster.</para>
<para>Note that the network addresses need to be consistent across all
of the nodes. Thus, if there is any need to use a
@@ -125,18 +126,18 @@
that <quote>public</quote> address needs to be able to be used
consistently throughout the <productname>Slony-I</productname>
cluster, as the address is propagated throughout the cluster in table
-<envar>sl_path</envar>.
+<envar>sl_path</envar>.</para>
<para>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.
+IP address 127.0.0.1, with a different port for each destination.</para>
<para> Note that <application>slonik</application> and the
<application>slon</application> instances need no special connections
or protocols to communicate with one another; they just need to be
able to get access to the <application>PostgreSQL</application>
-databases, connecting as a <quote>superuser</quote>.
+databases, connecting as a <quote>superuser</quote>.</para>
<para> An implication of the communications model is that the entire
extended network in which a <productname>Slony-I</productname> cluster
@@ -149,7 +150,7 @@
applied at the <emphasis>weakest</emphasis> link. Running a
full-blown <productname>Slony-I</productname> node at a branch
location that can't be kept secure compromises security for the
-cluster.
+cluster.</para>
<para>In the future plans is a feature whereby updates for a
particular replication set would be serialized via a scheme called
@@ -161,7 +162,7 @@
sort of <quote>avian transmission protocol.</quote> This will allow
one way communications so that <quote>subscribers</quote> that use log
shipping would have no need for access to other
-<productname>Slony-I</productname> nodes.
+<productname>Slony-I</productname> nodes.</para>
</sect1>
</article>
<!-- Keep this comment at the end of the file
Index: subscribenodes.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/subscribenodes.sgml,v
retrieving revision 1.5
retrieving revision 1.6
diff -Ldoc/adminguide/subscribenodes.sgml -Ldoc/adminguide/subscribenodes.sgml -u -w -r1.5 -r1.6
--- doc/adminguide/subscribenodes.sgml
+++ doc/adminguide/subscribenodes.sgml
@@ -1,4 +1,6 @@
-<sect1 id="subscribenodes"> <title/ Subscribing Nodes/
+<!-- $Id -->
+<article>
+<sect1 id="subscribenodes"> <title>Subscribing Nodes</title>
<para>Before you subscribe a node to a set, be sure that you have
<application><link linkend="slon"> slon </link></application>
@@ -47,25 +49,25 @@
subscribe it.</para>
<para>When you subscribe a node to a set, you should see something
-like this in your <application/slon/ logs for the provider node:
+like this in your <application>slon</application> logs for the provider node:
<screen>
DEBUG2 remoteWorkerThread_3: Received event 3,1059 SUBSCRIBE_SET
</screen>
-
+</para>
<para>You should also start seeing log entries like this in the
-<application/slon/ logs for the subscribing node:
+<application>slon</application> logs for the subscribing node:
<screen>
DEBUG2 remoteWorkerThread_1: copy table public.my_table
</screen>
-
+</para>
<para>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.
-
-<para>The table <envar/sl_subscribe/ on both the provider, and the new
+</para>
+<para>The table <envar>sl_subscribe</envar> on both the provider, and the new
subscriber should contain entries for the new subscription:
<screen>
@@ -73,12 +75,13 @@
---------+--------------+--------------+-------------+------------
1 | 1 | 2 | t | t
</screen>
-
+</para>
<para>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.
+</para>
</sect1>
-
+</article>
<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
Index: legal.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/legal.sgml,v
retrieving revision 1.2
retrieving revision 1.3
diff -Ldoc/adminguide/legal.sgml -Ldoc/adminguide/legal.sgml -u -w -r1.2 -r1.3
--- doc/adminguide/legal.sgml
+++ doc/adminguide/legal.sgml
@@ -41,12 +41,12 @@
SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.
</para>
- <para> Note that <trademark/UNIX/ is a registered trademark of The
- Open Group. <trademark/Windows/ is a registered trademark of
+ <para> Note that <trademark>UNIX</trademark> is a registered trademark of The
+ Open Group. <trademark>Windows</trademark> is a registered trademark of
Microsoft Corporation in the United States and other countries.
- <trademark/Solaris/ is a registered trademark of Sun Microsystems,
- Inc. <trademark/Linux/ is a trademark of Linus Torvalds.
-
+ <trademark>Solaris</trademark> is a registered trademark of Sun Microsystems,
+ Inc. <trademark>Linux</trademark> is a trademark of Linus Torvalds.
+</para>
</legalnotice>
<!-- Keep this comment at the end of the file
Index: faq.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/faq.sgml,v
retrieving revision 1.5
retrieving revision 1.6
diff -Ldoc/adminguide/faq.sgml -Ldoc/adminguide/faq.sgml -u -w -r1.5 -r1.6
--- doc/adminguide/faq.sgml
+++ doc/adminguide/faq.sgml
@@ -1,27 +1,28 @@
+<!-- $Id -->
<qandaset>
<qandaentry>
-<question><para>I looked for the <envar/_clustername/ namespace, and
-it wasn't there.</question>
+<question><para>I looked for the <envar>_clustername</envar> namespace, and
+it wasn't there.</para></question>
<answer><para> If the DSNs are wrong, then <link linkend="slon">
-<application/slon/ </link> instances can't connect to the nodes.
+<application>slon</application></link> instances can't connect to the nodes.</para>
-<para>This will generally lead to nodes remaining entirely untouched.
+<para>This will generally lead to nodes remaining entirely untouched.</para>
<para>Recheck the connection configuration. By the way, since <link
-linkend="slon"> <application/slon/ </link> links to libpq, you could
+linkend="slon"><application>slon</application></link> links to libpq, you could
have password information stored in <filename>
<envar>$HOME</envar>/.pgpass</filename>, partially filling in
-right/wrong authentication information there.
+right/wrong authentication information there.</para>
</answer>
</qandaentry>
<qandaentry id="SlonyFAQ02">
<question><para> Some events are moving around, but no replication is
-taking place.
+taking place.</para>
<para> Slony logs might look like the following:
@@ -29,6 +30,8 @@
DEBUG1 remoteListenThread_1: connected to 'host=host004 dbname=pgbenchrep user=postgres port=5432'
ERROR remoteListenThread_1: "select ev_origin, ev_seqno, ev_timestamp, ev_minxid, ev_maxxid, ev_xip, ev_type, ev_data1, ev_data2, ev_data3, ev_data4, ev_data5, ev_data6, ev_data7, ev_data8 from "_pgbenchtest".sl_event e where (e.ev_origin = '1' and e.ev_seqno > '1') order by e.ev_origin, e.ev_seqno" - could not receive data from server: Operation now in progress
</screen>
+</para>
+</question>
<answer><para>On AIX and Solaris (and possibly elsewhere), both
<productname>Slony-I</productname> <emphasis>and
@@ -65,17 +68,18 @@
main parser, so no, you probably shouldn't put a "-" in your
identifier name.</para>
-<para> You may be able to defeat this by putting <quote/quotes/ around
+<para> You may be able to defeat this by putting <quote>quotes</quote> around
identifier names, but it's still liable to bite you some, so this is
something that is probably not worth working around.</para>
-
+</answer>
+</qandaentry>
<qandaentry>
-<question><para> <link linkend="slon"> <application/slon/ </link> does
+<question><para> <link linkend="slon"> <application>slon</application></link> does
not restart after crash</para>
<para> After an immediate stop of postgresql (simulation of system
crash) in pg_catalog.pg_listener a tuple with
-relname='_${cluster_name}_Restart' exists. slon doesn't start beccause
+relname='_${cluster_name}_Restart' exists. slon doesn't start because
it thinks another process is serving the cluster on this node. What
can I do? The tuples can't be dropped from this relation.</para>
@@ -83,14 +87,14 @@
serving this node already</para></blockquote></para></question>
<answer><para> The problem is that the system table
-<envar/pg_catalog.pg_listener/, used by <productname/PostgreSQL/ to
+<envar>pg_catalog.pg_listener</envar>, used by <productname>PostgreSQL</productname> to
manage event notifications, contains some entries that are pointing to
backends that no longer exist. The new <link linkend="slon">
-<application/slon/ </link> instance connects to the database, and is
+<application>slon</application></link> instance connects to the database, and is
convinced, by the presence of these entries, that an old
-<application/slon/ is still servicing this <productname/Slony-I/ node.
+<application>slon</application> is still servicing this <productname>Slony-I</productname> node.</para>
-<para> The <quote/trash/ in that table needs to be thrown away.
+<para> The <quote>trash</quote> in that table needs to be thrown away.</para>
<para>It's handy to keep a slonik script similar to the following to
run in such cases:
@@ -114,6 +118,7 @@
<para>As of version 1.0.5, the startup process of slon looks for this
condition, and automatically cleans it up.</para>
+</answer></qandaentry>
<qandaentry>
<question><para>ps finds passwords on command line</para>
@@ -124,6 +129,7 @@
<answer> <para>Take the passwords out of the Slony configuration, and
put them into
<filename><envar>$(HOME)</envar>/.pgpass.</filename></para>
+</answer></qandaentry>
<qandaentry>
<question><para>Slonik fails - cannot load
@@ -162,6 +168,7 @@
machine(s). Unfortunately, just about any mismatch will cause things
not to link up quite right. See also <link linkend="slonyfaq02">
SlonyFAQ02 </link> concerning threading issues on Solaris ...</para>
+</answer></qandaentry>
<qandaentry>
<question><para>Table indexes with FQ namespace names
@@ -176,7 +183,7 @@
<answer><para> If you have <command> key =
'nspace.key_on_whatever'</command> the request will
<emphasis>FAIL</emphasis>.</para>
-
+</answer></qandaentry>
<qandaentry>
<question><para> I'm trying to get a slave subscribed, and get the
following messages in the logs:
@@ -273,8 +280,7 @@
command SET DROP TABLE, which will "do the trick."</para></listitem>
<listitem><para> If you are still using 1.0.1 or 1.0.2, the
-<emphasis>essential functionality of <command> <link
-linkend="stmtsetdroptable"> SET DROP TABLE</link></command> involves
+<emphasis>essential functionality of <command><link linkend="stmtsetdroptable">SET DROP TABLE</link></command> involves
the functionality in <function>droptable_int()</function>. 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
@@ -300,6 +306,7 @@
the queries by hand.</para></listitem> </itemizedlist></para>
</answer>
</qandaentry>
+
<qandaentry>
<question><para>I need to drop a sequence from a replication set</para></question>
@@ -343,7 +350,8 @@
DROP TABLE </link> </command>, this is implemented
<productname>Slony-I</productname> version 1.0.5 as <command> <link
linkend="stmtsetdropsequence"> SET DROP
-SEQUENCE</link></command>.</para>
+SEQUENCE</link></command>.</para></answer></qandaentry>
+
<qandaentry>
<question><para><productname>Slony-I</productname>: cannot add table to currently subscribed set 1</para>
@@ -360,7 +368,7 @@
set, add the new tables to that new set, subscribe the same nodes
subscribing to "set 1" to the new set, and then merge the sets
together.</para>
-
+</answer></qandaentry>
<qandaentry>
<question><para>Some nodes start consistently falling behind</para>
@@ -395,9 +403,10 @@
time after the start time of the eldest transaction that is still
open. Long running transactions will cause trouble, and should be
avoided, even on "slave" nodes.</para>
+</answer></qandaentry>
<qandaentry>
-<question><para>I started doing a backup using <application/pg_dump/,
+<question><para>I started doing a backup using <application>pg_dump</application>,
and suddenly Slony stops</para></question>
<answer><para>Ouch. What happens here is a conflict between:
@@ -449,16 +458,16 @@
schema dumped using <option>--schema=whatever</option>, and don't try
dumping the cluster's schema.</para></listitem>
-<listitem><para> It would be nice to add an <option/--exclude-schema/
-option to pg_dump to exclude the Slony cluster schema. Maybe in 8.0
-or 8.1...</para></listitem>
+<listitem><para> It would be nice to add an <option>--exclude-schema</option>
+option to pg_dump to exclude the Slony cluster schema. Maybe in 8.1...</para></listitem>
<listitem><para>Note that 1.0.5 uses a more precise lock that is less
exclusive that alleviates this problem.</para></listitem>
</itemizedlist></para>
+</answer></qandaentry>
<qandaentry>
-<question><para>The <application/slon/s spent the weekend out of
+<question><para>The <application>slon</application> spent the weekend out of
commission [for some reason], and it's taking a long time to get a
sync through.</para></question>
@@ -480,8 +489,9 @@
<para><productname>Slony-I</productname> 1.1 provides a stored
procedure that allows <command>SYNC</command> counts to be updated on
the origin based on a <application>cron</application> job even if
-there is no <link linkend="slon"> <application/slon/ </link> daemon
+there is no <link linkend="slon"> <application>slon</application></link> daemon
running.</para>
+</answer></qandaentry>
<qandaentry>
<question><para>I pointed a subscribing node to a different provider
@@ -623,7 +633,7 @@
<itemizedlist>
<listitem><para> At the time a node is dropped</para></listitem>
-<listitem><para> At the start of each <function/cleanupEvent/ run,
+<listitem><para> At the start of each <function>cleanupEvent</function> run,
which is the event in which old data is purged from sl_log_1 and
sl_seqlog</para></listitem>
</itemizedlist></para>
@@ -634,7 +644,7 @@
<question><para>Replication Fails - Unique Constraint Violation</para>
<para>Replication has been running for a while, successfully, when a
-node encounters a <quote/glitch,/ and replication logs are filled with
+node encounters a <quote>glitch,</quote> and replication logs are filled with
repetitions of the following:
<screen>
@@ -673,7 +683,7 @@
<itemizedlist>
-<listitem><para> The <quote/glitch/ seems to coincide with some sort
+<listitem><para> The <quote>glitch</quote> seems to coincide with some sort
of outage; it has been observed both in cases where databases were
suffering from periodic "SIG 11" problems, where backends were falling
over, as well as when temporary network failure seemed
@@ -701,6 +711,7 @@
from the condition or at least diagnosing it more exactly. And
perhaps the problem is that sl_log_1 was being purged too
aggressively, and this will resolve the issue completely.</para>
+</answer></qandaentry>
<qandaentry>
@@ -763,11 +774,12 @@
<command>copy_set</command> logic does a <command>delete</command>,
not a <command>delete only</command>, so the delete of the parent will
delete the new rows in the child as well.
-
</para>
-</answer></qandaentry>
+</answer>
+</qandaentry>
</qandaset>
+
<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
Index: reshape.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/reshape.sgml,v
retrieving revision 1.5
retrieving revision 1.6
diff -Ldoc/adminguide/reshape.sgml -Ldoc/adminguide/reshape.sgml -u -w -r1.5 -r1.6
--- doc/adminguide/reshape.sgml
+++ doc/adminguide/reshape.sgml
@@ -1,15 +1,17 @@
-<sect1 id="reshape"> <title/Reshaping a Cluster/
+<!-- $Id -->
+<article>
+<sect1 id="reshape"> <title>Reshaping a Cluster</title>
<para>If you rearrange the nodes so that they serve different
-purposes, this will likely lead to the subscribers changing a bit.
+purposes, this will likely lead to the subscribers changing a bit.</para>
<para>This will require doing several things:
<itemizedlist>
<listitem><para> 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 <link linkend="slonik"> slonik </link> <command/MOVE SET/
-operation.
+suitable <link linkend="slonik"> slonik </link> <command>MOVE SET</command>
+operation.</para></listitem>
<listitem><para> You may subsequently, or instead, wish to modify the
subscriptions of other nodes. You might want to modify a node to get
@@ -38,13 +40,14 @@
</link></command>.</para></listitem>
</itemizedlist>
-
-<para> The <filename/altperl/ toolset includes a
-<application/init_cluster.pl/ script that is quite up to the task of
+</para>
+<para> The <filename>altperl</filename> toolset includes a
+<application>init_cluster.pl</application> script that is quite up to the task of
creating the new <command>STORE LISTEN</command> commands; it isn't,
however, smart enough to know what listener paths should be dropped.
+</para>
</sect1>
-
+</article>
<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
Index: startslons.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/startslons.sgml,v
retrieving revision 1.4
retrieving revision 1.5
diff -Ldoc/adminguide/startslons.sgml -Ldoc/adminguide/startslons.sgml -u -w -r1.4 -r1.5
--- doc/adminguide/startslons.sgml
+++ doc/adminguide/startslons.sgml
@@ -1,13 +1,15 @@
-<sect1 id="slonstart"> <title/Slon daemons/
+<!-- $Id -->
+<article>
+<sect1 id="slonstart"> <title>Slon daemons</title>
-<para>The programs that actually perform <productname/Slony-I/ replication are the
-<application/slon/ daemons.
+<para>The programs that actually perform <productname>Slony-I</productname> replication are the
+<application>slon</application> daemons.</para>
<para>You need to run one <application><link linkend="slon"> slon
</link></application> instance for each node in a
-<productname/Slony-I/ cluster, whether you consider that node a
-<quote/master/ or a <quote/slave./ Since a <command/MOVE SET/ or
-<command/FAILOVER/ can switch the roles of nodes, slon needs to be
+<productname>Slony-I</productname> cluster, whether you consider that node a
+<quote>master</quote> or a <quote>slave</quote>. Since a <command>MOVE SET</command> or
+<command>FAILOVER</command> 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:
@@ -38,6 +40,7 @@
restart <application>slon</application> instances.</para></listitem>
</itemizedlist>
+</para>
<para>There are two <quote>watchdog</quote> scripts currently available:
@@ -71,7 +74,7 @@
<command>COPY SET</command> in progress.</para>
</sect1>
-
+</article>
<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
Index: addthings.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/addthings.sgml,v
retrieving revision 1.4
retrieving revision 1.5
diff -Ldoc/adminguide/addthings.sgml -Ldoc/adminguide/addthings.sgml -u -w -r1.4 -r1.5
--- doc/adminguide/addthings.sgml
+++ doc/adminguide/addthings.sgml
@@ -1,9 +1,12 @@
-<sect1 id="addthings"> <title/ Adding Things to Replication/
+<!-- $Id -->
+<article>
+<sect1 id="addthings">
+<title>Adding Things to Replication</title>
<para>You may discover that you have missed replicating things that
-you wish you were replicating.
+you wish you were replicating.</para>
-<para>This can be fairly easily remedied.
+<para>This can be fairly easily remedied.</para>
<para>You cannot directly use <link linkend="slonik"> slonik </link>
commands <command><link linkend="stmtsetaddtable"> SET ADD
@@ -17,7 +20,7 @@
linkend="stmtmergeset"> MERGE SET</link></command>.</para>
<para>Up to and including 1.0.2, there was a potential problem where
-if <command><link linkend="stmtmergeset"> MERGE SET</linK></command>
+if <command><link linkend="stmtmergeset">MERGE SET</link></command>
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.</para>
@@ -36,8 +39,9 @@
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.
-
+the interaction of five things that have all broken.</para>
+</sect1>
+</article>
<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
Index: intro.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/intro.sgml,v
retrieving revision 1.3
retrieving revision 1.4
diff -Ldoc/adminguide/intro.sgml -Ldoc/adminguide/intro.sgml -u -w -r1.3 -r1.4
--- doc/adminguide/intro.sgml
+++ doc/adminguide/intro.sgml
@@ -1,17 +1,18 @@
+<!-- $Id -->
<article id="introduction">
- <title>Introduction to Slony-I</title>
+ <title>Introduction to <productname>Slony-I</productname></title>
<sect1>
<title>Why yet another replication system?</title>
- <para>Slony-I was born from an idea to create a replication system that was not tied
+ <para><productname>Slony-I</productname> 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.</para>
</sect1>
<sect1>
- <title>What Slony-I is</title>
- <para>Slony-I is a <quote>master to multiple slaves</quote> replication
+ <title>What <productname>Slony-I</productname> is</title>
+ <para><productname>Slony-I</productname> is a <quote>master to multiple slaves</quote> replication
system supporting cascading and slave promotion. The big picture for
-the development of Slony-I is as a master-slave system that includes
+the development of <productname>Slony-I</productname> 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. <quote>Reasonable,</quote> in this
context, is probably no more than a few dozen servers. If the number
@@ -21,11 +22,11 @@
<para> See also <link linkend="slonylistenercosts"> SlonyListenerCosts
</link> for a further analysis.</para>
- <para> Slony-I is a system intended for data centers and backup sites,
+ <para> <productname>Slony-I</productname> 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
+nodes that cannot be kept secure, <productname>Slony-I</productname> may not be the ideal
replication solution for you.</para>
<para> There are plans for a <quote>file-based log shipping</quote>
@@ -35,23 +36,23 @@
<quote>log shipping.</quote></para></sect1>
-<sect1><title> Slony-I is not</title>
+<sect1><title> <productname>Slony-I</productname> is not</title>
-<para>Slony-I is not a network management system.</para>
+<para><productname>Slony-I</productname> is not a network management system.</para>
-<para> Slony-I does not have any functionality within it to detect a
+<para> <productname>Slony-I</productname> does not have any functionality within it to detect a
node failure, or automatically promote a node to a master or other
data origin.</para>
-<para>Slony-I is not multi-master; it's not a connection broker, and
+<para><productname>Slony-I</productname> is not multi-master; it's not a connection broker, and
it doesn't make you coffee and toast in the morning.</para>
-<para>(That being said, the plan is for a subsequent system, Slony-II,
+<para>(That being said, the plan is for a subsequent system, <productname>Slony-I</productname>I,
to provide "multimaster" capabilities, and be "bootstrapped" using
-Slony-I. But that is a separate project, and expectations for Slony-I
+<productname>Slony-I</productname>. But that is a separate project, and expectations for <productname>Slony-I</productname>
should not be based on hopes for future projects.)</para></sect1>
-<sect1><title> Why doesn't Slony-I do automatic fail-over/promotion?
+<sect1><title> Why doesn't <productname>Slony-I</productname> do automatic fail-over/promotion?
</title>
<para>This is the job of network monitoring software, not Slony.
@@ -61,27 +62,27 @@
address and disconnecting the <quote>failed</quote> node vary in every
network setup, vendor choice, hardware/software combination. This is
clearly the realm of network management software and not
-Slony-I.</para>
+<productname>Slony-I</productname>.</para>
-<para>Let Slony-I do what it does best: provide database replication.</para></sect1>
+<para>Let <productname>Slony-I</productname> do what it does best: provide database replication.</para></sect1>
<sect1><title> Current Limitations</title>
-<para>Slony-I does not automatically propagate schema changes, nor
+<para><productname>Slony-I</productname> 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
+single common reason for these limitations, namely that <productname>Slony-I</productname>
operates using triggers, and neither schema changes nor large object
-operations can raise triggers suitable to tell Slony-I when those
+operations can raise triggers suitable to tell <productname>Slony-I</productname> when those
kinds of changes take place.</para>
-<para>There is a capability for Slony-I to propagate DDL changes if
+<para>There is a capability for <productname>Slony-I</productname> to propagate DDL changes if
you submit them as scripts via the <application>slonik</application>
<command>EXECUTE SCRIPT</command> operation. That is not
<quote>automatic;</quote> you have to construct an SQL DDL script and submit
it.</para>
<para>If you have those sorts of requirements, it may be worth
-exploring the use of <application>PostgreSQL</application> 8.0 PITR (Point In Time
+exploring the use of <application>PostgreSQL</application> 8.0 <acronym>PITR</acronym> (Point In Time
Recovery), where <acronym>WAL</acronym> logs are replicated to remote
nodes. Unfortunately, that has two attendant limitations:
@@ -103,7 +104,7 @@
it is impossible for one replication system to be all things to all
people.</para></sect1>
-<sect1 id="slonylistenercosts"><title> Slony-I Communications
+<sect1 id="slonylistenercosts"><title> <productname>Slony-I</productname> Communications
Costs</title>
<para>The cost of communications grows in a quadratic fashion in
Index: reference.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/reference.sgml,v
retrieving revision 1.3
retrieving revision 1.4
diff -Ldoc/adminguide/reference.sgml -Ldoc/adminguide/reference.sgml -u -w -r1.3 -r1.4
--- doc/adminguide/reference.sgml
+++ doc/adminguide/reference.sgml
@@ -1,5 +1,6 @@
-<chapter id="slony-commands">
- <title>Slony-I Commands</title>
+<!-- $Id -->
+<chapter>
+ <title><productname>Slony-I</productname> binaries</title>
&slon;
&slonik;
&slonikref;
Index: ddlchanges.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/ddlchanges.sgml,v
retrieving revision 1.4
retrieving revision 1.5
diff -Ldoc/adminguide/ddlchanges.sgml -Ldoc/adminguide/ddlchanges.sgml -u -w -r1.4 -r1.5
--- doc/adminguide/ddlchanges.sgml
+++ doc/adminguide/ddlchanges.sgml
@@ -1,4 +1,7 @@
-<sect1 id="ddlchanges"> <title/Database Schema Changes (DDL)/
+<!-- $Id -->
+<article>
+<sect1 id="ddlchanges">
+<title>Database Schema Changes (DDL)</title>
<para>When changes are made to the database schema,
<emphasis>e.g.</emphasis> - adding fields to a table, it is necessary
@@ -6,10 +9,9 @@
get rather deranged because they disagree on how particular tables are
built.</para>
-<para>If you pass the changes through
-<productname>Slony-I</productname> via the <command><link
-linkend="stmtddlscript"> EXECUTE SCRIPT</link> </command> (slonik) /
-<function>ddlscript(set,script,node)</function> (stored function),
+<para>If you pass the changes through <productname>Slony-I</productname>
+via the <command><link linkend="stmtddlscript">EXECUTE SCRIPT</link></command>
+ (slonik) /<function>ddlscript(set,script,node)</function> (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
@@ -17,9 +19,8 @@
transactions are still winding their way through your systems, this is
necessary.</para>
-<para>It's worth making a couple of comments on <quote/special things/
-about <command><link linkend="stmtddlscript"> EXECUTE SCRIPT</link>
-</command>:
+<para>It's worth making a couple of comments on <quote>special things</quote>
+about <command><link linkend="stmtddlscript">EXECUTE SCRIPT</link></command>:</para>
<itemizedlist>
@@ -33,8 +34,8 @@
<listitem><para> If there is <emphasis>anything</emphasis> broken
about the script, or about how it executes on a particular node, this
-will cause the <link linkend="slon"> <application>slon</application>
-</link> daemon for that node to panic and crash. If you restart the
+will cause the <link linkend="slon"><application>slon</application></link>
+ daemon for that node to panic and crash. If you restart the
node, it will, more likely than not, try to
<emphasis>repeat</emphasis> the DDL script, which will, almost
certainly, fail the second time just as it did the first time. I have
@@ -68,6 +69,7 @@
Varlena General Bits</ulink></para>
</sect1>
+</article>
<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
Index: failover.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/failover.sgml,v
retrieving revision 1.5
retrieving revision 1.6
diff -Ldoc/adminguide/failover.sgml -Ldoc/adminguide/failover.sgml -u -w -r1.5 -r1.6
--- doc/adminguide/failover.sgml
+++ doc/adminguide/failover.sgml
@@ -1,4 +1,7 @@
-<sect1 id="failover"> <title>Doing switchover and failover with Slony-I</title>
+<!-- $Id -->
+<article>
+<sect1 id="failover">
+<title>Doing switchover and failover with Slony-I</title>
<sect2><title>Foreword</title>
@@ -78,8 +81,9 @@
<para> 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.</para></sect2>
+be any loss of data.</para>
+</sect2>
<sect2><title> Failover</title>
<para> If some more serious problem occurs on the
@@ -100,15 +104,16 @@
commands below into a script executed automatically from the network
monitoring system, well ... it's <emphasis>your</emphasis> data, and
it's <emphasis>your</emphasis> failover policy.
+</para>
<itemizedlist>
-<listitem><para> The <link linkend="slonik">
-<application>slonik</application> </link> command
-
+<listitem>
+<para>The <link linkend="slonik"><application>slonik</application></link> command
<programlisting>
failover (id = 1, backup node = 2);
-</programlisting></para>
+</programlisting>
+</para>
<para> causes node2 to assume the ownership (origin) of all sets that
have node1 as their current origin. If there should happen to be
@@ -124,22 +129,28 @@
<para> 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.</para></listitem>
+will receive anything from node1 any more.</para>
+</listitem>
-<listitem><para> Reconfigure and restart the application (or
+<listitem>
+<para> Reconfigure and restart the application (or
<application>pgpool</application>) to cause it to reconnect to
-node2.</para></listitem>
+node2.</para>
+</listitem>
-<listitem><para> After the failover is complete and node2 accepts
+<listitem>
+<para> After the failover is complete and node2 accepts
write operations against the tables, remove all remnants of node1's
-configuration information with the <link linkend="slonik">
-<application>slonik</application> </link> <command> <link
-linkend="stmtdropnode"> DROP NODE </link> </command> command:
+configuration information with the <link linkend="slonik"><application>slonik</application></link>
+<command><link linkend="stmtdropnode">DROP NODE</link></command> command:
<programlisting>
drop node (id = 1, event node = 2);
-</programlisting></para></listitem>
-</itemizedlist></para></sect2>
+</programlisting>
+</para>
+</listitem>
+</itemizedlist>
+</sect2>
<sect2><title>After Failover, Reconfiguring node1</title>
@@ -153,10 +164,11 @@
<para> If the database is very large, it may take many hours to
recover node1 as a functioning <productname>Slony-I</productname> node; that is
another reason to consider failover as an undesirable <quote>final
-resort.</quote></para></sect2>
+resort.</quote></para>
+</sect2>
</sect1>
-
+</article>
<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
Index: monitoring.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/monitoring.sgml,v
retrieving revision 1.4
retrieving revision 1.5
diff -Ldoc/adminguide/monitoring.sgml -Ldoc/adminguide/monitoring.sgml -u -w -r1.4 -r1.5
--- doc/adminguide/monitoring.sgml
+++ doc/adminguide/monitoring.sgml
@@ -1,12 +1,15 @@
-<sect1 id="monitoring"> <title/Monitoring/
+<!-- $Id -->
+<article>
+<sect1 id="monitoring">
+<title>Monitoring</title>
<para>Here are some of things that you may find in your
-<productname/Slony-I/ logs, and explanations of what they mean.
-
-<sect2><title/CONFIG notices/
+<productname>Slony-I</productname> logs, and explanations of what they mean.
+</para>
+<sect2><title>CONFIG notices</title>
<para>These entries are pretty straightforward. They are informative
-messages about your configuration.
+messages about your configuration.</para>
<para>Here are some typical entries that you will probably run into in
your logs:
@@ -20,7 +23,8 @@
CONFIG storeSet: set_id=1 set_origin=1 set_comment='Set 1'
CONFIG main: configuration complete - starting threads
</screen>
-
+</para>
+</sect2>
<sect2><title>DEBUG Notices</title>
<para>Debug notices are always prefaced by the name of the thread that
@@ -34,14 +38,15 @@
cleanupThread: Takes care of things like vacuuming, cleaning out the confirm and event tables, and deleting logs.
syncThread: Generates sync events.
</screen>
-
+</para>
<para> 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...
-
+</para>
+</sect2>
</sect1>
-
+</article>
<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
Index: installation.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/installation.sgml,v
retrieving revision 1.5
retrieving revision 1.6
diff -Ldoc/adminguide/installation.sgml -Ldoc/adminguide/installation.sgml -u -w -r1.5 -r1.6
--- doc/adminguide/installation.sgml
+++ doc/adminguide/installation.sgml
@@ -1,8 +1,9 @@
+<!-- $Id -->
<article id="installation">
<title>Slony-I Installation</title>
<sect1>
<title>Slony-I Installation</title>
-<para>You should have obtained the <productname/Slony-I/ source from
+<para>You should have obtained the <productname>Slony-I</productname> source from
the previous step. Unpack it.</para>
<screen>
@@ -11,9 +12,10 @@
</screen>
<para> This will create a directory under the current directory with
-the <productname/Slony-I/ sources. Head into that that directory for the rest of
+the <productname>Slony-I</productname> sources. Head into that that directory for the rest of
the installation procedure.</para>
</sect1>
+
<sect1>
<title>Short Version</title>
@@ -22,17 +24,19 @@
./configure --with-pgsourcetree=/whereever/the/source/is
gmake all; gmake install
</screen>
+</para>
+
</sect1>
<sect1>
<title>Configuration</title>
<para>The first step of the installation procedure is to configure the
source tree for your system. This is done by running the
-<application/configure/ script. In early versions,
-<application/Configure/ needed to know where your
-<productname/PostgreSQL/ source tree is, is done with the
-<option/--with-pgsourcetree=/ option. As of version 1.1,
-<productname/Slony-I/ is configured by pointing it to the various
+<application>configure</application> script. In early versions,
+<application>configure</application> needed to know where your
+<productname>PostgreSQL</productname> source tree is, is done with the
+<option>--with-pgsourcetree=</option> option. As of version 1.1,
+<productname>Slony-I</productname> is configured by pointing it to the various
library, binary, and include directories; for a full list of these
options, use the command <command> ./configure --help </command>
</para>
@@ -47,7 +51,7 @@
<para>This script will run a number of tests to guess values for
various dependent variables and try to detect some quirks of your
-system. Slony-I is known to need a modified version of libpq on
+system. <productname>Slony-I</productname> is known to need a modified version of libpq on
specific platforms such as Solaris2.X on SPARC this patch can be found
at <ulink
url="http://developer.postgresql.org/~wieck/slony1/download/threadsafe-libpq-742.diff.gz">
@@ -65,8 +69,8 @@
</screen></para>
<para> Be sure to use GNU make; on BSD systems, it is called
-<application/gmake/; on Linux, GNU make is typically the native
-<application/make/, so the name of the command you type in may vary
+<application>gmake</application>; on Linux, GNU make is typically the native
+<application>make</application>, so the name of the command you type in may vary
somewhat. The build may take anywhere from a few seconds to 2 minutes
depending on how fast your hardware is at compiling things. The last
line displayed should be</para>
Index: slonik.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slonik.sgml,v
retrieving revision 1.4
retrieving revision 1.5
diff -Ldoc/adminguide/slonik.sgml -Ldoc/adminguide/slonik.sgml -u -w -r1.4 -r1.5
--- doc/adminguide/slonik.sgml
+++ doc/adminguide/slonik.sgml
@@ -1,3 +1,4 @@
+<!-- $Id -->
<refentry id="app-slonik">
<refmeta>
<refentrytitle id="app-slonik-title"><application>slonik</application></refentrytitle>
@@ -19,7 +20,7 @@
<refsynopsisdiv>
<cmdsynopsis>
<command>slonik</command>
- <arg><replaceable class="parameter">filename</replaceable>
+ <arg><replaceable class="parameter">filename</replaceable></arg>
</cmdsynopsis>
</refsynopsisdiv>
@@ -45,16 +46,16 @@
script.</para>
<para>Nearly all of the real configuration work is actually done by
- calling stored procedures after loading the <productname/Slony-I/
- support base into a database. <application/Slonik/ was created
+ calling stored procedures after loading the <productname>Slony-I</productname>
+ support base into a database. <application>slonik</application> 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 <application/psql/ prompt, and
- <application/psql/ lacks the ability to maintain multiple
+ rather hard to do this from the <application>psql</application> prompt, and
+ <application>psql</application> lacks the ability to maintain multiple
connections with open transactions to multiple databases.</para>
- <para>The format of the Slonik <quote/language/ is very similar to
+ <para>The format of the Slonik <quote>language</quote> 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
Index: dropthings.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/dropthings.sgml,v
retrieving revision 1.5
retrieving revision 1.6
diff -Ldoc/adminguide/dropthings.sgml -Ldoc/adminguide/dropthings.sgml -u -w -r1.5 -r1.6
--- doc/adminguide/dropthings.sgml
+++ doc/adminguide/dropthings.sgml
@@ -1,36 +1,38 @@
-<sect1 id="dropthings"> <title/ Dropping things from Slony Replication/
+<!-- $Id -->
+<article>
+<sect1 id="dropthings"> <title>Dropping things from Slony Replication</title>
<para>There are several things you might want to do involving dropping
-things from <productname/Slony-I/ replication.
+things from <productname>Slony-I</productname> replication.</para>
-<sect2><title/ Dropping A Whole Node/
+<sect2><title>Dropping A Whole Node</title>
<para>If you wish to drop an entire node from replication, the <link
linkend="slonik"> slonik </link> command <command><link
linkend="stmtdropnode"> DROP NODE</link></command> should do the
trick.</para>
-<para>This will lead to <productname/Slony-I/ dropping the triggers
+<para>This will lead to <productname>Slony-I</productname> dropping the triggers
(generally that deny the ability to update data), restoring the
-<quote/native/ triggers, dropping the schema used by
-<productname/Slony-I/, and the slon process for that node terminating
-itself.
+<quote>>native</quote> triggers, dropping the schema used by
+<productname>Slony-I</productname>, and the slon process for that node terminating
+itself.</para>
<para>As a result, the database should be available for whatever use
-your application makes of the database.
+your application makes of the database.</para>
<para>This is a pretty major operation, with considerable potential to
-cause substantial destruction; make sure you drop the right node!
+cause substantial destruction; make sure you drop the right node!</para>
<para>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.
+protect you from errors.</para>
<para><link linkend="FAQ17"> sl_log_1 isn't getting purged </link>
documents some extra maintenance that may need to be done on
-sl_confirm if you are running versions prior to 1.0.5.
+sl_confirm if you are running versions prior to 1.0.5.</para>
-<sect2><title/ Dropping An Entire Set/
+<sect2><title>Dropping An Entire Set</title>
<para>If you wish to stop replicating a particular replication set,
the <link linkend="slonik"> slonik </link> command <command> <link
@@ -53,19 +55,18 @@
SET</link></command> to drop the <emphasis>wrong</emphasis> set, there
isn't anything to prevent potentially career-limiting
<quote>unfortunate results.</quote> Handle with care...</para>
-
-<sect2><title/ Unsubscribing One Node From One Set/
+</sect2>
+<sect2><title>Unsubscribing One Node From One Set</title>
<para>The <command> <link linkend="stmtunsubscribeset"> UNSUBSCRIBE
SET </link> </command> operation is a little less invasive than either
<command> <link linkend="stmtdropset"> DROP SET </link> </command> or
<command> <link linkend="stmtdropnode"> DROP NODE </link></command>; it involves dropping
<productname>Slony-I</productname> triggers and restoring
-<quote/native/ triggers on one node, for one replication set.</para>
+<quote>native</quote> triggers on one node, for one replication set.</para>
-<para>Much like with <command> <link linkend="stmtdropnode"> DROP NODE
-</link></command>, this operation will fail if there is a node
-subscribing to the set on this node.
+<para>Much like with <command><link linkend="stmtdropnode">DROP NODE</link></command>,
+this operation will fail if there is a node subscribing to the set on this node.
<warning>
<para>For all of the above operations, <quote>turning replication back
@@ -73,8 +74,11 @@
<emphasis>full</emphasis> fresh set of the data on a provider. The
fact that the data was recently being replicated isn't good enough;
<productname>Slony-I</productname> will expect to refresh the data
-from scratch.</para> </warning></para>
+from scratch.</para>
+</warning>
+</para>
+</sect2>
<sect2><title> Dropping A Table From A Set</title>
<para>In <productname>Slony-I</productname> 1.0.5 and above, there is
@@ -89,12 +93,12 @@
<para>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:
-
<programlisting>
select _slonyschema.alterTableRestore(40);
select _slonyschema.tableDropKey(40);
delete from _slonyschema.sl_table where tab_id = 40;
-</programlisting></para>
+</programlisting>
+</para>
<para>The schema will obviously depend on how you defined the
<productname>Slony-I</productname> cluster. The table ID, in this
@@ -103,16 +107,16 @@
<para>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 <link linkend="slonik">
-slonik </link> statement with a new <productname>Slony-I</productname>
+propagates properly. Implementing this via a <link linkend="slonik">slonik</link>
+statement with a new <productname>Slony-I</productname>
event would do that. Submitting the three queries using
-<command><link linkend="stmtddlscript"> EXECUTE SCRIPT </link>
-</command> could do that; see <link linkend="ddlchanges"> Database
-Schema Changes </link> for more details. Also possible would be to
-connect to each database and submit the queries by
-hand.</para></sect2>
+<command><link linkend="stmtddlscript">EXECUTE SCRIPT</link></command> could do that;
+see <link linkend="ddlchanges">Database Schema Changes</link> for more details.
+Also possible would be to connect to each database and submit the queries by
+hand.</para>
+</sect2>
-<sect2><title/ Dropping A Sequence From A Set/
+<sect2><title>Dropping A Sequence From A Set</title>
<para>Just as with <command> <link linkend="stmtsetdroptable"> SET
DROP TABLE </link> </command>, version 1.0.5 introduces the operation
@@ -120,9 +124,9 @@
SEQUENCE</link> </command>.</para>
<para>If you are running an earlier version, here are instructions as
-to how to drop sequences:
+to how to drop sequences:</para>
-<para>The data that needs to be deleted to stop <productname/Slony-I/
+<para>The data that needs to be deleted to stop <productname>Slony-I</productname>
from continuing to replicate the two sequences identified with
Sequence IDs 93 and 59 are thus:
@@ -130,14 +134,16 @@
delete from _oxrsorg.sl_seqlog where seql_seqid in (93, 59);
delete from _oxrsorg.sl_sequence where seq_id in (93,59);
</programlisting>
+</para>
<para> Those two queries could be submitted to all of the nodes via
<function>ddlscript()</function> / <command> <link
linkend="stmtddlscript"> EXECUTE SCRIPT</link> </command>, thus
eliminating the sequence everywhere <quote>at once.</quote> Or they
may be applied by hand to each of the nodes.</para>
+</sect2>
</sect1>
-
+</article>
<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
Index: listenpaths.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/listenpaths.sgml,v
retrieving revision 1.6
retrieving revision 1.7
diff -Ldoc/adminguide/listenpaths.sgml -Ldoc/adminguide/listenpaths.sgml -u -w -r1.6 -r1.7
--- doc/adminguide/listenpaths.sgml
+++ doc/adminguide/listenpaths.sgml
@@ -1,18 +1,18 @@
-<sect1 id="listenpaths"> <title/ Slony-I Listen Paths/
-
+<!-- $Id -->
+<article>
+<sect1 id="listenpaths"><title><productname>Slony-I</productname> listen paths</title>
<note> <para> If you are running version
-<productname>Slony-I</productname> 1.1, it should be
+<productname>Slony-I</productname> 1.1 or later it should be
<emphasis>completely unnecessary</emphasis> to read this section as it
introduces a way to automatically manage this part of its
-configuration. For earlier versions, however, it is needful...</para>
+configuration. For earlier versions, however, it is needful.</para>
</note>
<para>If you have more than two or three nodes, and any degree of
usage of cascaded subscribers (<emphasis>e.g.</emphasis> - subscribers
that are subscribing through a subscriber node), you will have to be
fairly careful about the configuration of <quote>listen paths</quote>
-via the Slonik <command> <link
-linkend="stmtstorelisten"> STORE LISTEN </link> </command> and
+via the Slonik <command> <link linkend="stmtstorelisten">STORE LISTEN</link></command> and
<link linkend="stmtdroplisten"> <command>DROP LISTEN</command> </link>
statements that control the contents of the table sl_listen.</para>
@@ -22,49 +22,49 @@
<quote>parent</quote> from whom they are getting updates, but in
reality, they need to be able to receive messages from
<emphasis>all</emphasis> nodes in order to be able to conclude that
-<command/SYNC/s have been received everywhere, and that, therefore,
+<command>sync</command>s 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
+therefore be purged. this extra communication is needful so
<productname>Slony-I</productname> is able to shift origins to other
locations.</para>
-<sect2><title/ How Listening Can Break/
+<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
(#3) that was, in effect, a <quote>cascaded slave.</quote> Dropping
-the subscriber node initially didn't work, as <link linkend="slonik">
-<command>slonik</command> </link> informed me that there was a
+the subscriber node initially didn't work, as
+<link linkend="slonik"><command>slonik</command></link> informed me that there was a
dependant node. I repointed the dependant node to the
<quote>master</quote> node for the subscription set, which, for a
while, replicated without difficulties.</para>
-<para>I then dropped the subscription on <quote/node 2,/ and started
-resubscribing it. That raised the <productname/Slony-I/
-<command/SET_SUBSCRIPTION/ event, which started copying tables. At
-that point in time, events stopped propagating to <quote/node 3,/ and
-while it was in perfectly OK shape, no events were making it to it.
+<para>I then dropped the subscription on <quote>node 2</quote>, and started
+resubscribing it. that raised the <productname>Slony-I</productname>
+<command>set_subscription</command> event, which started copying tables. at
+that point in time, events stopped propagating to <quote>node 3</quote>, and
+while it was in perfectly ok shape, no events were making it to it.</para>
<para>The problem was that node #3 was expecting to receive events
-from node #2, which was busy processing the <command/SET_SUBSCRIPTION/
-event, and was not passing anything else on.
+from node #2, which was busy processing the <command>set_subscription</command>
+event, and was not passing anything else on.</para>
<para>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, <quote/as if by magic,/ node #3 started replicating again, as
-it discovered a place to get <command/SYNC/ events.
-
-<sect2><title/How The Listen Configuration Should Look/
+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>
<para>The simple cases tend to be simple to cope with. We need to
-instead look at a more complex node configuration.
+instead look at a more complex node configuration.</para>
<para>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.
+2, and 6 subscribes to 5.</para>
-<para>Here is a <quote/listener network/ that indicates where each
+<para>Here is a <quote>listener network</quote> that indicates where each
node should listen for messages coming from each other node:
<screen>
@@ -77,16 +77,16 @@
5 2 2 2 2 0 6
6 5 5 5 5 5 0
</screen>
-
+</para>
<para>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.
+and 6 from node 5.</para>
<para>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.
+listens to node 5 to get events from nodes 1-5.</para>
-<para>The set of slonik <command/SET LISTEN/ statements to express
-this <quote/listener network/ are as follows:
+<para>The set of slonik <command>set listen</command> statements to express
+this <quote>listener network</quote> are as follows:
<programlisting>
store listen (origin = 1, receiver = 2, provider = 1);
@@ -120,46 +120,46 @@
store listen (origin = 6, receiver = 4, provider = 1);
store listen (origin = 6, receiver = 5, provider = 6);
</programlisting>
+</para>
+<para>How we read these listen statements is thus...</para>
-<para>How we read these listen statements is thus...
-
-<para>When on the <quote/receiver/ node, look to the <quote/provider/
-node to provide events coming from the <quote/origin/ node.
+<para>When on the <quote>receiver</quote> node, look to the <quote>provider</quote>
+node to provide events coming from the <quote>origin</quote> node.</para>
-<para>The tool <filename/init_cluster.pl/ in the <filename/altperl/
+<para>The tool <filename>init_cluster.pl</filename> in the <filename>altperl</filename>
scripts produces optimized listener networks in both the tabular form
shown above as well as in the form of <link linkend="Slonik">
-<application/slonik/ </link> statements.
+<application>slonik</application></link> statements.</para>
-<para>There are three <quote/thorns/ in this set of roses:
+<para>There are three <quote>thorns</quote> in this set of roses:
<itemizedlist>
<listitem><para> 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 <productname/Slony-I/, there is no automated way
-at this point to do this <quote/reshaping./
+between nodes. Until <productname>Slony-I</productname>, there is no automated way
+at this point to do this <quote>reshaping</quote>.</para></listitem>
-<listitem><para> If you <emphasis/don't/ change the sl_listen entries,
+<listitem><para> If you <emphasis>don't</emphasis> 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, <quote/orphaning/ any nodes that are listening through it.
+continue to run well. the problem will only be noticed when a node is
+taken down, <quote>orphaning</quote> any nodes that are listening through it.</para></listitem>
-<listitem><para> You might have multiple replication sets that have
-<emphasis/different/ shapes for their respective trees of subscribers.
-There won't be a single <quote/best/ listener configuration in that
-case.
+<listitem><para> you might have multiple replication sets that have
+<emphasis>different</emphasis> shapes for their respective trees of subscribers.
+there won't be a single <quote>best</quote> listener configuration in that
+case.</para></listitem>
<listitem><para> In order for there to be an sl_listen path, there
-<emphasis/must/ 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 <quote/connected/ network of nodes, then some nodes will not
-be reachable. This would typically happen, in practice, when you have
+<emphasis>must</emphasis> 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 <quote>connected</quote> 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 <quote/firewall/ nodes that can talk
-between the subnets. Cut out those nodes and the subnets stop
-communicating.
+where there are only a couple of <quote>firewall</quote> nodes that can talk
+between the subnets. cut out those nodes and the subnets stop
+communicating.</para></listitem>
</itemizedlist>
@@ -196,14 +196,13 @@
<para> If you are running an earlier version of
<productname>Slony-I</productname>, you may want to take a look at
-<link linkend="regenlisten">
-<application>regenerate-listens.pl</application> </link>, a Perl
+<link linkend="regenlisten"><application>regenerate-listens.pl</application></link>, a Perl
script which duplicates the functionality of the stored procedure in
-the form of a script that generates the <link linkend="slonik"> Slonik
+the form of a script that generates the <link linkend="slonik"><command>slonik</command>
</link> requests to generate the listener paths.</para></sect2>
</sect1>
-
+</article>
<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
Index: slony.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slony.sgml,v
retrieving revision 1.6
retrieving revision 1.7
diff -Ldoc/adminguide/slony.sgml -Ldoc/adminguide/slony.sgml -u -w -r1.6 -r1.7
--- doc/adminguide/slony.sgml
+++ doc/adminguide/slony.sgml
@@ -9,7 +9,7 @@
]>
<book id="slony">
- <title>Slony-I &version; Documentation</title>
+ <title><productname>Slony-I</productname> &version; Documentation</title>
<bookinfo>
<corpauthor>The Slony Global Development Group</corpauthor>
<author>
@@ -20,8 +20,7 @@
</bookinfo>
<part id="slonyintro">
- <title>Slony-I Introduction</title>
-
+ <title><productname>Slony-I</productname> Introduction</title>
&intro;
&prerequisites;
&installation;
@@ -30,13 +29,13 @@
&defineset;
</part>
- <part id="refrence">
- <title>Slony-I Command Reference</title>
+ <part id="commandreferencec">
+ <title>Core <productname>Slony-I</productname> Programs</title>
&reference;
</part>
<part id="slonyadmin">
- <title>Slony-I Administration</title>
+ <title><productname>Slony-I</productname> Administration</title>
&adminscripts;
&startslons;
@@ -70,9 +69,7 @@
&schemadoc;
</article>
</part>
-<!-- &errcodes; -->
-<!-- &biblio; -->
-<!-- &bookindex; -->
+&bookindex;
</book>
- Previous message: [Slony1-commit] By darcyb: Carry the docbook stuff through to the frontend
- Next message: [Slony1-commit] By cbbrowne: Added commentary on what happens to triggers and rules
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-commit mailing list