Mon Apr 11 16:58:29 PDT 2005
- Previous message: [Slony1-commit] By xfade: This patch adds two new functions: - slon_quote_brute is used
- Next message: [Slony1-commit] By cbbrowne: Fix typos
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Log Message:
-----------
More docs for log shipping and on the slon options
Modified Files:
--------------
slony1-engine/doc/adminguide:
logshipping.sgml (r1.5 -> r1.6)
slon.sgml (r1.14 -> r1.15)
slonconf.sgml (r1.3 -> r1.4)
-------------- next part --------------
Index: slonconf.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slonconf.sgml,v
retrieving revision 1.3
retrieving revision 1.4
diff -Ldoc/adminguide/slonconf.sgml -Ldoc/adminguide/slonconf.sgml -u -w -r1.3 -r1.4
--- doc/adminguide/slonconf.sgml
+++ doc/adminguide/slonconf.sgml
@@ -6,10 +6,11 @@
</indexterm>
<para>
- There are several configuration parameters that affect the behavior of the
- replication system. In this section, we describe how to set the slon daemon's
- configuration parameters; the following subsections discuss each parameter
- in detail.
+ There are several configuration parameters that affect the
+ behavior of the replication system. In this section, we describe
+ how to set the <application>slon</application> daemon's
+ configuration parameters; the following subsections discuss each
+ parameter in detail.
</para>
<para>
@@ -30,8 +31,8 @@
</para>
<para>
- Some options may be set through the Command-line, these options override any
- conflicting settings in the conf file.
+ Some options may be set through the Command-line, these options
+ override any conflicting settings in the configuration file.
</para>
@@ -58,9 +59,10 @@
<primary><varname>syslog_facility</varname> configuration parameter</primary>
</indexterm>
<listitem>
- <para>Sets the syslog "facility" to be used when syslog enabled. Valid
- values are LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7.
- The default is LOCAL0.
+ <para>Sets the syslog <quote>facility</quote> to be used when
+ syslog enabled. Valid values are LOCAL0, LOCAL1, LOCAL2,
+ LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. The default is
+ LOCAL0.
</para>
</listitem>
</varlistentry>
@@ -95,7 +97,7 @@
</indexterm>
<listitem>
<para>Determins, if you would like the pid of the (parent) slon process to
- apear in each log line entry.
+ appear in each log line entry.
</para>
</listitem>
</varlistentry>
@@ -106,8 +108,8 @@
<primary><varname>log_timestamp</varname> configuration parameter</primary>
</indexterm>
<listitem>
- <para>Determins, if you would like the timestamp of the event being logged to
- apear in each log line entry.
+ <para>Determines if you would like the timestamp of the event being logged to
+ appear in each log line entry.
</para>
</listitem>
</varlistentry>
@@ -118,8 +120,9 @@
<primary><varname>log_timestamp_format</varname> configuration parameter</primary>
</indexterm>
<listitem>
- <para>A strftime()-conformant format string for use if log_timestamp is enabled.
- The default is '%Y-%m-%d %H:%M:%S %Z'
+ <para>A <function>strftime()</function>-conformant format
+ string for use if <envar>log_timestamp</envar> is enabled. The
+ default is <quote>%Y-%m-%d %H:%M:%S %Z</quote>
</para>
</listitem>
</varlistentry>
@@ -130,8 +133,9 @@
<primary><varname>pid_file</varname> configuration parameter</primary>
</indexterm>
<listitem>
- <para>Location and filename you would like for the pid file. The default
- is not defined in which case no pid file is written.
+ <para>Location and filename you would like for a file
+ containing the Process ID of the slon process. The default is
+ not defined in which case no file is written.
</para>
</listitem>
</varlistentry>
@@ -142,40 +146,43 @@
<title>Connection settings</title>
<variablelist>
<varlistentry id="slon-config-connection-cluster-name" xreflabel="slon_conf_cluster_name">
- <term><varname>cluster_name (<type>string</type>)</term>
+ <term><varname>cluster_name</varname> (<type>string</type>) </term>
<indexterm>
<primary><varname>cluster_name</varname> configuration parameter</primary>
</indexterm>
<listitem>
<para>
- Set the cluster name that this instance of slon is running against.
- The default is to read it off the command line.
+ Set the cluster name that this instance of
+ <application>slon</application> is running against. The
+ default is to read it off the command line.
</para>
</listitem>
</varlistentry>
<varlistentry id="slon-config-connection-conn-info" xreflabel="slon_conf_conn_info">
- <term><varname>conn_info (<type>string</type>)</term>
+ <term><varname>conn_info</varname> (<type>string</type>)</term>
<indexterm>
<primary><varname>conn_info</varname> configuration parameter</primary>
</indexterm>
<listitem>
<para>
- Set slon's connection info, default is to read it off the command line.
+ Set <application>slon</application>'s connection info;
+ default is to read it off the command line.
</para>
</listitem>
</varlistentry>
<varlistentry id="slon-config-sql-on-connection" xreflabel="slon_conf_sql_on_connection">
- <term><varname>sql_on_connection (<type>string</type>)</term>
+ <term><varname>sql_on_connection</varname> (<type>string</type>)</term>
<indexterm>
<primary><varname>sql_on_connection</varname> configuration parameter</primary>
</indexterm>
<listitem>
<para>
- Execute this SQL on each node at slon connect time. Useful to set logging
- levels, or to tune the planner/memory settings. You can specify multiple
- statements by seperating them with a ;
+ Execute this SQL on each node at
+ <application>slon</application> connect time. Useful to set
+ logging levels, or to tune the planner/memory settings. You
+ can specify multiple statements by separating them with a ;
</para>
</listitem>
</varlistentry>
@@ -186,7 +193,7 @@
<title>Event Tuning</title>
<variablelist>
<varlistentry id="slon-config-sync-interval" xreflabel="slon_conf_sync_interval">
- <term><varname>sync_interval (<type>integer</type>)</term>
+ <term><varname>sync_interval</varname> (<type>integer</type>)</term>
<indexterm>
<primary><varname>sync_interval</varname> configuration parameter</primary>
</indexterm>
@@ -198,68 +205,81 @@
</varlistentry>
<varlistentry id="slon-config-sync-interval-timeout" xreflabel="slon_conf_sync_interval_timeout">
- <term><varname>sync_interval_timeout (<type>integer</type>)</term>
+ <term><varname>sync_interval_timeout</varname> (<type>integer</type>)</term>
<indexterm>
<primary><varname>sync_interval_timeout</varname> configuration parameter</primary>
</indexterm>
<listitem>
<para>
- Maximum amount of time in milliseconds before issuing a SYNC event,
- This prevents a possible race condition in which the action sequence
- is bumped by the trigger while inserting the log row, which makes
- this bump is immediately visible to the sync thread, but
- the resulting log rows are not visible yet. If the sync is picked
- up by the subscriber, processed and finished before the transaction
- commits, this transaction's changes will not be replicated until the
- next SYNC. But if all application activity suddenly stops,
- there will be no more sequence bumps, so the high frequent -s check
- won't detect that. Thus, the need for sync_interval_timeout.
- Range: [0-120000], default 1000
+ Maximum amount of time in milliseconds before issuing a
+ <command>SYNC</command> event, This prevents a possible race
+ condition in which the action sequence is bumped by the
+ trigger while inserting the log row, which makes this bump
+ is immediately visible to the sync thread, but the resulting
+ log rows are not visible yet. If the
+ <command>SYNC</command> is picked up by the subscriber,
+ processed and finished before the transaction commits, this
+ transaction's changes will not be replicated until the next
+ <command>SYNC</command>. But if all application activity
+ suddenly stops, there will be no more sequence bumps, so the
+ high frequent <option>-s</option> check won't detect that.
+ Thus, the need for
+ <envar>sync_interval_timeout</envar>. Range: [0-120000],
+ default 1000
</para>
</listitem>
</varlistentry>
<varlistentry id="slon-config-sync-group-maxsize" xreflabel="slon_conf_sync_group_maxsize">
- <term><varname>sync_group_maxsize (<type>integer</type>)</term>
+ <term><varname>sync_group_maxsize</varname> (<type>integer</type>)</term>
<indexterm>
<primary><varname>sync_group_maxsize</varname> configuration parameter</primary>
</indexterm>
<listitem>
<para>
- Maximum number of SYNC events to group together when/if a subscriber
- falls behind. SYNCs are batched only if there are that many available
- and if they are contiguous. Every other event type in between leads to
- a smaller batch. And if there is only one SYNC available, even -g60
- will apply just that one. As soon as a subscriber catches up, it will
- apply every single SYNC by itself.
- Range: [0,100], default: 6
+ Maximum number of <command>SYNC</command> events to group
+ together when/if a subscriber falls behind.
+ <command>SYNC</command>s are batched only if there are that
+ many available and if they are contiguous. Every other event
+ type in between leads to a smaller batch. And if there is
+ only one <command>SYNC</command> available, even
+ <option>-g60</option> will apply just that one. As soon as a
+ subscriber catches up, it will apply every single
+ <command>SYNC</command> by itself. Range: [0,100], default:
+ 6
</para>
</listitem>
</varlistentry>
<varlistentry id="slon-config-vac-frequency" xreflabel="slon_conf_vac_frequency">
- <term><varname>vac_frequency (<type>integer</type>)</term>
+ <term><varname>vac_frequency</varname> (<type>integer</type>)</term>
<indexterm>
<primary><varname>vac_frequency</varname> configuration parameter</primary>
</indexterm>
<listitem>
<para>
- Sets how many cleanup cycles to run before a vacuum is done. 0 disables the builtin vacuum,
- intended to be used with the <application>pg_autovacuum</application> daemon.
- Range: [0,100], default: 3
+ Sets how many cleanup cycles to run before a vacuum is done.
+ 0 disables the builtin vacuum, intended to be used with the
+ <application>pg_autovacuum</application> daemon. Range:
+ [0,100], default: 3
</para>
</listitem>
</varlistentry>
<varlistentry id="slon-config-desired-sync-time" xreflabel="desired_sync_time">
- <term><varname>desired_sync_time (<type>integer</type>)</term>
+ <term><varname>desired_sync_time</varname> (<type>integer</type>)</term>
<indexterm>
<primary><varname>desired_sync_time</varname> configuration parameter</primary>
</indexterm>
<listitem>
- <para>Maximum time planned for grouped SYNCs. If replication is behind,
- <application>slon</application> will try to increase numbers of syncs
- done targetting that they should take this quantity of time to process.
- This is in ms Range [10000,600000], default 60000.
+ <para>Maximum time planned for grouped
+ <command>SYNC</command>s. If replication is behind,
+ <application>slon</application> will try to increase numbers
+ of syncs done targetting that they should take this quantity
+ of time to process. This is in Range [10000,600000] ms,
+ default 60000. </para>
+
+ <para>If the value is left alone, it reverts to 0, in which
+ case this logic will be ignored.
</para>
</listitem>
</varlistentry>
Index: slon.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/slon.sgml,v
retrieving revision 1.14
retrieving revision 1.15
diff -Ldoc/adminguide/slon.sgml -Ldoc/adminguide/slon.sgml -u -w -r1.14 -r1.15
--- doc/adminguide/slon.sgml
+++ doc/adminguide/slon.sgml
@@ -73,7 +73,7 @@
indicates how often <application>slon</application> should check
to see if a <command>SYNC</command> should be introduced.
Default is 10000 ms. The main loop in
- <function>sync_Thread_main() sleeps for intervals of
+ <function>sync_Thread_main()</function> sleeps for intervals of
<envar>sync_interval</envar> milliseconds between iterations.
</para>
@@ -242,7 +242,7 @@
itself. If you are not, there are some tables
<productname>Slony-I</productname> uses that collect a
<emphasis>lot</emphasis> of dead tuples that should be vacuumed
- frequently.
+ frequently, notably <envar>pg_listener</envar>.
</para>
<para> In &slony1; version 1.1, this changes a little; the
@@ -281,7 +281,15 @@
</para>
<para> This configuration is discussed further in <xref
- linkend="runtime-config">.</para>
+ linkend="runtime-config">. If there are to be a complex set of
+ configuration parameters, or if there are parameters you do not
+ wish to be visible in the process environment variables (such as
+ passwords), it may be convenient to draw many or all parameters
+ from a configuration file. You might either put common
+ parameters for all slon processes in a commonly-used
+ configuration file, allowing the command line to specify little
+ other than the connection info. Alternatively, you might create
+ a configuration file for each node.</para>
</listitem>
</varlistentry>
Index: logshipping.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/logshipping.sgml,v
retrieving revision 1.5
retrieving revision 1.6
diff -Ldoc/adminguide/logshipping.sgml -Ldoc/adminguide/logshipping.sgml -u -w -r1.5 -r1.6
--- doc/adminguide/logshipping.sgml
+++ doc/adminguide/logshipping.sgml
@@ -62,31 +62,20 @@
generate them by adding the <option>-a</option> option.
</answer>
</qandaentry>
-
<qandaentry>
+<question> <para> What takes place when a failover/MOVE SET takes place?</para></question>
-<question> <para> What takes place when a failover/MOVE SET takes
-place?</para></question>
-
-<answer><para> Nothing too special. So long as the archiving node
-remains a subscriber, it will continue to generate
-logs.</para></answer>
+<answer><para> Nothing special. So long as the archiving node remains
+a subscriber, it will continue to generate logs.</para></answer>
</qandaentry>
<qandaentry>
<question> <para> What if we run out of <quote>spool space</quote>?
</para></question>
-<answer><para> The node will stop accepting <command>SYNC</command>s
-until this problem is alleviated. The database being subscribed to
-will also fall behind.
-
-<para> There will be the further side-effect on the cluster that
-confirmations won't be able to propagate (because the node has not
-processed the updates), which will cause <xref
-linkend="table.sl-log-1"> and <xref linkend="table.sl-seqlog"> to
-grow.
-
+<answer><para> The node will stop accepting SYNCs until this problem
+is alleviated. The database being subscribed to will also fall
+behind. </para></answer>
</qandaentry>
<qandaentry>
@@ -118,14 +107,28 @@
<quote>sniffing</quote> the data applied at a particular subscriber
node. As a result, you must have at least one <quote>regular</quote>
node; you cannot have a cluster that consists solely of an origin and
-a set of <quote>log shipping nodes.</quote>. </para>
+a set of <quote>log shipping nodes.</quote>. </para></answer>
+
+<answer><para> The <quote>log shipping node</quote> tracks the
+entirety of the traffic going to a subscriber. You cannot separate
+things out if there are multiple replication sets. </para></answer>
+
+<answer><para> The <quote>log shipping node</quote> presently tracks
+only SYNC events. This should be sufficient to cope with
+<emphasis>some</emphasis> changes in cluster configuration, but not
+others. </para>
<para> Log shipping does <emphasis>not</emphasis> process certain
additional events, with the implication that the introduction of any
of the following events can invalidate the relationship between the
SYNCs and the dump created using
-<application>slony1_dump.sh</application> so that you may need to
-rerun <application>slony1_dump.sh</application>.
+<application>slony1_dump.sh</application> so that you'll likely need
+to rerun <application>slony1_dump.sh</application>:
+
+<itemizedlist>
+<listitem><para><command> SUBSCRIBE_SET </command>
+
+</itemizedlist>
<para> A number of event types <emphasis> are </emphasis> handled in
such a way that log shipping copes with them:
@@ -137,8 +140,6 @@
<listitem><para><command> DDL_SCRIPT</command> is handled.
-<listitem><para><command> SUBSCRIBE_SET </command>
-
<listitem><para><command> UNSUBSCRIBE_SET </command>
<para> This event, much like <command>SUBSCRIBE_SET</command> is not
@@ -188,7 +189,7 @@
&slony1; configuration to the node, and promote it into being a new
node. Again, a Simple Matter Of Programming (that might not
necessarily be all that simple)... </para></answer>
-
+</qandaentry>
</qandaset>
<sect2><title> Usage Hints </title>
@@ -225,11 +226,10 @@
trying the next file.
<listitem><para> If the <function> setsyncTracking_offline()
-</function> call succeeds, then you have the right next
-<command>SYNC</command> file, and should apply it. You should
-probably <command>ROLLBACK</command> the transaction, and then use
-<application>psql</application> to apply the entire file full of
-updates.
+</function> call succeeds, then you have the right next SYNC file, and
+should apply it. You should probably <command>ROLLBACK</command> the
+transaction, and then use <application>psql</application> to apply the
+entire file full of updates.
</itemizedlist>
@@ -245,6 +245,7 @@
--------------------------------------------------------------------
</programlisting>
+</itemizedlist>
</sect2>
</sect1>
<!-- Keep this comment at the end of the file
- Previous message: [Slony1-commit] By xfade: This patch adds two new functions: - slon_quote_brute is used
- Next message: [Slony1-commit] By cbbrowne: Fix typos
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-commit mailing list