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

Option	Description	Default Value	Command-line Equivalent
cluster_name	Defines the name of the cluster that slon is servicing.	none (required)	first argument
conn_info	Tells slon how to connect to the target database.	none (required)	second argument
sync_interval	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
sync_interval_timeout	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
sync_interval_timeout	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.
desired_sync__time	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
sync_group_maxsize	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.	20	-gcount
log_level	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).	4 (verbose)	-d level
Syslog	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	0	none
syslog_facility	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.	LOCAL0	none
syslog_ident	If slon writes information to the syslog daemon, it identifies each message originating from the syslog_ident program.	slon	none
log_pid	If true, slon includes its process ID in every log message.	false	none
log_timestamp	If true, slon includes a timestamp in every log message.	true	none
log_timestamp_format	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)	none
pid_file	If present, slon writes its process ID to the named file.	none	-p file-name
vac_frequency	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.	3	-c cycle-count
archive_dir	If present slon writes replication data to a "shipping" log in the given directory. See the section titled "Log Shipping" for more information.	none	-a directory- name