Provided by: slony1-bin_1.2.22-1_i386 bug

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:

              o Fatal

              o Error

              o Warn

              o Config

              o Info

              o Debug1

              o Debug2

              o Debug3

              o 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 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 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
              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:

              o 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.

              o 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
              maximum 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
              cutting down on the number of transaction COMMITs; moving from 1
              to  2  will  provide considerable benefit, but the benefits will
              progressively 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 '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
              '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 together, targetting 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
              transaction  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 ["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 generated.

              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 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 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 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 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.