Provided by: slony1-2-bin_2.2.11-6_amd64 
NAME
slon - Slony-I daemon
SYNOPSIS
slon [option]... [clustername] [conninfo]
DESCRIPTION
slon 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 consistent‐
ly 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 in‐
tervals of sync_interval milliseconds between iterations.
Short sync check intervals keep the origin on a ‘short leash’, updating its subscribers more fre‐
quently. If you have replicated sequences that are frequently updated without there being tables
that are affected, this keeps there from being times when only sequences are updated, and there‐
fore 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 gener‐
ated.
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 gen‐
erated. 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 generating 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 database, 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 20. Thus, if a particu‐
lar node is behind by 200 SYNCs, it will try to group them together into groups of a maximum size
of sync_group_maxsize. This can be expected to reduce transaction overhead due to having fewer
transactions to COMMIT.
The default of 20 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 ex‐
pected to only grow to a few MB in size.
The big advantage in increasing this parameter comes from cutting down on the number of transac‐
tion COMMITs; moving from 1 to 2 will provide considerable benefit, but the benefits will progres‐
sively fall off once the transactions being processed get to be reasonably large. There isn't
likely to be a material difference in performance between 80 and 90; at that point, whether ‘big‐
ger 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 dis‐
rupted 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 ‘deadlock.’
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 processes the troublesome SYNCs one by one, hopefully making operator 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 to‐
gether, 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 up‐
date, all as one transaction, that can ‘blow up’ the length of the resulting SYNC to be nearly ar‐
bitrarily 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_autovacu‐
um 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 fre‐
quently, notably pg_listener.
In Slony-I version 1.1, this changes a little; the cleanup thread tracks, from iteration to itera‐
tion, the earliest transaction ID still active in the system. If this doesn't change, from one it‐
eration 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 sin‐
gle host.
-f config file
File from which to read slon configuration.
This configuration is discussed further in Slon Run-time Configuration [“Run-time Configuration”
[not available as a man page]]. 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.
-a archive directory
archive_dir indicates a directory in which to place a sequence of SYNC archive files for use in
log shipping [“Log Shipping - Slony-I with Files” [not available as a man page]] mode.
-x command to run on log archive
command_on_logarchive indicates a command to be run each time a SYNC file is successfully generat‐
ed.
See more details on “slon_conf_command_on_log_archive” [not available as a man page].
-q quit based on SYNC provider
quit_sync_provider indicates which provider's worker thread should be watched in order to termi‐
nate 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 corresponding 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 lag‐
ging node.
That might not be ideal behaviour at failover time, or at the time when you want to run SLONIK EX‐
ECUTE SCRIPT(7).
EXIT STATUS
slon 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 19 September 2024 slon(1)