Tue Jan 17 08:16:10 PST 2006
- Previous message: [Slony1-commit] By cbbrowne: Numerous updates to documentation based on Brian A.
- Next message: [Slony1-commit] By cbbrowne: slon SUBSCRIBE_SET event now requests an exclusive lock on
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Log Message:
-----------
Draw into CVS HEAD the documention work that has been taking place in
the -STABLE branch.
Modified Files:
--------------
slony1-engine/doc/adminguide:
addthings.sgml (r1.11 -> r1.12)
adminscripts.sgml (r1.29 -> r1.30)
bestpractices.sgml (r1.13 -> r1.14)
cluster.sgml (r1.10 -> r1.11)
concepts.sgml (r1.17 -> r1.18)
ddlchanges.sgml (r1.19 -> r1.20)
defineset.sgml (r1.20 -> r1.21)
failover.sgml (r1.19 -> r1.20)
faq.sgml (r1.50 -> r1.51)
filelist.sgml (r1.15 -> r1.16)
firstdb.sgml (r1.17 -> r1.18)
installation.sgml (r1.19 -> r1.20)
intro.sgml (r1.20 -> r1.21)
legal.sgml (r1.9 -> r1.10)
listenpaths.sgml (r1.16 -> r1.17)
locking.sgml (r1.5 -> r1.6)
logshipping.sgml (r1.12 -> r1.13)
man.sgml (r1.4 -> r1.5)
monitoring.sgml (r1.21 -> r1.22)
plainpaths.sgml (r1.10 -> r1.11)
prerequisites.sgml (r1.24 -> r1.25)
reshape.sgml (r1.16 -> r1.17)
slon.sgml (r1.23 -> r1.24)
slonik.sgml (r1.15 -> r1.16)
slonik_ref.sgml (r1.38 -> r1.39)
slony.sgml (r1.26 -> r1.27)
startslons.sgml (r1.14 -> r1.15)
subscribenodes.sgml (r1.14 -> r1.15)
testbed.sgml (r1.5 -> r1.6)
usingslonik.sgml (r1.14 -> r1.15)
versionupgrade.sgml (r1.7 -> r1.8)
-------------- next part --------------
Index: slon.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slon.sgml,v
retrieving revision 1.23
retrieving revision 1.24
diff -Ldoc/adminguide/slon.sgml -Ldoc/adminguide/slon.sgml -u -w -r1.23 -r1.24
--- doc/adminguide/slon.sgml
+++ doc/adminguide/slon.sgml
@@ -298,7 +298,7 @@
<para>
<envar>archive_dir</envar> indicates a directory in which to
place a sequence of <command>SYNC</command> archive files for
- use in &logship; mode.
+ use in &logshiplink; mode.
</para>
</listitem>
</varlistentry>
Index: slonik_ref.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slonik_ref.sgml,v
retrieving revision 1.38
retrieving revision 1.39
diff -Ldoc/adminguide/slonik_ref.sgml -Ldoc/adminguide/slonik_ref.sgml -u -w -r1.38 -r1.39
--- doc/adminguide/slonik_ref.sgml
+++ doc/adminguide/slonik_ref.sgml
@@ -983,6 +983,19 @@
we can't see there being terribly much interest in replicating
tables that contain no application data.</para> </note>
+ <caution><para> <command>TABLE ADD KEY</command> <emphasis>should
+ not be used</emphasis> if you can possibly avoid it. It is
+ emphatically <emphasis>not</emphasis> a &bestpracticelink;. </para>
+
+ <para> The absence of a proper primary key should be a big red
+ flag that the database schema is <emphasis>broken.</emphasis> The
+ <emphasis>right</emphasis> way to repair this is to introduce a
+ proper primary key, not to have &slony1; <quote>fake</quote> one
+ up.</para>
+
+ <para>It is <emphasis>not</emphasis> supported in &logshiplink;,
+ and will not be.</para> </caution>
+
<para> This uses &funtableaddkey;. </para>
</refsect1>
<refsect1><title>Example</title>
Index: cluster.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/cluster.sgml,v
retrieving revision 1.10
retrieving revision 1.11
diff -Ldoc/adminguide/cluster.sgml -Ldoc/adminguide/cluster.sgml -u -w -r1.10 -r1.11
--- doc/adminguide/cluster.sgml
+++ doc/adminguide/cluster.sgml
@@ -8,7 +8,16 @@
<para>A &slony1; cluster is the basic grouping of database instances
in which replication takes place. It consists of a set of &postgres;
database instances in which is defined a namespace specific to that
-cluster.</para>
+cluster. For instance, if the cluster is called
+<envar>cbcluster</envar>, then &slony1; will define, at the
+initialization time for each node, a schema called
+<command>_cbcluster</command>, in which it then creates numerous
+tables that store &slony1; configuration and replication state
+information. See <xref linkend="schema"> for more documentation about
+what is stored in that schema. More specifically, the tables <xref
+linkend="table.sl-log-1"> and <xref linkend="table.sl-log-2"> log
+changes collected on the origin node as they are replicated to
+subscribers. </para>
<para>Each database instance in which replication is to take place is
identified by a node number.</para>
@@ -22,10 +31,12 @@
correspond to the shape of the environment, as opposed to (say) the
order in which nodes were initialized.</para>
-<para>It may be that in version 1.1, nodes will also have a
-<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.</para>
+<para> In &slony1; version 1.1, the <xref linkend="stmtinclude"> and
+<xref linkend="stmtdefine"> statements allow you to create a sort of
+<quote>symbol table</quote> behind the scenes so that <xref
+linkend="slonik"> scripts can use names for nodes rather than cryptic
+numbers. </para>
+
</sect1>
<!-- Keep this comment at the end of the file
Index: bestpractices.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/bestpractices.sgml,v
retrieving revision 1.13
retrieving revision 1.14
diff -Ldoc/adminguide/bestpractices.sgml -Ldoc/adminguide/bestpractices.sgml -u -w -r1.13 -r1.14
--- doc/adminguide/bestpractices.sgml
+++ doc/adminguide/bestpractices.sgml
@@ -145,10 +145,11 @@
<emphasis>acceptable</emphasis> to use a <quote>candidate primary key.</quote></para>
<para> It is <emphasis>not recommended</emphasis> that a
-&slony1;-defined key be used to introduce a candidate primary key, as
-this introduces the possibility that updates to this table can fail
-due to the introduced unique index, which means that &slony1; has
-introduced a new failure mode for your application.</para>
+&slony1;-defined key (created via <xref linkend="stmttableaddkey">) be
+used to introduce a candidate primary key, as this introduces the
+possibility that updates to this table can fail due to the introduced
+unique index, which means that &slony1; has introduced a new failure
+mode for your application.</para>
</listitem>
<listitem>
@@ -249,9 +250,9 @@
lot of them, they may be a nuisance to read.)</para>
<para> Unfortunately, if you invoke <xref linkend="slon"> from the
-command line, you could <emphasis>forget</emphasis> to include <link
-linkend="logshipping"> log shipping </link> configuration and thereby
-destroy the sequence of logs for a log shipping node. </para>
+command line, you could <emphasis>forget</emphasis> to include
+&logshiplink; configuration and thereby destroy the sequence of logs
+for a log shipping node. </para>
</listitem>
<listitem> <para> Unlike when command line options are used, the
@@ -261,8 +262,7 @@
configuration file. </para>
<para> By putting the options in a file, you won't forget including
-any of them, so this is safer for <link linkend="logshipping"> log
-shipping. </link> </para>
+any of them, so this is safer for &logshiplink;. </para>
</listitem>
</itemizedlist>
Index: filelist.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/filelist.sgml,v
retrieving revision 1.15
retrieving revision 1.16
diff -Ldoc/adminguide/filelist.sgml -Ldoc/adminguide/filelist.sgml -u -w -r1.15 -r1.16
--- doc/adminguide/filelist.sgml
+++ doc/adminguide/filelist.sgml
@@ -36,7 +36,7 @@
<!entity notation SYSTEM "notation.sgml">
<!entity problems SYSTEM "problems.sgml">
<!entity slonybook SYSTEM "slony.sgml">
-<!entity logshipping SYSTEM "logshipping.sgml">
+<!entity logshipfile SYSTEM "logshipping.sgml">
<!entity bestpractices SYSTEM "bestpractices.sgml">
<!entity locking SYSTEM "locking.sgml">
<!entity supportedplatforms SYSTEM "supportedplatforms.sgml">
Index: man.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/man.sgml,v
retrieving revision 1.4
retrieving revision 1.5
diff -Ldoc/adminguide/man.sgml -Ldoc/adminguide/man.sgml -u -w -r1.4 -r1.5
--- doc/adminguide/man.sgml
+++ doc/adminguide/man.sgml
@@ -9,7 +9,7 @@
<!ENTITY slony1 "<PRODUCTNAME>Slony-I</PRODUCTNAME>">
<!ENTITY postgres "<PRODUCTNAME>PostgreSQL</PRODUCTNAME>">
<!ENTITY windows "<trademark>Windows</trademark>">
- <!ENTITY logship "log shipping">
+ <!ENTITY logshiplink "log shipping">
<!ENTITY rlocking " locking ">
<!ENTITY rddlchanges "distribution documentation on DDL changes">
<!ENTITY rplainpaths "distribution documentation on plain paths">
@@ -43,6 +43,7 @@
<!ENTITY funsubscribeset "<function>subscribeset(integer,integer,integer,boolean)</function>">
<!ENTITY slnode "<envar>sl_node</envar>">
<!ENTITY slconfirm "<envar>sl_confirm</envar>">
+ <!ENTITY bestpracticelink "Best Practice">
]>
<book id="slony">
Index: prerequisites.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/prerequisites.sgml,v
retrieving revision 1.24
retrieving revision 1.25
diff -Ldoc/adminguide/prerequisites.sgml -Ldoc/adminguide/prerequisites.sgml -u -w -r1.24 -r1.25
--- doc/adminguide/prerequisites.sgml
+++ doc/adminguide/prerequisites.sgml
@@ -230,16 +230,15 @@
cluster as a whole.</para>
<para>New in &slony1; version 1.1 is a feature whereby updates for a
-particular replication set may be serialized via a scheme called <link
-linkend="logshipping">log shipping. </link> The data stored in
-<envar>sl_log_1</envar> and <envar>sl_log_2</envar> is also written
-out to log files on disk. These files may then be transmitted in any
-manner desired, whether via scp, FTP, burning them onto DVD-ROMs and
-mailing them, or, at the frivolous end of the spectrum, by recording
-them on a USB <quote>flash device</quote> and attaching them to birds,
-allowing some equivalent to <ulink
-url="http://www.faqs.org/rfcs/rfc1149.html"> transmission of IP
-datagrams on avian carriers - RFC 1149.</ulink> But whatever the
+particular replication set may be serialized via a scheme called
+&logshiplink;. The data stored in <envar>sl_log_1</envar> and
+<envar>sl_log_2</envar> is also written out to log files on disk.
+These files may then be transmitted in any manner desired, whether via
+scp, FTP, burning them onto DVD-ROMs and mailing them, or, at the
+frivolous end of the spectrum, by recording them on a USB <quote>flash
+device</quote> and attaching them to birds, allowing some equivalent
+to <ulink url="http://www.faqs.org/rfcs/rfc1149.html"> transmission of
+IP datagrams on avian carriers - RFC 1149.</ulink> But whatever the
transmission mechanism, this allows one way communications such that
subscribers that use log shipping have no need of access to other
&slony1; nodes.</para>
Index: faq.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/faq.sgml,v
retrieving revision 1.50
retrieving revision 1.51
diff -Ldoc/adminguide/faq.sgml -Ldoc/adminguide/faq.sgml -u -w -r1.50 -r1.51
--- doc/adminguide/faq.sgml
+++ doc/adminguide/faq.sgml
@@ -593,15 +593,9 @@
structure of the replication <quote>tree</quote>
changes.</para></listitem>
-<listitem><para> Version 1.1 should provide better tools to help
-manage this.</para>
-
-<para> In fact, it does. <xref linkend="autolisten"> provides a
-heuristic to generate listener entries. If you are still tied to
-earlier versions, a Perl script, <xref linkend="regenlisten">,
-provides a way of querying a live &slony1; instance and generating the
-<xref linkend="slonik"> commands to generate the listen path
-network.</para></listitem>
+<listitem><para> Version 1.1 provides better tools to help manage
+this.</para>
+</listitem>
</itemizedlist></para>
Index: addthings.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/addthings.sgml,v
retrieving revision 1.11
retrieving revision 1.12
diff -Ldoc/adminguide/addthings.sgml -Ldoc/adminguide/addthings.sgml -u -w -r1.11 -r1.12
--- doc/adminguide/addthings.sgml
+++ doc/adminguide/addthings.sgml
@@ -5,16 +5,15 @@
<para>You may discover that you have missed replicating things that
you wish you were replicating.</para>
-<para>This can be fairly easily remedied.</para>
+<para>This can generally be fairly easily remedied.</para>
-<para>You cannot directly use <xref linkend="slonik">
-<xref linkend="stmtsetaddtable"> or <xref linkend="stmtsetaddsequence">
-in order to add tables and sequences
-to a replication set that is presently replicating; you must instead
-create a new replication set. Once it is identically subscribed
-(e.g. - the set of providers and subscribers is <emphasis>entirely
-identical</emphasis> to that for the set it is to merge with), the
-sets may be merged together using <xref
+<para>You cannot directly use <xref linkend="slonik"> <xref
+linkend="stmtsetaddtable"> or <xref linkend="stmtsetaddsequence"> in
+order to add tables and sequences to a replication set that is
+presently replicating; you must instead create a new replication set.
+Once it is identically subscribed (e.g. - the set of providers and
+subscribers is <emphasis>entirely identical</emphasis> to that for the
+set it is to merge with), the sets may be merged together using <xref
linkend="stmtmergeset">.</para>
<para>Up to and including 1.0.2, there was a potential problem where
@@ -45,6 +44,148 @@
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.</para>
+
+<para> Here are a set of <quote>recipes</quote> for how to do various
+sorts of modifications to replication configuration:</para>
+
+<itemizedlist>
+<listitem><para> Adding a table to replication </para>
+
+<para> &slony1; does not allow you to add a table to a replication set
+that is already being replicated. In principle, it would certainly be
+<emphasis>possible;</emphasis> what would happen is that the
+SET_ADD_TABLE event would lead to the relevant code from the
+SUBSCRIBE_SET event being invoked to initialize the table. That would,
+regrettably, significantly complicate the logic of all of these
+components, so this is not permitted. </para>
+
+<para>Instead, what you must do is thus:
+
+<itemizedlist>
+<listitem><para> Add the new table on each node. </para>
+
+<para> In principle, <xref linkend="stmtddlscript"> could be used for
+this, but the fact that this leads to <link linkend="locking"> Locking
+Issues </link> and requires altering <emphasis>all</emphasis> tables
+in some existing replication set, on <emphasis>all</emphasis> nodes,
+makes <xref linkend="stmtddlscript"> an unattractive approach on a
+busy system. This breaks the &slony1; feature that you <quote>don't
+have to interrupt normal activity to introduce replication.</quote>
+</para>
+
+<para> Instead, you can add the table via
+<application>psql</application> on each node.
+
+</para> </listitem>
+
+<listitem><Para> Create a new replication set <xref linkend="stmtcreateset">
+</para></listitem>
+<listitem><para>
+Add the table to the new set <xref linkend="stmtsetaddtable">
+</para></listitem>
+<listitem><para>
+Request subscription <xref linkend="stmtsubscribeset"> for this new set. If there are several nodes, you will need to <xref linkend="stmtsubscribeset"> once for each node that should subscribe.
+</para></listitem>
+<listitem><para>
+Once the subscriptions have all been set up so that the new set has an identical set of subscriptions to the old set, you can merge the new set in alongside the old one via <xref linkend="stmtmergeset">
+</itemizedlist>
+</listitem>
+<listitem><para> How to add columns to a replicated table </para>
+
+<para> This also answers the question <quote>How do I rename columns
+on a replicated table?</quote>, and, more generally, other questions
+to the effect of <quote>How do I modify the definitions of replicated
+tables?</quote></para>
+
+<para>If you change the <quote>shape</quote> of a replicated table, this needs to take place at exactly the same point in all of the <quote>transaction streams</quote> on all nodes that are subscribed to the set containing the table.</para>
+
+<para> Thus, the way to do this is to construct an SQL script consisting of the DDL changes, and then submit that script to all of the nodes via the Slonik command <xref linkend="stmtddlscript">.
+
+<para> There are a number of <quote>sharp edges</quote> to note...
+<itemizedlist>
+ <listitem><para> You absolutely <emphasis>must not</emphasis> include transaction control commands, particularly <command>BEGIN</command> and <command>COMMIT</command>, inside these DDL scripts. &slony1; wraps DDL scripts with a <command>BEGIN</command>/<command>COMMIT</command> pair; adding extra transaction control will mean that parts of the DDL will commit outside the control of &slony1; </para></listitem>
+
+ <listitem><Para> Avoid, if possible, having quotes in the DDL script </para> </listitem>
+</itemizedlist>
+
+</para></listitem>
+<listitem><para> How to remove replication for a node
+<para> You will want to remove the various &slony1; components connected to the database(s).</para>
+
+<para> We will just consider, for now, doing this to one node. If you have multiple nodes, you will have to repeat this as many times as necessary.</para>
+
+<para> Components to be Removed: </para>
+<itemizedlist>
+<listitem><para> Log Triggers / Update Denial Triggers
+
+</para></listitem>
+<listitem><para> The "cluster" schema containing &slony1; tables indicating the state of the node as well as various stored functions
+</para></listitem>
+<listitem><para>
+ <xref linkend="slon"> process that manages the node
+</para></listitem>
+<listitem><para>
+ Optionally, the SQL and pl/pgsql scripts and &slony1; binaries that are part of the &postgres; build. (Of course, this would make it challenging to restart replication; it is unlikely that you truly need to do this...)
+</para></listitem>
+</itemizedlist>
+
+<para> How To Conveniently Handle Removal</para>
+<itemizedlist>
+<listitem><para>
+ You may use the Slonik <xref linkend="stmtdropnode"> command to remove the node from the cluster. This will lead to the triggers and everything in the cluster schema being dropped from the node. The <xref linkend="slon"> process will automatically die off.
+</para></listitem>
+<listitem><para>
+
+ In the case of a failed node (where you used <xref linkend="stmtfailover"> to switch to another node), you may need to use <xref linkend="stmtuninstallnode"> to drop out the triggers and schema and functions.
+</para></listitem>
+<listitem><para>
+
+ If the above things work out particularly badly, you could submit the SQL command <command>DROP SCHEMA "_ClusterName" CASCADE;</command>, which will drop out &slony1; functions, tables, and triggers alike.
+</para></listitem>
+</itemizedlist>
+</listitem>
+
+<listitem><para> Adding A Node To Replication</para>
+
+<para>Things are not fundamentally different whether you are adding a brand new, fresh node, or if you had previously dropped a node and are recreating it. In either case, you are adding a node to replication. </para>
+
+<para>The needful steps are thus... </para>
+<itemizedlist>
+<listitem><para>
+ Determine the node number and any relevant DSNs for the new node. Use &postgres; command <command>createdb</command> to create the database; add the table definitions for the tables that are to be replicated, as &slony1; does not automatically propagate that information.
+</para></listitem>
+<listitem><para>
+ If the node had been a failed node, you may need to issue the <xref linkend="slonik"> command <xref linkend="stmtdropnode"> in order to get rid of its vestiges in the cluster, and to drop out the schema that &slony1; creates.
+</para></listitem>
+<listitem><para>
+ Issue the slonik command <xref linkend="stmtstorenode"> to establish the new node.
+</para></listitem>
+<listitem><para>
+ At this point, you may start a <xref linkend="slon"> daemon against the new node. It may not know much about the other nodes yet, so the logs for this node may be pretty quiet.
+</para></listitem>
+<listitem><para>
+ Issue the slonik command <xref linkend="stmtstorepath"> to indicate how <xref linkend="slon"> processes are to communicate with the new node. In &slony1; version 1.1 and later, this will then automatically generate <link linkend="listenpaths"> listen path </link> entries; in earlier versions, you will need to use <xref linkend="stmtstorelisten"> to generate them manually.
+</para></listitem>
+<listitem><para>
+ Issue the slonik command <xref linkend="stmtsubscribeset"> to subscribe the node to some replication set.
+</para></listitem>
+</itemizedlist>
+</listitem>
+
+<listitem><para> How do I reshape the subscriptions?
+
+<para> For instance, I want subscriber node 3 to draw data from node
+1, when it is presently drawing data from node 2. </para>
+
+<para> This isn't a case for <xref linkend="stmtmoveset">; we're not
+shifting the origin, just reshaping the subscribers. </para>
+
+<para> For this purpose, you can simply submit <xref
+linkend="stmtsubscribeset"> requests to <emphasis>revise</emphasis>
+the subscriptions. Subscriptions will not be started from scratch;
+they will merely be reconfigured. </para></listitem>
+
+</itemizedlist>
</sect1>
<!-- Keep this comment at the end of the file
Local variables:
Index: intro.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/intro.sgml,v
retrieving revision 1.20
retrieving revision 1.21
diff -Ldoc/adminguide/intro.sgml -Ldoc/adminguide/intro.sgml -u -w -r1.20 -r1.21
--- doc/adminguide/intro.sgml
+++ doc/adminguide/intro.sgml
@@ -136,15 +136,36 @@
<para>&slony1; 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 &slony1;
-operates using triggers, and neither schema changes nor large object
-operations can raise triggers suitable to tell &slony1; when those
-kinds of changes take place.</para>
-
-<para>There is a capability for &slony1; to propagate DDL changes if
-you submit them as scripts via the <application>slonik</application>
-<xref linkend="stmtddlscript"> operation. That is not
-<quote>automatic;</quote> you have to construct an SQL DDL script and
-submit it, and there are a number of further <link
+collects updates using triggers, and neither schema changes nor large
+object operations are able to triggers suitable to inform &slony1;
+when those sorts of changes take place. As a result, the only
+database objects where &slony1; can replicate updates are tables and
+sequences. </para>
+
+<para> Note that with the <emphasis>use</emphasis> of triggers comes
+some additional <emphasis>fiddling around with triggers</emphasis>.
+On the <quote>origin</quote> for each replicated table, an additional
+trigger is added which runs the stored procedure <xref
+linkend="function.logtrigger">. On each subscriber, tables are
+augmented with a trigger that runs the <xref
+linkend="function.denyaccess"> function; this function prevents
+anything other than the <xref linkend="slon"> process from updating
+data in replicated tables. In addition, any
+<emphasis>other</emphasis> triggers and rules on replicated tables are
+<emphasis>suppressed</emphasis> on the subscribers: This is done by
+pointing them, in the system table, to the primary key index instead
+of to the table itself. This represents something of a
+<quote>corruption</quote> of the data dictionary, and is why you
+should not directly use <application>pg_dump</application> to dump
+schemas on subscribers. </para>
+
+<para>There is a capability for &slony1; to propagate other kinds of
+database modifications, notably DDL changes, if you submit them as
+scripts via the <application>slonik</application> <xref
+linkend="stmtddlscript"> operation. That is not handled
+<quote>automaticly;</quote> you, as a database administrator, will
+have to construct an SQL DDL script and submit it, via <xref
+linkend="stmtddlscript"> and there are a number of further <link
linkend="ddlchanges"> caveats.</link></para>
<para>If you have those sorts of requirements, it may be worth
@@ -174,8 +195,8 @@
people.</para>
<para> &slony1; implements a particular model, namely that of
-asynchronous replication, using triggers, where a single
-<quote>origin</quote> may be replicated to multiple
+asynchronous replication, using triggers to collect table updates,
+where a single <quote>origin</quote> may be replicated to multiple
<quote>subscribers</quote> including cascaded subscribers.</para>
<para> There are a number of other replication models which are
Index: listenpaths.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/listenpaths.sgml,v
retrieving revision 1.16
retrieving revision 1.17
diff -Ldoc/adminguide/listenpaths.sgml -Ldoc/adminguide/listenpaths.sgml -u -w -r1.16 -r1.17
--- doc/adminguide/listenpaths.sgml
+++ doc/adminguide/listenpaths.sgml
@@ -203,12 +203,6 @@
<function>RebuildListenEntries()</function> will be called to revise
the listener paths.</para>
-<para> If you are running an earlier version of &slony1;, you may want
-to take a look at <xref linkend="regenlisten">, a Perl script which
-duplicates the functionality of the stored procedure in the form of a
-script that generates the <xref linkend="slonik"> requests to
-generate the listener paths.</para></sect2>
-
</sect1>
<!-- Keep this comment at the end of the file
Local variables:
Index: logshipping.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/logshipping.sgml,v
retrieving revision 1.12
retrieving revision 1.13
diff -Ldoc/adminguide/logshipping.sgml -Ldoc/adminguide/logshipping.sgml -u -w -r1.12 -r1.13
--- doc/adminguide/logshipping.sgml
+++ doc/adminguide/logshipping.sgml
@@ -168,7 +168,9 @@
<command>SET_ADD_TABLE</command>,
<command>SET_ADD_SEQUENCE</command>,
<command>STORE_TRIGGER</command>,
-<command>DROP_TRIGGER</command>,</para></listitem>
+<command>DROP_TRIGGER</command>,
+<command>TABLE_ADD_KEY</command>
+</para></listitem>
</itemizedlist>
</para>
Index: slony.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slony.sgml,v
retrieving revision 1.26
retrieving revision 1.27
diff -Ldoc/adminguide/slony.sgml -Ldoc/adminguide/slony.sgml -u -w -r1.26 -r1.27
--- doc/adminguide/slony.sgml
+++ doc/adminguide/slony.sgml
@@ -10,7 +10,7 @@
<!ENTITY postgres "<PRODUCTNAME>PostgreSQL</PRODUCTNAME>">
<!ENTITY nagios "<PRODUCTNAME>Nagios</PRODUCTNAME>">
<!ENTITY windows "<trademark>Windows</trademark>">
- <!ENTITY logship "<link linkend=logshipping>log shipping</link>">
+ <!ENTITY logshiplink "<link linkend=logshipping>log shipping</link>">
<!ENTITY rlocking "<link linkend=locking> locking </link>">
<!ENTITY rddlchanges "<xref linkend=ddlchanges>">
<!ENTITY fundroplisten "<xref linkend=function.droplisten-integer-integer-integer>">
@@ -39,6 +39,7 @@
<!ENTITY fununinstallnode "<xref linkend=function.uninstallnode>">
<!ENTITY fununlockset "<xref linkend=function.unlockset-integer>">
<!ENTITY fununsubscribeset "<xref linkend=function.unsubscribeset-integer-integer>">
+ <!ENTITY bestpracticelink "<link linkend=bestpractices>Best Practice</link>">
<!ENTITY rmissingoids "<link linkend=missingoids>error messages indicating missing OIDs</link>">
<!ENTITY slnode "<xref linkend=table.sl-node>">
<!ENTITY slconfirm "<xref linkend=table.sl-confirm>">
@@ -89,7 +90,7 @@
&locking;
&addthings;
&dropthings;
- &logshipping;
+ &logshipfile;
&ddlchanges;
&usingslonik;
&adminscripts;
- Previous message: [Slony1-commit] By cbbrowne: Numerous updates to documentation based on Brian A.
- Next message: [Slony1-commit] By cbbrowne: slon SUBSCRIBE_SET event now requests an exclusive lock on
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-commit mailing list