Starting the Replication Daemons

Now that you've created all of the replication nodes and defined the paths that connect them, you can start the replication daemons. Every node in the replication cluster must be serviced by a running copy of the slon program. You typically run slon as a background, or daemon, process. The slon program accepts a number of configuration options that you can specify on the command line or in a separate configuration file. I recommend the configuration file approach, since you have a complete record (hopefully, a well-commented record) of the options that you actually used the last time you started the daemon.

Listing 24.5 shows a configuration file that tells slon how to service the springfield node.

Listing 24.5. springfield.slon Configuration File

# File: springfield.slon
cluster_name = 'branches'
conn_info = 'service=springfield-replication'

At first glance, the syntax for a slon configuration file looks similar to the syntax you use to create slonik script, but there a few important differences that may trip you up. In a slonik script, every command ends with a semicolonthat's not the case for a slon configuration file. (If you accidentally terminate a slon configuration option with a semicolon, slon will taunt you with a rather unfriendly syntax error.) Second, the individual parts of a multi-word command name (such as cluster name) are separated by whitespace in a slonik script, but you must use an underscore in a slon configuration file (cluster_name).

You must specify, at least, the cluster_name and conn_info options to start slon. The cluster_name option tells slon how to find the cluster's schema within the target database. slon uses the conn_info option to connect to the target database. Once it's up and running, slon will use the path that you defined with a store path command when it needs to connect to another node.

Remember that you must start one slon daemon for each node in the replication cluster. That means that you'll need one configuration file for each node. Listing 24.6 shows the configuration files for all three nodes in the branches cluster.

Listing 24.6. slon Configuration Files

#File: springfield.slon
cluster_name = 'branches'
conn_info = 'service=springfield-replication'

#File: boomtown.slon
cluster_name = 'branches'
conn_info = 'service=boomtown-replication'

#File: snoozeville.slon
cluster_nam = 'brances'
conn_info = 'service=snoozeville-replication'

To start the three slon daemons, execute the following commands:

$ slon -f springfield.slon > springfield.log 2>&1 &
$ slon -f boomtown.slon > boomtown.log 2>&1 &
$ slon -f snoozeville.slon > snoozeville.log 2>&1 &

Looking at the first command, the -f flag tells slon to read configuration options from springfield.slon. The > springfield.log part redirects the standard output stream to springfied.log, and the 2>&1 redirects the standard error stream to the same file. (That way, all log information and error messages are recorded in the same file.) The & at the end of the command line tells the Linux/Unix shell to run the entire command in background.

In this example, you're running all three replication daemons on the same computer (even though the daemons are servicing three different nodes). That's a convenient arrangement while you are setting up the replication cluster, but you can also run each slon daemon on the system that hosts the node.

With the slon daemons up and running, you'll see quite a bit of periodic network traffic as the daemons exchange replication messages. You can adjust the frequency of the messages by tuning the sync_interval, sync_interval_timeout configuration options shown in Table 24.1. You can include any of options shown in Table 24.1 in a slon configuration script.

Table 24.1. slon Configuration Options



Default Value

Command-line Equivalent


Defines the name of the cluster that slon is servicing.

none (required)

first argument


Tells slon how to connect to the target database.

none (required)

second argument


Interval between checks for replication data. The slonprocess awakens every sync interval milliseconds and searches for new updates in the cluster.sl_log table. If it finds new replication data, it sends a SYNC event to all subscribers.(Each subscriber listens for a SYNCeventwhen it receives a SYNC event, it pulls the new replication data from the origin.) Valid values are in the range 1060000 (inclusive).

2000(2 seconds)

-s milliseconds


In some cases, a subscriber can pull data from the origin before the origin has completed its work. If that happens, the subscriber won't pull all of the replication data from the origin

10000(10 seconds)

-t milliseconds


until the next SYNC event is signaled. slon signals a SYNCevent every sync_interval timeout milliseconds even if the sync_interval check detects no new replication data. Valid values are in the range 01200000, inclusive.



If a subscriber falls behind, slongroups multiple SYNC events together into increasingly larger events until each event takes desired_sync_time milliseconds to complete. This reduces the number of messages, confirmations, and COMMITs required to "catch up." slon will not create a group that contains more than sync_group maxsize events (see next option). Value values are in the range 10000600000, inclusive.

60000(60 seconds)

-o milliseconds


Specifies the maximum number of SYNCevents to coalesce into a single, larger event when a subscriber has fallen behind. Valid values are in the range 0500, inclusive.




Determines how much information the slon process writes to the debug log (stdoutand/or syslog). Valid values range from 0 (minimal output) to 4 (detailed debugging information).



-d level


Determines whether slon writes log information to syslog(Linux/Unix hosts only), to the standard output stream (stdout), or both. Valid values are 0write to stdout only 1write to syslog and stdout 2write to syslog only




If slon writes information to yslog daemon (see the previous option), it designates each message as originating from syslog facility. Valid values are LOCAL0, LOCAL1, LOCAL7. See the syslogman page for more information.




If slon writes information to the syslog daemon, it identifies each message originating from the syslog_ident program.




If true, slon includes its process ID in every log message.




If true, slon includes a timestamp in every log message.




If log_timestamp is true, this option determines the format of the time stamp included in each log message. See the strftime man page for more details.

'%F %T %Z' (2005-02- 28 14:26: 30 GMT)



If present, slon writes its process ID to the named file.


-p file-name


Determines how frequently slon VACUUMs the Slony configuration and message tables. The slon daemon performs a general cleanup cycle once every 10 minutes.vac_frequency determines the number of cleanup cycles that run before slon VACUUMs its tables. If you are running pg_autovacuum, set vac frequency to 0 to disable the VACUUM feature offered by slon. Valid values range from 0 to 100.


-c cycle-count


If present slon writes replication data to a "shipping" log in the given directory. See the section titled "Log Shipping" for more information.


-a directory- name

Part I: General PostgreSQL Use

Introduction to PostgreSQL and SQL

Working with Data in PostgreSQL

PostgreSQL SQL Syntax and Use


Part II: Programming with PostgreSQL

Introduction to PostgreSQL Programming

Extending PostgreSQL


The PostgreSQL C APIlibpq

A Simpler C APIlibpgeasy

The New PostgreSQL C++ APIlibpqxx

Embedding SQL Commands in C Programsecpg

Using PostgreSQL from an ODBC Client Application

Using PostgreSQL from a Java Client Application

Using PostgreSQL with Perl

Using PostgreSQL with PHP

Using PostgreSQL with Tcl and Tcl/Tk

Using PostgreSQL with Python

Npgsql: The .NET Data Provider

Other Useful Programming Tools

Part III: PostgreSQL Administration

Introduction to PostgreSQL Administration

PostgreSQL Administration

Internationalization and Localization


Replicating PostgreSQL Data with Slony

Contributed Modules


PostgreSQL(c) The comprehensive guide to building, programming, and administering PostgreSQL databases
PostgreSQL(c) The comprehensive guide to building, programming, and administering PostgreSQL databases
ISBN: 735712573
Year: 2004
Pages: 261 © 2008-2020.
If you may any questions please contact us: