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