Mon Feb 25 07:31:27 PST 2008
- Previous message: [Slony1-commit] slony1-engine/src/slonik Makefile
- Next message: [Slony1-commit] slony1-engine/doc/adminguide 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
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Update of /home/cvsd/slony1/slony1-engine/doc/adminguide In directory main.slony.info:/tmp/cvs-serv1990 Modified Files: slonconf.sgml Log Message: Elaborate on SYNC parameters to show a bit better how they interact with one another Index: slonconf.sgml =================================================================== RCS file: /home/cvsd/slony1/slony1-engine/doc/adminguide/slonconf.sgml,v retrieving revision 1.19 retrieving revision 1.20 diff -C2 -d -r1.19 -r1.20 *** slonconf.sgml 2 Jan 2008 19:12:42 -0000 1.19 --- slonconf.sgml 25 Feb 2008 15:31:25 -0000 1.20 *************** *** 272,275 **** --- 272,282 ---- Range: [10-60000], default 100 </para> + + <para> This parameter is primarily of concern on nodes that + originate replication sets. On a non-origin node, there + will never be update activity that would induce a SYNC; + instead, the timeout value described below will induce a + SYNC every so often <emphasis>despite absence of changes to + replicate.</emphasis> </para> </listitem> </varlistentry> *************** *** 298,301 **** --- 305,343 ---- default 1000 </para> + + <para> This parameter is likely to be primarily of concern on + nodes that originate replication sets, though it does affect + how often events are generated on other nodes.</para> + + <para> + On a non-origin node, there never is activity to cause a + SYNC to get generated; as a result, there will be a SYNC + generated every <envar>sync_interval_timeout</envar> + milliseconds. There are no subscribers looking for those + SYNCs, so these events do not lead to any replication + activity. They will, however, clutter sl_event up a little, + so it would be undesirable for this timeout value to be set + too terribly low. 120000ms represents 2 minutes, which is + not a terrible value. + </para> + + <para> The two values function together in varying ways: </para> + + <para> On an origin node, <envar>sync_interval</envar> is + the <emphasis>minimum</emphasis> time period that will be + covered by a SYNC, and during periods of heavy application + activity, it may be that a SYNC is being generated + every <envar>sync_interval</envar> milliseconds. </para> + + <para> On that same origin node, there may be quiet intervals, + when no replicatable changes are being submitted. A SYNC will + be induced, anyways, + every <envar>sync_interval_timeout</envar> + milliseconds. </para> + + <para> On a subscriber node that does not originate any sets, + only the <quote>timeout-induced</quote> SYNCs will + occur. </para> + </listitem> </varlistentry> *************** *** 307,322 **** </indexterm> <listitem> <para> ! 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,10000], default: ! 20 </para> </listitem> </varlistentry> --- 349,369 ---- </indexterm> <listitem> + <para> ! Maximum number of <command>SYNC</command> events that a ! subscriber node will 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 though you used ! <option>-g600</option>, the &lslon; will apply just the one ! that is available. As soon as a subscriber catches up, it ! will tend to apply each ! <command>SYNC</command> by itself, as a singleton, unless ! processing should fall behind for some reason. Range: ! [0,10000], default: 20 </para> + </listitem> </varlistentry>
- Previous message: [Slony1-commit] slony1-engine/src/slonik Makefile
- Next message: [Slony1-commit] slony1-engine/doc/adminguide 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
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Slony1-commit mailing list