Changeset 937

Timestamp:

03/02/08 18:33:18 (10 months ago)

Author:

daamien

Message:

Merge 1.2.12 > 1.2.13

Files:

• traduc/trunk/slony/addthings.xml (modified) (2 diffs)
• traduc/trunk/slony/adminscripts.xml (modified) (1 diff)
• traduc/trunk/slony/bestpractices.xml (modified) (4 diffs)
• traduc/trunk/slony/defineset.xml (modified) (2 diffs)
• traduc/trunk/slony/failover.xml (modified) (1 diff)
• traduc/trunk/slony/faq.xml (modified) (3 diffs)
• traduc/trunk/slony/filelist.xml (modified) (1 diff)
• traduc/trunk/slony/firstdb.xml (modified) (2 diffs)
• traduc/trunk/slony/installation.xml (modified) (3 diffs)
• traduc/trunk/slony/legal.xml (modified) (2 diffs)
• traduc/trunk/slony/loganalysis.xml (modified) (3 diffs)
• traduc/trunk/slony/logshipping.xml (modified) (3 diffs)
• traduc/trunk/slony/maintenance.xml (modified) (6 diffs)
• traduc/trunk/slony/monitoring.xml (modified) (3 diffs)
• traduc/trunk/slony/raceconditions.xml (added)
• traduc/trunk/slony/releasechecklist.xml (modified) (3 diffs)
• traduc/trunk/slony/schemadoc.xml (modified) (53 diffs)
• traduc/trunk/slony/slon.xml (modified) (1 diff)
• traduc/trunk/slony/slonconf.xml (modified) (2 diffs)
• traduc/trunk/slony/slonik_ref.xml (modified) (11 diffs)
• traduc/trunk/slony/slony.xml (modified) (3 diffs)
• traduc/trunk/slony/slonyupgrade.xml (modified) (1 diff)
• traduc/trunk/slony/subscribenodes.xml (modified) (1 diff)
• traduc/trunk/slony/supportedplatforms.xml (modified) (2 diffs)
• traduc/trunk/slony/testbed.xml (modified) (1 diff)
• traduc/trunk/slony/triggers.xml (added)
• traduc/trunk/slony/usingslonik.xml (modified) (5 diffs)

traduc/trunk/slony/addthings.xml

@@ -1 +1 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<!-- DerniÚre modification
-22 février 2008
-damien clochard <damien@dalibo.info>
+$Date$
+$Author$
-     révision $Revision$ -->
-
@@ -245 +245 @@
-
-<note><para> In &slony1; version 2.0, <xref linkend=
-
-
+/
+/
-<command>DROP SCHEMA "_ClusterName" CASCADE;</command>.  </para>
-</note></listitem>

traduc/trunk/slony/adminscripts.xml

