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


Part I: General PostgreSQL Use

Introduction to PostgreSQL and SQL

Working with Data in PostgreSQL

PostgreSQL SQL Syntax and Use

Performance

Part II: Programming with PostgreSQL

Introduction to PostgreSQL Programming

Extending PostgreSQL

PL/pgSQL

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

Security

Replicating PostgreSQL Data with Slony

Contributed Modules

Index



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
EAN: N/A
Year: 2004
Pages: 261

Flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net