SLON(1) Slony-I 2.2.4 Documentation SLON(1)NAMEslon - Slony-I daemon
SYNOPSISslon [ option ... ] [ clustername ] [ conninfo ]
DESCRIPTIONslon is the daemon application that ``runs'' Slony-I replication. A
slon instance must be run for each node in a Slony-I cluster.
OPTIONS-d log_level
The log_level specifies which levels of debugging messages slon
should display when logging its activity.
The nine levels of logging are:
· Fatal
· Error
· Warn
· Config
· Info
· Debug1
· Debug2
· Debug3
· Debug4
The first five non-debugging log levels (from Fatal to Info) are always
displayed in the logs. In early versions of Slony-I, the ``suggested''
log_level value was 2, which would list output at all levels down to
debugging level 2. In Slony-I version 2, it is recommended to set
log_level to 0; most of the consistently interesting log information is
generated at levels higher than that.
-s SYNC check interval
The sync_interval, measured in milliseconds, indicates how often
slon should check to see if a SYNC should be introduced.
Default is 2000 ms. The main loop in sync_Thread_main() sleeps
for intervals of sync_interval milliseconds between iterations.
Short sync check intervals keep the origin on a ``short leash'',
updating its subscribers more frequently. If you have repli‐
cated sequences that are frequently updated without there being
tables that are affected, this keeps there from being times when
only sequences are updated, and therefore no syncs take place
If the node is not an origin for any replication set, so no
updates are coming in, it is somewhat wasteful for this value to
be much less the sync_interval_timeout value.
-t SYNC interval timeout
At the end of each sync_interval_timeout timeout period, a SYNC
will be generated on the ``local'' node even if there has been
no replicable data updated that would have caused a SYNC to be
generated.
If application activity ceases, whether because the application
is shut down, or because human users have gone home and stopped
introducing updates, the slon(1) will iterate away, waking up
every sync_interval milliseconds, and, as no updates are being
made, no SYNC events would be generated. Without this timeout
parameter, no SYNC events would be generated, and it would
appear that replication was falling behind.
The sync_interval_timeout value will lead to eventually generat‐
ing a SYNC, even though there was no real replication work to be
done. The lower that this parameter is set, the more frequently
slon(1) will generate SYNC events when the application is not
generating replicable activity; this will have two effects:
· The system will do more replication work.
(Of course, since there is no application load on the data‐
base, and no data to replicate, this load will be very easy to
handle.
· Replication will appear to be kept more ``up to date.''
(Of course, since there is no replicable activity going on,
being ``more up to date'' is something of a mirage.)
Default is 10000 ms and maximum is 120000 ms. By default, you can
expect each node to ``report in'' with a SYNC every 10 seconds.
Note that SYNC events are also generated on subscriber nodes. Since
they are not actually generating any data to replicate to other nodes,
these SYNC events are of not terribly much value.
-g group size
This controls the maximum SYNC group size, sync_group_maxsize;
defaults to 6. Thus, if a particular node is behind by 200
SYNCs, it will try to group them together into groups of a maxi‐
mum size of sync_group_maxsize. This can be expected to reduce
transaction overhead due to having fewer transactions to COMMIT.
The default of 6 is probably suitable for small systems that can
devote only very limited bits of memory to slon. If you have
plenty of memory, it would be reasonable to increase this, as it
will increase the amount of work done in each transaction, and
will allow a subscriber that is behind by a lot to catch up more
quickly.
Slon processes usually stay pretty small; even with large value
for this option, slon would be expected to only grow to a few MB
in size.
The big advantage in increasing this parameter comes from cut‐
ting down on the number of transaction COMMITs; moving from 1 to
2 will provide considerable benefit, but the benefits will pro‐
gressively fall off once the transactions being processed get to
be reasonably large. There isn't likely to be a material dif‐
ference in performance between 80 and 90; at that point, whether
``bigger is better'' will depend on whether the bigger set of
SYNCs makes the LOG cursor behave badly due to consuming more
memory and requiring more time to sortt.
In Slony-I version 1.0, slon will always attempt to group SYNCs
together to this maximum, which won't be ideal if replication
has been somewhat destabilized by there being very large updates
(e.g. - a single transaction that updates hundreds of thousands
of rows) or by SYNCs being disrupted on an origin node with the
result that there are a few SYNCs that are very large. You
might run into the problem that grouping together some very
large SYNCs knocks over a slon process. When it picks up again,
it will try to process the same large grouped set of SYNCs, and
run into the same problem over and over until an administrator
interrupts this and changes the -g value to break this ``dead‐
lock.''
In Slony-I version 1.1 and later versions, the slon instead
adaptively ``ramps up'' from doing 1 SYNC at a time towards the
maximum group size. As a result, if there are a couple of SYNCs
that cause problems, the slon will (with any relevant watchdog
assistance) always be able to get to the point where it pro‐
cesses the troublesome SYNCs one by one, hopefully making opera‐
tor assistance unnecessary.
-o desired sync time
A ``maximum'' time planned for grouped SYNCs.
If replication is running behind, slon will gradually increase
the numbers of SYNCs grouped together, targeting that (based on
the time taken for the last group of SYNCs) they shouldn't take
more than the specified desired_sync_time value.
The default value for desired_sync_time is 60000ms, equal to one
minute.
That way, you can expect (or at least hope!) that you'll get a
COMMIT roughly once per minute.
It isn't totally predictable, as it is entirely possible for
someone to request a very large update, all as one transaction,
that can ``blow up'' the length of the resulting SYNC to be
nearly arbitrarily long. In such a case, the heuristic will
back off for the next group.
The overall effect is to improve Slony-I's ability to cope with
variations in traffic. By starting with 1 SYNC, and gradually
moving to more, even if there turn out to be variations large
enough to cause PostgreSQL backends to crash, Slony-I will back
off down to start with one sync at a time, if need be, so that
if it is at all possible for replication to progress, it will.
-c cleanup cycles
The value vac_frequency indicates how often to VACUUM in cleanup
cycles.
Set this to zero to disable slon-initiated vacuuming. If you are
using something like pg_autovacuum to initiate vacuums, you may
not need for slon to initiate vacuums itself. If you are not,
there are some tables Slony-I uses that collect a lot of dead
tuples that should be vacuumed frequently, notably pg_listener.
In Slony-I version 1.1, this changes a little; the cleanup
thread tracks, from iteration to iteration, the earliest trans‐
action ID still active in the system. If this doesn't change,
from one iteration to the next, then an old transaction is still
active, and therefore a VACUUM will do no good. The cleanup
thread instead merely does an ANALYZE on these tables to update
the statistics in pg_statistics.
-p PID filename
pid_file contains the filename in which the PID (process ID) of
the slon is stored.
This may make it easier to construct scripts to monitor multiple
slon processes running on a single host.
-f config file
File from which to read slon configuration.
This configuration is discussed further in Slon Run-time
Configuration. 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 pass‐
words), 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 con‐
nection info. Alternatively, you might create a configuration
file for each node.
-a archive directory
archive_dir indicates a directory in which to place a sequence
of SYNC archive files for use in log shipping mode.
-x command to run on log archive
command_on_logarchive indicates a command to be run each time a
SYNC file is successfully generated.
See more details on [XRef to SLON-CONFIG-COMMAND-ON-LOGARCHIVE].
-q quit based on SYNC provider
quit_sync_provider indicates which provider's worker thread
should be watched in order to terminate after a certain event.
This must be used in conjunction with the -r option below...
This allows you to have a slon stop replicating after a certain
point.
-r quit at event number
quit_sync_finalsync indicates the event number after which the
remote worker thread for the provider above should terminate.
This must be used in conjunction with the -q option above...
-l lag interval
lag_interval indicates an interval value such as
3 minutes or 4 hours or 2 days that indicates that this
node is to lag its providers by the specified interval of time.
This causes events to be ignored until they reach the age corre‐
sponding to the interval.
Warning:
There is a concommittant downside to this lag; events that
require all nodes to synchronize, as typically happens with
SLONIK FAILOVER(7) and SLONIK MOVE SET(7), will have to wait for
this lagging node.
That might not be ideal behaviour at failover time, or at the
time when you want to run SLONIK EXECUTE SCRIPT(7).
EXIT STATUSslon returns 0 to the shell if it finished normally. It returns via
exit(-1) (which will likely provide a return value of either 127 or
255, depending on your system) if it encounters any fatal error.
Application 18 January 2015 SLON(1)
