Mon Feb 25 07:38:00 PST 2008
- Previous message: [Slony1-commit] slony1-engine/doc/adminguide slonconf.sgml
- Next message: [Slony1-commit] slony1-engine/config acx_libpq.m4
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Update of /home/cvsd/slony1/slony1-engine/doc/adminguide
In directory main.slony.info:/tmp/cvs-serv2382
Modified Files:
Makefile bestpractices.sgml cluster.sgml concepts.sgml
defineset.sgml failover.sgml faq.sgml intro.sgml
listenpaths.sgml maintenance.sgml monitoring.sgml
slonik_ref.sgml slony.sgml
Log Message:
Changed over to using entity references to point to sl_log_[12], sl_seqlog
Index: cluster.sgml
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/cluster.sgml,v
retrieving revision 1.13
retrieving revision 1.14
diff -C2 -d -r1.13 -r1.14
*** cluster.sgml 2 Aug 2006 18:34:57 -0000 1.13
--- cluster.sgml 25 Feb 2008 15:37:58 -0000 1.14
***************
*** 13,20 ****
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
--- 13,19 ----
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 &sllog1;
! and &sllog2; 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
Index: defineset.sgml
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/defineset.sgml,v
retrieving revision 1.29
retrieving revision 1.30
diff -C2 -d -r1.29 -r1.30
*** defineset.sgml 4 Feb 2008 20:56:22 -0000 1.29
--- defineset.sgml 25 Feb 2008 15:37:58 -0000 1.30
***************
*** 173,178 ****
<para> Each time a SYNC is processed, values are recorded for
<emphasis>all</emphasis> of the sequences in the set. If there are a
! lot of sequences, this can cause <xref linkend="table.sl-seqlog"> to
! grow rather large.</para>
<para> This points to an important difference between tables and
--- 173,178 ----
<para> Each time a SYNC is processed, values are recorded for
<emphasis>all</emphasis> of the sequences in the set. If there are a
! lot of sequences, this can cause &slseqlog; to grow rather
! large.</para>
<para> This points to an important difference between tables and
***************
*** 189,204 ****
<para> If it is not updated, the trigger on the table on the origin
! never fires, and no entries are added to <xref
! linkend="table.sl-log-1">. The table never appears in any of the
further replication queries (<emphasis>e.g.</emphasis> in the
<command>FETCH 100 FROM LOG</command> queries used to find
replicatable data) as they only look for tables for which there are
! entries in <xref linkend="table.sl-log-1">.</para></listitem>
<listitem><para> In contrast, a fixed amount of work is introduced to
each SYNC by each sequence that is replicated.</para>
! <para> Replicate 300 sequence and 300 rows need to be added to <xref
! linkend="table.sl-seqlog"> on a regular basis.</para>
<para> It is more than likely that if the value of a particular
--- 189,205 ----
<para> If it is not updated, the trigger on the table on the origin
! never fires, and no entries are added to &sllog1;/&sllog2;. The table never appears in any of the
further replication queries (<emphasis>e.g.</emphasis> in the
<command>FETCH 100 FROM LOG</command> queries used to find
replicatable data) as they only look for tables for which there are
! entries in &sllog1;/&sllog2;.</para></listitem>
<listitem><para> In contrast, a fixed amount of work is introduced to
each SYNC by each sequence that is replicated.</para>
! <para> Replicate 300 sequence and 300 rows need to be added to
! &slseqlog; on a regular basis, at least, thru until the 2.0 branch,
! where updates are only applied when the value of a given sequence is
! seen to change.</para>
<para> It is more than likely that if the value of a particular
Index: intro.sgml
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/intro.sgml,v
retrieving revision 1.28
retrieving revision 1.29
diff -C2 -d -r1.28 -r1.29
*** intro.sgml 11 Jun 2007 16:02:50 -0000 1.28
--- intro.sgml 25 Feb 2008 15:37:58 -0000 1.29
***************
*** 297,307 ****
<listitem><para> Each SYNC applied needs to be reported back to all of
the other nodes participating in the set so that the nodes all know
! that it is safe to purge <xref linkend="table.sl-log-1"> and <xref
! linkend="table.sl-log-2"> data, as any <quote>forwarding</quote> node
! could potentially take over as <quote>master</quote> at any time. One
! might expect SYNC messages to need to travel through n/2 nodes to get
! propagated to their destinations; this means that each SYNC is
! expected to get transmitted n(n/2) times. Again, this points to a
! quadratic growth in communications costs as the number of nodes
increases.</para></listitem>
--- 297,307 ----
<listitem><para> Each SYNC applied needs to be reported back to all of
the other nodes participating in the set so that the nodes all know
! that it is safe to purge &sllog1; and &sllog2; data, as
! any <quote>forwarding</quote> node could potentially take over
! as <quote>master</quote> at any time. One might expect SYNC messages
! to need to travel through n/2 nodes to get propagated to their
! destinations; this means that each SYNC is expected to get transmitted
! n(n/2) times. Again, this points to a quadratic growth in
! communications costs as the number of nodes
increases.</para></listitem>
Index: failover.sgml
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/failover.sgml,v
retrieving revision 1.24
retrieving revision 1.25
diff -C2 -d -r1.24 -r1.25
*** failover.sgml 17 Dec 2007 20:18:31 -0000 1.24
--- failover.sgml 25 Feb 2008 15:37:58 -0000 1.25
***************
*** 195,203 ****
set of references to node 1 in <xref linkend="table.sl-node">, as well
as in referring tables such as <xref linkend="table.sl-confirm">;
! since data in <xref linkend="table.sl-log-1"> is still present,
! &slony1; cannot immediately purge out the node. </para>
! <para> After the failover is complete and node2 accepts
! write operations against the tables, remove all remnants of node1's
configuration information with the <xref linkend="stmtdropnode">
command:
--- 195,203 ----
set of references to node 1 in <xref linkend="table.sl-node">, as well
as in referring tables such as <xref linkend="table.sl-confirm">;
! since data in &sllog1;/&sllog2; is still present, &slony1; cannot
! immediately purge out the node. </para>
! <para> After the failover is complete and node2 accepts write
! operations against the tables, remove all remnants of node1's
configuration information with the <xref linkend="stmtdropnode">
command:
Index: monitoring.sgml
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/monitoring.sgml,v
retrieving revision 1.40
retrieving revision 1.41
diff -C2 -d -r1.40 -r1.41
*** monitoring.sgml 22 Aug 2007 22:05:00 -0000 1.40
--- monitoring.sgml 25 Feb 2008 15:37:58 -0000 1.41
***************
*** 174,180 ****
<para> If one or another of the nodes in the cluster hasn't reported
! back recently, that tends to lead to cleanups of tables like <xref
! linkend="table.sl-log-1"> and <xref linkend="table.sl-seqlog"> not
! taking place.</para></listitem>
<listitem><para> Summarizes what transactions have been running for a
--- 174,179 ----
<para> If one or another of the nodes in the cluster hasn't reported
! back recently, that tends to lead to cleanups of tables like &sllog1;,
! &sllog2; and &slseqlog; not taking place.</para></listitem>
<listitem><para> Summarizes what transactions have been running for a
Index: Makefile
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/Makefile,v
retrieving revision 1.19
retrieving revision 1.20
diff -C2 -d -r1.19 -r1.20
*** Makefile 2 Aug 2006 15:32:01 -0000 1.19
--- Makefile 25 Feb 2008 15:37:58 -0000 1.20
***************
*** 252,255 ****
--- 252,256 ----
TEMPSCHEMA=schemadoc
CREATELANG=$(pgbindir)/createlang # That's how it is for me...
+ PGAUTODOC=/usr/bin/postgresql_autodoc
schemadoc.xml: $(BASESQL) $(BASEFUNS) $(XIDDIR)
***************
*** 259,264 ****
cat $(XIDSQL) $(BASEFUNS) $(BASESQL) | sed -e "s/@NAMESPACE@/$(TEMPSCHEMA)/g" -e "s/@CLUSTERNAME@/$(TEMPSCHEMA)/g" | $(pgbindir)/psql $(TEMPDB) && \
$(PGAUTODOC) -d $(TEMPDB) -s $(TEMPSCHEMA) -t xml -f schemadoc ;\
! sed -i.bak -e "s/$(TEMPSCHEMA)\.//g" \
! -e "s@<book.*>@@g" -e "s@</book.*>@@g" schemadoc.xml ;\
rm schemadoc.xml.bak ;\
$(pgbindir)/dropdb $(TEMPDB) >/dev/null 2>&1 \
--- 260,264 ----
cat $(XIDSQL) $(BASEFUNS) $(BASESQL) | sed -e "s/@NAMESPACE@/$(TEMPSCHEMA)/g" -e "s/@CLUSTERNAME@/$(TEMPSCHEMA)/g" | $(pgbindir)/psql $(TEMPDB) && \
$(PGAUTODOC) -d $(TEMPDB) -s $(TEMPSCHEMA) -t xml -f schemadoc ;\
! sed -i.bak -e "s/$(TEMPSCHEMA)\.//g" -e "s@<book.*>@@g" -e "s@</book.*>@@g" schemadoc.xml ;\
rm schemadoc.xml.bak ;\
$(pgbindir)/dropdb $(TEMPDB) >/dev/null 2>&1 \
Index: bestpractices.sgml
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/bestpractices.sgml,v
retrieving revision 1.29
retrieving revision 1.30
diff -C2 -d -r1.29 -r1.30
*** bestpractices.sgml 2 Jan 2008 19:12:42 -0000 1.29
--- bestpractices.sgml 25 Feb 2008 15:37:58 -0000 1.30
***************
*** 104,110 ****
<listitem><para> The system will periodically rotate (using
<command>TRUNCATE</command> to clean out the old table) between the
! two log tables, <xref linkend="table.sl-log-1"> and <xref
! linkend="table.sl-log-2">, preventing unbounded growth of dead space
! there. </para></listitem>
</itemizedlist>
--- 104,109 ----
<listitem><para> The system will periodically rotate (using
<command>TRUNCATE</command> to clean out the old table) between the
! two log tables, &sllog1; and &sllog2;, preventing unbounded growth of
! dead space there. </para></listitem>
</itemizedlist>
***************
*** 590,595 ****
<para> There will correspondingly be an <emphasis>enormous</emphasis>
! growth of <xref linkend="table.sl-log-1"> and <xref
! linkend="table.sl-seqlog">. Unfortunately, once the
<command>COPY_SET</command> completes, users have found that the
queries against these tables wind up reverting to <command>Seq
--- 589,593 ----
<para> There will correspondingly be an <emphasis>enormous</emphasis>
! growth of &sllog1;, &sllog2;, and &slseqlog;. Unfortunately, once the
<command>COPY_SET</command> completes, users have found that the
queries against these tables wind up reverting to <command>Seq
Index: listenpaths.sgml
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/listenpaths.sgml,v
retrieving revision 1.20
retrieving revision 1.21
diff -C2 -d -r1.20 -r1.21
*** listenpaths.sgml 11 Jun 2007 16:02:50 -0000 1.20
--- listenpaths.sgml 25 Feb 2008 15:37:58 -0000 1.21
***************
*** 26,32 ****
<emphasis>all</emphasis> nodes in order to be able to conclude that
<command>sync</command>s have been received everywhere, and that,
! therefore, entries in <xref linkend="table.sl-log-1"> and <xref
! linkend="table.sl-log-2"> have been applied everywhere, and can
! therefore be purged. this extra communication is needful so
<productname>Slony-I</productname> is able to shift origins to other
locations.</para>
--- 26,32 ----
<emphasis>all</emphasis> nodes in order to be able to conclude that
<command>sync</command>s have been received everywhere, and that,
! therefore, entries in &sllog1; and &sllog2; have been applied
! everywhere, and can therefore be purged. this extra communication is
! needful so
<productname>Slony-I</productname> is able to shift origins to other
locations.</para>
Index: slony.sgml
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/slony.sgml,v
retrieving revision 1.39
retrieving revision 1.40
diff -C2 -d -r1.39 -r1.40
*** slony.sgml 28 Jan 2008 19:35:21 -0000 1.39
--- slony.sgml 25 Feb 2008 15:37:58 -0000 1.40
***************
*** 45,48 ****
--- 45,49 ----
<!ENTITY sllog1 "<xref linkend=table.sl-log-1>">
<!ENTITY sllog2 "<xref linkend=table.sl-log-2>">
+ <!ENTITY slseqlog "<xref linkend=table.sl-seqlog>">
<!ENTITY slconfirm "<xref linkend=table.sl-confirm>">
<!ENTITY rplainpaths "<xref linkend=plainpaths>">
Index: concepts.sgml
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/concepts.sgml,v
retrieving revision 1.20
retrieving revision 1.21
diff -C2 -d -r1.20 -r1.21
*** concepts.sgml 2 Aug 2006 18:34:57 -0000 1.20
--- concepts.sgml 25 Feb 2008 15:37:58 -0000 1.21
***************
*** 41,45 ****
<para>The cluster name is specified in each and every Slonik script via the directive:</para>
<programlisting>
! cluster name = 'something';
</programlisting>
--- 41,45 ----
<para>The cluster name is specified in each and every Slonik script via the directive:</para>
<programlisting>
! cluster name = something;
</programlisting>
Index: slonik_ref.sgml
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/slonik_ref.sgml,v
retrieving revision 1.79
retrieving revision 1.80
diff -C2 -d -r1.79 -r1.80
*** slonik_ref.sgml 14 Feb 2008 16:38:08 -0000 1.79
--- slonik_ref.sgml 25 Feb 2008 15:37:58 -0000 1.80
***************
*** 525,529 ****
<application>slonik</application> will not attempt to
initialize a database with the replication
! schema.</para></listitem>
</varlistentry>
--- 525,535 ----
<application>slonik</application> will not attempt to
initialize a database with the replication
! schema.</para>
!
! <warning><para> Never use the SPOOLNODE value - no released
! version of &slony1; has ever behaved in the fashion described
! in the preceding fashion. Log shipping, as it finally emerged
! in 1.2.11, does not require initializing <quote>spool
! nodes</quote>.</para> </warning> </listitem>
</varlistentry>
***************
*** 555,559 ****
parameter was introduced in version 1.1, but was vestigal in that
version. The described functionality for <envar>SPOOLNODE</envar>
! arrives in version 1.2. </para>
</refsect1>
</Refentry>
--- 561,567 ----
parameter was introduced in version 1.1, but was vestigal in that
version. The described functionality for <envar>SPOOLNODE</envar>
! arrived in version 1.2, but <envar>SPOOLNODE</envar> was not used
! for this purpose. In later versions, hopefully
! <envar>SPOOLNODE</envar> will be unavailable. </para>
</refsect1>
</Refentry>
Index: faq.sgml
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/faq.sgml,v
retrieving revision 1.73
retrieving revision 1.74
diff -C2 -d -r1.73 -r1.74
*** faq.sgml 4 Jan 2008 23:05:50 -0000 1.73
--- faq.sgml 25 Feb 2008 15:37:58 -0000 1.74
***************
*** 759,775 ****
<qandaentry>
! <question> <para> Replication has fallen behind, and it appears that the
! queries to draw data from <xref linkend="table.sl-log-1">/<xref
! linkend="table.sl-log-2"> are taking a long time to pull just a few
<command>SYNC</command>s. </para>
</question>
! <answer> <para> Until version 1.1.1, there was only one index on <xref
! linkend="table.sl-log-1">/<xref linkend="table.sl-log-2">, and if
! there were multiple replication sets, some of the columns on the index
! would not provide meaningful selectivity. If there is no index on
! column <function> log_xid</function>, consider adding it. See
! <filename>slony1_base.sql</filename> for an example of how to create
! the index.
</para>
</answer>
--- 759,774 ----
<qandaentry>
! <question> <para> Replication has fallen behind, and it appears that
! the queries to draw data from &sllog1;/&sllog2; are taking a long time
! to pull just a few
<command>SYNC</command>s. </para>
</question>
! <answer> <para> Until version 1.1.1, there was only one index on
! &sllog1;/&sllog2;, and if there were multiple replication sets, some
! of the columns on the index would not provide meaningful selectivity.
! If there is no index on column <function> log_xid</function>, consider
! adding it. See <filename>slony1_base.sql</filename> for an example of
! how to create the index.
</para>
</answer>
***************
*** 1155,1160 ****
<question><para> Replication has been slowing down, I'm seeing
<command> FETCH 100 FROM LOG </command> queries running for a long
! time, <xref linkend="table.sl-log-1"> is growing, and performance is,
! well, generally getting steadily worse. </para>
</question>
--- 1154,1159 ----
<question><para> Replication has been slowing down, I'm seeing
<command> FETCH 100 FROM LOG </command> queries running for a long
! time, &sllog1;/&sllog2; is growing, and performance is, well,
! generally getting steadily worse. </para>
</question>
***************
*** 1179,1185 ****
<listitem><para> The cleanup thread will be unable to clean out
! entries in <xref linkend="table.sl-log-1"> and <xref
! linkend="table.sl-seqlog">, with the result that these tables will
! grow, ceaselessly, until the transaction is closed. </para>
</listitem>
</itemizedlist>
--- 1178,1184 ----
<listitem><para> The cleanup thread will be unable to clean out
! entries in &sllog1;, &sllog2;, and &slseqlog;, with the result that
! these tables will grow, ceaselessly, until the transaction is
! closed. </para>
</listitem>
</itemizedlist>
***************
*** 1220,1225 ****
<qandaentry id="faq17">
! <question><para>After dropping a node, <xref linkend="table.sl-log-1">
! isn't getting purged out anymore.</para></question>
<answer><para> This is a common scenario in versions before 1.0.5, as
--- 1219,1224 ----
<qandaentry id="faq17">
! <question><para>After dropping a node, &sllog1;/&sllog2;
! aren't getting purged out anymore.</para></question>
<answer><para> This is a common scenario in versions before 1.0.5, as
***************
*** 1285,1290 ****
<listitem><para> At the start of each
<function>cleanupEvent</function> run, which is the event in which old
! data is purged from <xref linkend="table.sl-log-1"> and <xref
! linkend="table.sl-seqlog"></para></listitem> </itemizedlist></para>
</answer>
</qandaentry>
--- 1284,1289 ----
<listitem><para> At the start of each
<function>cleanupEvent</function> run, which is the event in which old
! data is purged from &sllog1;, &sllog2;, and
! &slseqlog;</para></listitem> </itemizedlist></para>
</answer>
</qandaentry>
***************
*** 1296,1306 ****
sync through.</para></question>
! <answer><para> You might want to take a look at the <xref
! linkend="table.sl-log-1">/<xref linkend="table.sl-log-2"> tables, and
! do a summary to see if there are any really enormous &slony1;
! transactions in there. Up until at least 1.0.2, there needs to be a
! &lslon; connected to the origin in order for
<command>SYNC</command> events to be generated.</para>
<para>If none are being generated, then all of the updates until the
next one is generated will collect into one rather enormous &slony1;
--- 1295,1308 ----
sync through.</para></question>
! <answer><para> You might want to take a look at the tables &sllog1;
! and &sllog2; and do a summary to see if there are any really enormous
! &slony1; transactions in there. Up until at least 1.0.2, there needs
! to be a &lslon; connected to the origin in order for
<command>SYNC</command> events to be generated.</para>
+ <note><para> As of 1.0.2,
+ function <function>generate_sync_event()</function> provides an
+ alternative as backup...</para> </note>
+
<para>If none are being generated, then all of the updates until the
next one is generated will collect into one rather enormous &slony1;
***************
*** 1523,1529 ****
nodes. I am discovering that confirmations for set 1 never get to the
nodes subscribing to set 2, and that confirmations for set 2 never get
! to nodes subscribing to set 1. As a result, <xref
! linkend="table.sl-log-1"> grows and grows and is never purged. This
! was reported as &slony1; <ulink
url="http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1485">
bug 1485 </ulink>.
--- 1525,1531 ----
nodes. I am discovering that confirmations for set 1 never get to the
nodes subscribing to set 2, and that confirmations for set 2 never get
! to nodes subscribing to set 1. As a result, &sllog1;/&sllog2; grow
! and grow, and are never purged. This was reported as
! &slony1; <ulink
url="http://gborg.postgresql.org/project/slony1/bugs/bugupdate.php?1485">
bug 1485 </ulink>.
***************
*** 1577,1582 ****
subscriber to a particular provider are for
<quote>sequence-only</quote> sets. If a node gets into that state,
! replication will fail, as the query that looks for data from <xref
! linkend="table.sl-log-1"> has no tables to find, and the query will be
malformed, and fail. If a replication set <emphasis>with</emphasis>
tables is added back to the mix, everything will work out fine; it
--- 1579,1584 ----
subscriber to a particular provider are for
<quote>sequence-only</quote> sets. If a node gets into that state,
! replication will fail, as the query that looks for data from
! &sllog1;/&sllog2; has no tables to find, and the query will be
malformed, and fail. If a replication set <emphasis>with</emphasis>
tables is added back to the mix, everything will work out fine; it
***************
*** 1880,1899 ****
<para>By the time we notice that there is a problem, the seemingly
! missed delete transaction has been cleaned out of <xref
! linkend="table.sl-log-1">, so there appears to be no recovery
! possible. What has seemed necessary, at this point, is to drop the
! replication set (or even the node), and restart replication from
! scratch on that node.</para>
! <para>In &slony1; 1.0.5, the handling of purges of <xref
! linkend="table.sl-log-1"> became more conservative, refusing to purge
! entries that haven't been successfully synced for at least 10 minutes
! on all nodes. It was not certain that that would prevent the
! <quote>glitch</quote> from taking place, but it seemed plausible that
! it might leave enough <xref linkend="table.sl-log-1"> data to be able
! to do something about recovering from the condition or at least
! diagnosing it more exactly. And perhaps the problem was that <xref
! linkend="table.sl-log-1"> was being purged too aggressively, and this
! would resolve the issue completely.</para>
<para> It is a shame to have to reconstruct a large replication node
--- 1882,1899 ----
<para>By the time we notice that there is a problem, the seemingly
! missed delete transaction has been cleaned out of &sllog1;, so there
! appears to be no recovery possible. What has seemed necessary, at
! this point, is to drop the replication set (or even the node), and
! restart replication from scratch on that node.</para>
! <para>In &slony1; 1.0.5, the handling of purges of &sllog1; became
! more conservative, refusing to purge entries that haven't been
! successfully synced for at least 10 minutes on all nodes. It was not
! certain that that would prevent the <quote>glitch</quote> from taking
! place, but it seemed plausible that it might leave enough &sllog1;
! data to be able to do something about recovering from the condition or
! at least diagnosing it more exactly. And perhaps the problem was that
! &sllog1; was being purged too aggressively, and this would resolve the
! issue completely.</para>
<para> It is a shame to have to reconstruct a large replication node
***************
*** 1906,1912 ****
<para> In one case we found two lines in the SQL error message in the
log file that contained <emphasis> identical </emphasis> insertions
! into <xref linkend="table.sl-log-1">. This <emphasis> ought
! </emphasis> to be impossible as is a primary key on <xref
! linkend="table.sl-log-1">. The latest (somewhat) punctured theory
that comes from <emphasis>that</emphasis> was that perhaps this PK
index has been corrupted (representing a &postgres; bug), and that
--- 1906,1911 ----
<para> In one case we found two lines in the SQL error message in the
log file that contained <emphasis> identical </emphasis> insertions
! into &sllog1;. This <emphasis> ought </emphasis> to be impossible as
! is a primary key on &sllog1;. The latest (somewhat) punctured theory
that comes from <emphasis>that</emphasis> was that perhaps this PK
index has been corrupted (representing a &postgres; bug), and that
***************
*** 2013,2018 ****
<para> That trigger initiates the action of logging all updates to the
! table to &slony1; <xref linkend="table.sl-log-1">
! tables.</para></listitem>
<listitem><para> On a subscriber node, this involves disabling
--- 2012,2016 ----
<para> That trigger initiates the action of logging all updates to the
! table to &slony1; &sllog1;/&sllog2; tables.</para></listitem>
<listitem><para> On a subscriber node, this involves disabling
***************
*** 2130,2134 ****
<para>The solution is to rebuild the trigger on the affected table and
! fix the entries in <xref linkend="table.sl-log-1"> by hand.</para>
<itemizedlist>
--- 2128,2132 ----
<para>The solution is to rebuild the trigger on the affected table and
! fix the entries in &sllog1;/&sllog2; by hand.</para>
<itemizedlist>
***************
*** 2149,2158 ****
</screen>
! <para>You then need to find the rows in <xref
! linkend="table.sl-log-1"> that have bad
! entries and fix them. You may
! want to take down the slon daemons for all nodes except the master;
! that way, if you make a mistake, it won't immediately propagate
! through to the subscribers.</para>
<para> Here is an example:</para>
--- 2147,2154 ----
</screen>
! <para>You then need to find the rows in &sllog1;/&sllog2; that have
! bad entries and fix them. You may want to take down the slon daemons
! for all nodes except the master; that way, if you make a mistake, it
! won't immediately propagate through to the subscribers.</para>
<para> Here is an example:</para>
Index: maintenance.sgml
===================================================================
RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/maintenance.sgml,v
retrieving revision 1.28
retrieving revision 1.29
diff -C2 -d -r1.28 -r1.29
*** maintenance.sgml 2 Jan 2008 19:12:42 -0000 1.28
--- maintenance.sgml 25 Feb 2008 15:37:58 -0000 1.29
***************
*** 11,17 ****
<listitem><para> Deletes old data from various tables in the
<productname>Slony-I</productname> cluster's namespace, notably
! entries in <xref linkend="table.sl-log-1">, <xref
! linkend="table.sl-log-2">, and <xref
! linkend="table.sl-seqlog">.</para></listitem>
<listitem><para> Vacuum certain tables used by &slony1;. As of 1.0.5,
--- 11,15 ----
<listitem><para> Deletes old data from various tables in the
<productname>Slony-I</productname> cluster's namespace, notably
! entries in &sllog1;, &sllog2;, and &slseqlog;.</para></listitem>
<listitem><para> Vacuum certain tables used by &slony1;. As of 1.0.5,
***************
*** 37,52 ****
<listitem> <para> The <link linkend="dupkey"> Duplicate Key Violation
! </link> bug has helped track down some &postgres; race conditions.
! One remaining issue is that it appears that is a case where
! <command>VACUUM</command> is not reclaiming space correctly, leading
! to corruption of B-trees. </para>
!
! <para> It may be helpful to run the command <command> REINDEX TABLE
! sl_log_1;</command> periodically to avoid the problem
! occurring. </para> </listitem>
<listitem><para> As of version 1.2, <quote>log switching</quote>
! functionality is in place; every so often, it seeks to switch between
! storing data in &sllog1; and &sllog2; so that it may seek
to <command>TRUNCATE</command> the <quote>elder</quote> data.</para>
--- 35,48 ----
<listitem> <para> The <link linkend="dupkey"> Duplicate Key Violation
! </link> bug has helped track down a number of rather obscure
! &postgres; race conditions, so that in modern versions of &slony1; and &postgres;, there should be little to worry about.
! </para>
! </listitem>
<listitem><para> As of version 1.2, <quote>log switching</quote>
! functionality is in place; every so often (by default, once per week,
! though you may induce it by calling the stored
! function <function>logswitch_start()</function>), it seeks to switch
! between storing data in &sllog1; and &sllog2; so that it may seek
to <command>TRUNCATE</command> the <quote>elder</quote> data.</para>
***************
*** 54,58 ****
cleared out, so that you will not suffer from them having grown to
some significant size, due to heavy load, after which they are
! incapable of shrinking back down </para> </listitem>
</itemizedlist>
--- 50,63 ----
cleared out, so that you will not suffer from them having grown to
some significant size, due to heavy load, after which they are
! incapable of shrinking back down </para>
!
! <para> In version 2.0, <command>DELETE</command> is no longer used to
! clear out data in &sllog1; and &sllog2;; instead, the log switch logic
! is induced frequently, every time the cleanup loop does not find a
! switch in progress, and these tables are purely cleared out
! via <command>TRUNCATE</command>. This eliminates the need to vacuum
! these tables. </para>
!
! </listitem>
</itemizedlist>
- Previous message: [Slony1-commit] slony1-engine/doc/adminguide slonconf.sgml
- Next message: [Slony1-commit] slony1-engine/config acx_libpq.m4
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-commit mailing list