@@ -639 +639 @@
-<subtitle> Apache-Style profiles for FreeBSD <filename>ports/databases/slony/*</filename> </subtitle>
-
-
+
+
+
-script that might be used to start up &lslon; instances at the time of
-system startup.  It is designed to interact with the FreeBSD Ports
-system.</para>
+
+</sect2>
+
+
+<sect2 id="duplicate-node"> <title> <filename> duplicate-node.sh </filename> </title>
+<indexterm><primary> duplicating nodes </primary> </indexterm>
+<para> In the <filename>tools</filename> area,
+<filename>duplicate-node.sh</filename> is a script that may be used to
+help create a new node that duplicates one of the ones in the
+cluster. </para>
+
+<para> The script expects the following parameters: </para>
+<itemizedlist>
+<listitem><para> Cluster name </para> </listitem>
+<listitem><para> New node number </para> </listitem>
+<listitem><para> Origin node </para> </listitem>
+<listitem><para> Node being duplicated </para> </listitem>
+<listitem><para> New node </para> </listitem>
+</itemizedlist>
+
+<para> For each of the nodes specified, the script offers flags to
+specify <function>libpq</function>-style parameters for
+<envar>PGHOST</envar>, <envar>PGPORT</envar>,
+<envar>PGDATABASE</envar>, and <envar>PGUSER</envar>; it is expected
+that <filename>.pgpass</filename> will be used for storage of
+passwords, as is generally considered best practice. Those values may
+inherit from the <function>libpq</function> environment variables, if
+not set, which is useful when using this for testing.  When
+<quote>used in anger,</quote> however, it is likely that nearly all of
+the 14 available parameters should be used. </para>
+
+<para> The script prepares files, normally in
+<filename>/tmp</filename>, and will report the name of the directory
+that it creates that contain SQL and &lslonik; scripts to set up the
+new node. </para>
+
+<itemizedlist>
+<listitem><para> <filename> schema.sql </filename> </para> 
+<para> This is drawn from the origin node, and contains the <quote>pristine</quote> database schema that must be applied first.</listitem>
+<listitem><para> <filename> slonik.preamble </filename> </para> 
+
+<para> This <quote>preamble</quote> is used by the subsequent set of slonik scripts. </para> </listitem>
+<listitem><para> <filename> step1-storenode.slonik </filename> </para> 
+<para> A &lslonik; script to set up the new node. </para> </listitem>
+<listitem><para> <filename> step2-storepath.slonik </filename> </para> 
+<para> A &lslonik; script to set up path communications between the provider node and the new node. </para> </listitem>
+<listitem><para> <filename> step3-subscribe-sets.slonik </filename> </para> 
+<para> A &lslonik; script to request subscriptions for all replications sets.</para> </listitem>
+</itemizedlist>
+
+<para> For testing purposes, this is sufficient to get a new node working.  The configuration may not necessarily reflect what is desired as a final state:</para>
+
+<itemizedlist>
+<listitem><para> Additional communications paths may be desirable in order to have redundancy. </para> </listitem>
+<listitem><para> It is assumed, in the generated scripts, that the new node should support forwarding; that may not be true. </para> </listitem>
+<listitem><para> It may be desirable later, after the subscription process is complete, to revise subscriptions. </para> </listitem>
+</itemizedlist>
-
-</sect2>

traduc/trunk/slony/bestpractices.xml

@@ -149 +149 @@
-</listitem>
-
+<listitem><para> If you are using the autovacuum process in recent
+versions of &postgres;, you may wish to leave &slony1; tables out, as
+&slony1; is a bit more intelligent about vacuuming when it is expected
+to be conspicuously useful (<emphasis>e.g.</emphasis> - immediately
+after purging old data) to do so than autovacuum can be. </para>
+
+<para> See <xref linkend="maintenance-autovac"/> for more
+details. </para> </listitem>
+
+
-<listitem> <para> Running all of the &lslon; daemons on a central
-server for each network has proven preferable. </para>
@@ -230 +240 @@
-unique index, which means that &slony1; has introduced a new failure
-mode for your application.</para>
+
+
+<warning><para> In version 2 of &slony1;, <xref
+linkend="stmttableaddkey"/> is no longer supported.  You
+<emphasis>must</emphasis> have either a true primary key or a
+candidate primary key.  </para></warning>
-</listitem>
-
@@ -604 +620 @@
-the exact form that the index setup should take. </para> 
-
-, there is a process that runs automatically to add
-
-
+ and later versions, there is a process that runs
+
+should be the optimal 
-</listitem>
-
@@ -621 +637 @@
-poorly. </para> </listitem>
-
-
+ls
-linkend="slon-config-sync-interval"/> on the origin's <xref
-linkend="slon"/> so that <command>SYNC</command> events are generated

traduc/trunk/slony/defineset.xml

@@ -75 +75 @@
-key, as it infers the namespace from the table.</para></listitem>
-
+
-<listitem><para> If the table hasn't even got a candidate primary key,
-
-
-
-
-
-
+
+
+
+
+
+
+
+
+
-
-</itemizedlist>
@@ -123 +127 @@
-that will shorten the length of each of the transactions, lessening
-the degree of the <quote>injury</quote> to performance.</para>
+
+<para> Another issue comes up particularly frequently when replicating
+across a WAN; sometimes the network connection is a little bit
+unstable, such that there is a risk that a connection held open for
+several hours will lead to <command>CONNECTION TIMEOUT.</command> If
+that happens when 95% done copying a 50-table replication set
+consisting of 250GB of data, that could ruin your whole day.  If the
+tables were, instead, associated with separate replication sets, that
+failure at the 95% point might only interrupt, temporarily, the
+copying of <emphasis>one</emphasis> of those tables.  </para>
-
-<para> These <quote>negative effects</quote> tend to emerge when the

traduc/trunk/slony/failover.xml

@@ -51 +51 @@
-
-<listitem><para> At the time of this writing switchover to another
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
-
-<listitem><para> A small <xref linkend="slonik"/> script executes the

traduc/trunk/slony/faq.xml

@@ -238 +238 @@
-</qandaentry>
-
+<qandaentry>
+<question> <para> Problem building on Fedora/x86-64 </para>
+
+<para> When trying to configure &slony1; on a Fedora x86-64 system,
+where <application>yum</application> was used to install the package
+<filename>postgresql-libs.x86_64</filename>, the following complaint
+comes up:
+
+<screen>
+configure: error: Your version of libpq doesn't have PQunescapeBytea
+ this means that your version of PostgreSQL is lower than 7.3
+ and thus not supported by Slony-I.
+</screen></para>
+
+<para> This happened with &postgres; 8.2.5, which is certainly rather
+newer than 7.3. </para>
+</question>
+
+<answer> <para> <application>configure</application> is looking for
+that symbol by compiling a little program that calls for it, and
+checking if the compile succeeds.  On the <command>gcc</command>
+command line it uses <command>-lpq</command> to search for the
+library. </para>
+
+<para> Unfortunately, that package is missing a symlink, from
+<filename>/usr/lib64/libpq.so</filename> to
+<filename>libpq.so.5.0</filename>; that is why it fails to link to
+libpq.  The <emphasis>true</emphasis> problem is that the compiler failed to
+find a library to link to, not that libpq lacked the function call.
+</para>
+
+<para> Eventually, this should be addressed by those that manage the
+<filename>postgresql-libs.x86_64</filename> package. </para>
+</answer>
+
+<answer> <para> Note that this same symptom can be the indication of
+similar classes of system configuration problems.  Bad symlinks, bad
+permissions, bad behaviour on the part of your C compiler, all may
+potentially lead to this same error message. </para> 
+
+<para> Thus, if you see this error, you need to look in the log file
+that is generated, <filename>config.log</filename>.  Search down to
+near the end, and see what the <emphasis>actual</emphasis> complaint
+was.  That will be helpful in tracking down the true root cause of the
+problem.</para>
+</answer>
+
+</qandaentry>
+
-</qandadiv>
-
@@ -421 +470 @@
-could also announce an admin to take a look...  </para> </answer>
-
-
-
-
+
-
-</qandaentry>
@@ -1336 +1383 @@
-</answer> </qandaentry>
-
+<qandaentry>
+
+<question><para> I'm noticing in the logs that a &lslon; is frequently
+switching in and out of <quote>polling</quote> mode as it is
+frequently reporting <quote>LISTEN - switch from polling mode to use
+LISTEN</quote> and <quote>UNLISTEN - switch into polling
+mode</quote>. </para> </question>
+
+<answer><para> The thresholds for switching between these modes are
+controlled by the configuration parameters <xref
+linkend="slon-config-sync-interval"> and <xref
+linkend="slon-config-sync-interval-timeout">; if the timeout value
+(which defaults to 10000, implying 10s) is kept low, that makes it
+easy for the &lslon; to decide to return to <quote>listening</quote>
+mode.  You may want to increase the value of the timeout
+parameter. </para>
+</answer>
+</qandaentry>
+
+
-</qandadiv>
-<qandadiv id="faqbugs"> <title> &slony1; FAQ: &slony1; Bugs in Elder Versions </title>

traduc/trunk/slony/filelist.xml

@@ -49 +49 @@
-<!ENTITY slonyupgrade       SYSTEM "slonyupgrade.xml">
-<!ENTITY releasechecklist   SYSTEM "releasechecklist.xml">
-
+
+
+
-
-<!-- back matter -->

traduc/trunk/slony/firstdb.xml

@@ -100 +100 @@
-</programlisting>
-
+<para> One of the tables created by
+<application>pgbench</application>, <envar>history</envar>, does not
+have a primary key.  In earlier versions of &slony1;, a &lslonik;
+command called <xref linkend="stmttableaddkey"/> could be used to
+introduce one.  This caused a number of problems, and so this feature
+has been removed in version 2 of &slony1;.  It now
+<emphasis>requires</emphasis> that there is a suitable candidate
+primary key. </para>
+
+<para> The following SQL requests will establish a proper primary key on this table: </para>
+
+<programlisting>
+psql -U $PGBENCH_USER -h $HOST1 -d $DBNAME1 -c "begin; alter table
+history add column id serial; update history set id =
+nextval('history_id_seq'); alter table history add primary key(id);
+commit"
+</programlisting>
+
-<para>Because &slony1; depends on the databases having the pl/pgSQL
-procedural language installed, we better install it now.  It is
@@ -235 +253 @@
-        set add table (set id=1, origin=1, id=2, fully qualified name = 'public.branches', comment='branches table');
-        set add table (set id=1, origin=1, id=3, fully qualified name = 'public.tellers', comment='tellers table');
-, key = serial
+
-
-        #--

traduc/trunk/slony/installation.xml

@@ -231 +231 @@
-indicates that there is intent to address the issue by bumping up the
-value of NAMELEN in some future release of Red Hat Enterprise Linux,
-5
+8
-issue addressed somewhat sooner. </para>
-
@@ -272 +272 @@
-installing any RPM.</para>
-
-
+engine-
-
-<para>If you want to upgrade the previous version, just use 
@@ -283 +283 @@
-are installed in <filename>/usr/lib/pgsql</filename>, and finally the
-docs are installed in
-
+-engine
-
-</sect2>

traduc/trunk/slony/legal.xml

@@ -6 +6 @@
-
-<copyright>
-6
+7
- <holder>The PostgreSQL Global Development Group</holder>
-</copyright>
@@ -14 +14 @@
-
- <para>
-6
+7
-  by the PostgreSQL Global Development Group and is distributed under
-  the terms of the license of the University of California below.

traduc/trunk/slony/loganalysis.xml

@@ -31 +31 @@
-</screen></para></sect2>
-
+<sect2><title>INFO notices</title>
+
+<para> Events that take place that seem like they will generally be of
+interest are recorded at the INFO level, and, just as with CONFIG
+notices, are always listed. </para>
+
+</sect2>
+
-<sect2><title>DEBUG Notices</title>
-
-
-
-
+
+
+
+
+
+
+
+
+
+
-
-<variablelist>
@@ -182 +197 @@
-<para> This section lists numerous of the error messages found in
-&slony1;, along with a brief explanation of implications.  It is a
-well comprehensive list, l
-generally
+comprehensive list, only 
+almost always
-uninteresting.</para>
-
@@ -1035 +1050 @@
-<listitem><para><command>WARN: remoteWorkerThread_%d: event %d ignored - origin inactive</command></para> 
-
-6
+7
-of deactivating a node... </para>
-</listitem>

traduc/trunk/slony/logshipping.xml

@@ -275 +275 @@
-start transaction;
-
-5
+7
--- end of log archiving header
-</programlisting></para></listitem>
@@ -287 +287 @@
-start transaction;
-
-5
+7
--- end of log archiving header
-</programlisting></para>
@@ -349 +349 @@
-
-</sect2>
+
+<sect2><title> <application> find-triggers-to-deactivate.sh
+</application> </title>
+
+<indexterm><primary> trigger deactivation </primary> </indexterm>
+
+<para> It was once pointed out (<ulink
+url="http://www.slony.info/bugzilla/show_bug.cgi?id=19"> Bugzilla bug
+#19</ulink>) that the dump of a schema may include triggers and rules
+that you may not wish to have running on the log shipped node.</para>
+
+<para> The tool <filename> tools/find-triggers-to-deactivate.sh
+</filename> was created to assist with this task.  It may be run
+against the node that is to be used as a schema source, and it will
+list the rules and triggers present on that node that may, in turn
+need to be deactivated.</para>
+
+<para> It includes <function>logtrigger</function> and <function>denyaccess</function>
+triggers which will may be left out of the extracted schema, but it is
+still worth the Gentle Administrator verifying that such triggers are
+kept out of the log shipped replica.</para>
+
+</sect2>
+
-<sect2> <title> <application>slony_logshipper </application> Tool </title>
-

traduc/trunk/slony/maintenance.xml

@@ -17 +17 @@
-<productname>Slony-I</productname> cluster's namespace, notably
-entries in <xref linkend="table.sl-log-1"/>, <xref
- (not yet used)
+
-linkend="table.sl-seqlog"/>.</para></listitem>
-
@@ -31 +31 @@
-vacuuming of these tables.  Unfortunately, it has been quite possible
-for <application>pg_autovacuum</application> to not vacuum quite
-probably want
+may prefer
-Vacuuming &pglistener; <quote>too often</quote> isn't nearly as
-hazardous as not vacuuming it frequently enough.</para>
@@ -63 +63 @@
-</itemizedlist>
-</para>
+
+
+<sect2 id="maintenance-autovac"> <title> Interaction with &postgres;
+autovacuum </title>
+
+<indexterm><primary>autovacuum interaction</primary></indexterm>
+
+<para> Recent versions of &postgres; support an
+<quote>autovacuum</quote> process which notices when tables are
+modified, thereby creating dead tuples, and vacuums those tables,
+<quote>on demand.</quote> It has been observed that this can interact
+somewhat negatively with &slony1;'s own vacuuming policies on its own
+tables. </para>
+
+<para> &slony1; requests vacuums on its tables immediately after
+completing transactions that are expected to clean out old data, which
+may be expected to be the ideal time to do so.  It appears as though
+autovacuum may notice the changes a bit earlier, and attempts
+vacuuming when transactions are not complete, rendering the work
+pretty useless.  It seems preferable to configure autovacuum to avoid
+vacuum &slony1;-managed configuration tables. </para>
+
+<para> The following query (change the cluster name to match your
+local configuration) will identify the tables that autovacuum should
+be configured not to process: </para>
+
+<programlisting>
+mycluster=# select oid, relname from pg_class where relnamespace = (select oid from pg_namespace where nspname = '_' || 'MyCluster') and relhasindex;
+  oid  |   relname    
+-------+--------------
+ 17946 | sl_nodelock
+ 17963 | sl_setsync
+ 17994 | sl_trigger
+ 17980 | sl_table
+ 18003 | sl_sequence
+ 17937 | sl_node
+ 18034 | sl_listen
+ 18017 | sl_path
+ 18048 | sl_subscribe
+ 17951 | sl_set
+ 18062 | sl_event
+ 18069 | sl_confirm
+ 18074 | sl_seqlog
+ 18078 | sl_log_1
+ 18085 | sl_log_2
+(15 rows)
+</programlisting>
+
+<para> The following query will populate
+<envar>pg_catalog.pg_autovacuum</envar> with suitable configuration
+information: <command> insert into pg_catalog.pg_autovacuum (vacrelid,
+enabled) select oid, 'f' from pg_catalog.pg_class where relnamespace =
+(select oid from pg_namespace where nspname = '_' || 'MyCluster') and
+relhasindex; </command> </para>
+</sect2>
-
-<sect2><title> Watchdogs: Keeping Slons Running</title>
@@ -94 +149 @@
-<sect2 id="gensync"><title>Parallel to Watchdog: generate_syncs.sh</title>
-
+<indexterm><primary>generate SYNCs</primary></indexterm>
+
-<para>A new script for &slony1; 1.1 is
-<application>generate_syncs.sh</application>, which addresses the following kind of
@@ -224 +281 @@
-<sect2><title> Other Replication Tests </title>
-
+<indexterm><primary>testing replication</primary></indexterm>  
+  
-<para> The methodology of the previous section is designed with a view
-to minimizing the cost of submitting replication test queries; on a
@@ -292 +351 @@
-</para>
-</sect2>
+
+<sect2><title>mkservice </title>
+<indexterm><primary>mkservice for BSD </primary></indexterm>
+
+<sect3><title>slon-mkservice.sh</title>
+
+<para> Create a slon service directory for use with svscan from
+daemontools.  This uses multilog in a pretty basic way, which seems to
+be standard for daemontools / multilog setups. If you want clever
+logging, see logrep below. Currently this script has very limited
+error handling capabilities.</para>
+
+<para> For non-interactive use, set the following environment
+variables.  <envar>BASEDIR</envar> <envar>SYSUSR</envar>
+<envar>PASSFILE</envar> <envar>DBUSER</envar> <envar>HOST</envar>
+<envar>PORT</envar> <envar>DATABASE</envar> <envar>CLUSTER</envar>
+<envar>SLON_BINARY</envar> If any of the above are not set, the script
+asks for configuration information interactively.</para>
+
+<itemizedlist>
+<listitem><para>
+<envar>BASEDIR</envar> where you want the service directory structure for the slon
+to be created. This should <emphasis>not</emphasis> be the <filename>/var/service</filename> directory.</para></listitem>
+<listitem><para>
+<envar>SYSUSR</envar> the unix user under which the slon (and multilog) process should run.</para></listitem>
+<listitem><para>
+<envar>PASSFILE</envar> location of the <filename>.pgpass</filename> file to be used. (default <filename>~sysusr/.pgpass</filename>)</para></listitem>
+<listitem><para>
+<envar>DBUSER</envar> the postgres user the slon should connect as (default slony)</para></listitem>
+<listitem><para>
+<envar>HOST</envar> what database server to connect to (default localhost)</para></listitem>
+<listitem><para>
+<envar>PORT</envar> what port to connect to (default 5432)</para></listitem>
+<listitem><para>
+<envar>DATABASE</envar> which database to connect to (default dbuser)</para></listitem>
+<listitem><para>
+<envar>CLUSTER</envar> the name of your Slony1 cluster? (default database)</para></listitem>
+<listitem><para>
+<envar>SLON_BINARY</envar> the full path name of the slon binary (default <command>which slon</command>)</para></listitem>
+</itemizedlist>
+
+<sect3><title>logrep-mkservice.sh</title>
+
+<para>This uses <command>tail -F</command> to pull data from log files allowing
+you to use multilog filters (by setting the CRITERIA) to create
+special purpose log files. The goal is to provide a way to monitor log
+files in near realtime for <quote>interesting</quote> data without either
+hacking up the initial log file or wasting CPU/IO by re-scanning the
+same log repeatedly.
+</para>
+
+<para>For non-interactive use, set the following environment
+variables.  <envar>BASEDIR</envar> <envar>SYSUSR</envar> <envar>SOURCE</envar>
+<envar>EXTENSION</envar> <envar>CRITERIA</envar> If any of the above are not set,
+the script asks for configuration information interactively.
+</para>
+
+<itemizedlist>
+<listitem><para>
+<envar>BASEDIR</envar> where you want the service directory structure for the logrep
+to be created. This should <emphasis>not</emphasis> be the <filename>/var/service</filename> directory.</para></listitem>
+<listitem><para><envar>SYSUSR</envar> unix user under which the service should run.</para></listitem>
+<listitem><para><envar>SOURCE</envar> name of the service with the log you want to follow.</para></listitem>
+<listitem><para><envar>EXTENSION</envar> a tag to differentiate this logrep from others using the same source.</para></listitem>
+<listitem><para><envar>CRITERIA</envar> the multilog filter you want to use.</para></listitem>
+</itemizedlist>
+
+<para> A trivial example of this would be to provide a log file of all slon
+ERROR messages which could be used to trigger a nagios alarm.
+<command>EXTENSION='ERRORS'</command>
+<command>CRITERIA="'-*' '+* * ERROR*'"</command>
+(Reset the monitor by rotating the log using <command>svc -a $svc_dir</command>)
+</para>
+
+<para> A more interesting application is a subscription progress log.
+<command>EXTENSION='COPY'</command>
+<command>CRITERIA="'-*' '+* * ERROR*' '+* * WARN*' '+* * CONFIG enableSubscription*' '+* * DEBUG2 remoteWorkerThread_* prepare to copy table*' '+* * DEBUG2 remoteWorkerThread_* all tables for set * found on subscriber*' '+* * DEBUG2 remoteWorkerThread_* copy*' '+* * DEBUG2 remoteWorkerThread_* Begin COPY of table*' '+* * DEBUG2 remoteWorkerThread_* * bytes copied for table*' '+* * DEBUG2 remoteWorkerThread_* * seconds to*' '+* * DEBUG2 remoteWorkerThread_* set last_value of sequence*' '+* * DEBUG2 remoteWorkerThread_* copy_set*'"</command>
+</para>
+
+<para>If you have a subscription log then it's easy to determine if a given
+slon is in the process of handling copies or other subscription activity.
+If the log isn't empty, and doesn't end with a 
+<command>"CONFIG enableSubscription: sub_set:1"</command>
+(or whatever set number you've subscribed) then the slon is currently in
+the middle of initial copies.</para>
+
+<para> If you happen to be monitoring the mtime of your primary slony logs to 
+determine if your slon has gone brain-dead, checking this is a good way
+to avoid mistakenly clobbering it in the middle of a subscribe. As a bonus,
+recall that since the the slons are running under svscan, you only need to
+kill it (via the svc interface) and let svscan start it up again laster.
+I've also found the COPY logs handy for following subscribe activity 
+interactively.</para>
+</sect3>
+
+</sect2>
-</sect1>

traduc/trunk/slony/monitoring.xml

@@ -100 +100 @@
-Options[db_replication_lagtime]: gauge,nopercent,growright
-</programlisting>
+
+
+<para> Alternatively, Ismail Yenigul points out how he managed to
+monitor slony using <application>MRTG</application> without installing
+<application>SNMPD</application>.</para>
+
+<para> Here is the mrtg configuration</para>
+
+<programlisting>
+Target[db_replication_lagtime]:`/bin/snmpReplicationLagTime.sh 2`
+MaxBytes[db_replication_lagtime]: 400000000
+Title[db_replication_lagtime]: db: replication lag time
+PageTop[db_replication_lagtime]: &lt;H1&gt;db: replication lag time&lt;/H1&gt;
+Options[db_replication_lagtime]: gauge,nopercent,growright
+</programlisting>
+
+<para> and here is the modified version of the script</para>
+
+<programlisting>
+# cat /bin/snmpReplicationLagTime.sh
+#!/bin/bash
+
+output=`/usr/bin/psql -U slony -h 192.168.1.1 -d endersysecm -qAt -c
+"select cast(extract(epoch from st_lag_time) as int8) FROM _mycluster.sl_status WHERE st_received = $1"`
+echo $output
+echo $output
+echo 
+echo
+# end of script#
+</programlisting>
+
+
+<note><para> MRTG expects four lines from the script, and since there
+are only two lines provided, the output must be padded to four
+lines. </para> </note>
+
-</sect2>
-
@@ -199 +235 @@
-<filename>tools</filename>, may be used to generate a cluster summary
-compatible with the popular <ulink url="http://www.mediawiki.org/">
-
+
+
+
+
+
+
+
-
-<para> The gentle user might use the script as follows: </para>
@@ -206 +248 @@
-~/logtail.en>         mvs login -d mywiki.example.info -u "Chris Browne" -p `cat ~/.wikipass` -w wiki/index.php                     
-Doing login with host: logtail and lang: en
-
+--categories=Slony-I 
-~/logtail.en> mvs commit -m "More sophisticated generated Slony-I cluster docs" Slony_replication.wiki
-Doing commit Slony_replication.wiki with host: logtail and lang: en

traduc/trunk/slony/releasechecklist.xml

@@ -58 +58 @@
-<filename>configure.ac</filename></para></listitem> 
-
-
+
+
+
-
-
+
+
+
-<listitem><para> Run <filename>tools/release_checklist.sh</filename> </para>
-
@@ -71 +75 @@
-<listitem><para>PACKAGE_VERSION=REL_1_1_2</para></listitem>
-
-
+-engine
-
-</itemizedlist>
@@ -101 +105 @@
-make all &amp;&amp; make clean</command> but that is a somewhat ugly approach.
-
-
+
+
+
+
+
+
-
-<listitem><para> Make sure that generated Makefiles and such from the
-previous step(s) are removed.</para>
-
-
-
+
+
+
+
+
+
+
+
-
-<listitem><para>Generate HTML tarball, and RTF/PDF, if

traduc/trunk/slony/schemadoc.xml

@@ -1 @@
-
-
-
-
-
+
+
+
+
+
+
-
-  <chapter id="schema"
@@ -10 +11 @@
-    <para></para>
-
-
-      <section id="table.sl-archive-counter"
-               xreflabel="sl_archive_counter">
-        <title id="table.sl-archive-counter-title">
-         Table:
-         
-         <structname>sl_archive_counter</structname>
-        </title>
- 
-
-        <para>
-          Table used to generate the log shipping archive number.
-
-        </para>
-
-
-        <para>
-          <variablelist>
-            <title>
-              Structure of <structname>sl_archive_counter</structname>
-            </title>
-
-
-            <varlistentry>
-              <term><structfield>ac_num</structfield></term>
-              <listitem><para>
-                <type>bigint</type>
-
-
-
-
-
-
-
-              </para>
-
-              <para>
-                Counter of SYNC ID used in log shipping as the archive number
-              </para>
-
-            </listitem>
-          </varlistentry>
-
-            <varlistentry>
-              <term><structfield>ac_timestamp</structfield></term>
-              <listitem><para>
-                <type>timestamp without time zone</type>
-
-
-
-
-
-
-
-              </para>
-
-              <para>
-                Time at which the archive log was generated on the subscriber
-              </para>
-
-            </listitem>
-          </varlistentry>
-
-        </variablelist>
-
-
-
-
-
-
-
-
-
-
-      </para>
-    </section>
-
-      <section id="table.sl-config-lock"
@@ -120 +45 @@
-
-
-              </para>
-
-              <pa