Slony-I 2.2.10 Documentation
Prev | Fast Backward |  | Fast Forward | Next

# 4. Event Tuning

`sync_interval` (`integer`)

  Check for updates at least this often in milliseconds. Range: [10-60000], default 2000

  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 despite absence of changes to replicate.

`sync_interval_timeout` (`integer`)

  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 10000

  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.

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

  The two values function together in varying ways:

  On an origin node, `sync_interval` is the minimum 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 `sync_interval` milliseconds.

  On that same origin node, there may be quiet intervals, when no replicatable changes are being submitted. A SYNC will be induced, anyways, every `sync_interval_timeout` milliseconds.

  On a subscriber node that does not originate any sets, only the "timeout-induced" SYNCs will occur.

`sync_group_maxsize` (`integer`)

  Maximum number of `SYNC` events that a subscriber node will group together when/if a subscriber falls behind. `SYNC`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 `SYNC` available, even though you used `-g600`, the slon will apply just the one that is available. As soon as a subscriber catches up, it will tend to apply each `SYNC` by itself, as a singleton, unless processing should fall behind for some reason. Range: [0,10000], default: 20

`vac_frequency` (`integer`)

  Sets how many cleanup cycles to run before a vacuum is done. 0 disables the builtin vacuum, intended to be used with the pg_autovacuum daemon. Range: [0,100], default: 3

`cleanup_interval` (`interval`)

  Controls how quickly old events are trimmed out. That subsequently controls when the data in the log tables, `sl_log_1` and `sl_log_2`, get trimmed out. Default: '10 minutes'.

`cleanup_deletelogs` (`boolean`)

  Controls whether or not we use DELETE to trim old data from the log tables, `sl_log_1` and `sl_log_2`. Default: false

`desired_sync_time` (`integer`)

  Maximum time planned for grouped `SYNC`s. If replication is behind, slon will try to increase numbers of syncs done targeting that they should take this quantity of time to process. This is in Range [10000,600000] ms, default 60000.

  If the value is set to 0, this logic will be ignored.

`quit_sync_provider` (`integer`)

  This must be used in conjunction with quit_sync_finalsync, and indicates which provider node's worker thread should be watched to see if the slon should terminate due to reaching some desired "final" event number.

  If the value is set to 0, this logic will be ignored.

`quit_sync_finalsync` (`integer`)

  Final event number to process. This must be used in conjunction with quit_sync_finalsync, and allows the slon to terminate itself once it reaches a certain event for the specified provider.

  If the value is set to 0, this logic will be ignored.

`lag_interval` (`string/interval`)

  Indicates an interval by which this node should lag its providers. If set, this is used in the event processing loop to modify what events are to be considered for queueing; those events newer than `now() - lag_interval::interval` are left out, to be processed later.

  If the value is left empty, this logic will be ignored.

`sync_max_rowsize` (`integer`)

  Size above which an sl_log_? row's `log_cmddata` is considered large. Up to 500 rows of this size are allowed in memory at once. Rows larger than that count into the `sync_max_largemem` space allocated and `free()`'ed on demand.

  The default value is 8192, meaning that your expected memory consumption (for the LOG cursor) should not exceed 8MB.

`sync_max_largemem` (`integer`)

  Maximum memory allocated for large rows, where `log_cmddata` are larger than `sync_max_rowsize`.

  Note that the algorithm reads rows until after this value is exceeded. Otherwise, a tuple larger than this value would stall replication. As a result, don't assume that memory consumption will remain smaller than this value.

  The default value is 5242880.

`remote_listen_timeout` (`integer`)

  How long, in milliseconds, should the remote listener wait before treating the event selection criteria as having timed out? Range: [30-30000], default 300ms

Prev | Home | Next
Archive Logging Options | Up | slonik