3. System Requirements

3.1. Slony-I Software Dependancies

At present, Slony-I as well as PostgreSQL need to be able to be compiled from source at your site.

In order to compile Slony-I, you need to have the following tools:

• GNU make. Other make programs will not work. GNU make is often installed under the name gmake; this document will therefore always refer to it by that name. (On Linux-based systems GNU make is typically the default make, and is called make) To test to see if your make is GNU make enter make version. Version 3.76 or later will suffice; previous versions may not.

• You need an ISO/ANSI C compiler. Recent versions of GCC work.

• You also need a recent version of PostgreSQL source. Slony-I depends on namespace support so you must have PostgreSQL version 7.3.3 or newer to be able to build and use Slony-I.

  Earlier versions of PostgreSQL are not supported, but note that one user has "hacked" Slony-I to do a 7.2-to-7.4 upgrade; see PostgreSQL 7.2 notes .

  Versions of PostgreSQL prior to 7.4.8 may run into a longstanding race condition that leads to problems of "duplicate keys", so you may want to consider upgrades if you are running earlier versions.

  If you are running a version of PostgreSQL earlier than 8.0, you need to make sure that server header files were installed. If installing from sources, this is done via the command make install-all-headers. Otherwise, you will encounter the missing headers for libpqserver problem described in the FAQ.

  If you are running versions 8.1.0 thru 8.1.3, there is a bug (addressed in 8.1.4) which prevents SLONIK UPDATE FUNCTIONS from running properly. For more details see the "", on PostgreSQL 8.1.[0-3] .

  There is variation between what versions of PostgreSQL& are compatible with what versions of Slony-I. See Section 4 for more details.

• GNU packages may be included in the standard packaging for your operating system, or you may need to look for source code at your local GNU mirror (see http://www.gnu.org/order/ftp.html for a list) or at ftp://ftp.gnu.org/gnu .)

• If you need to obtain PostgreSQL source, you can download it from your favorite PostgreSQL mirror. See http://www.postgresql.org/mirrors-www.html for a list.

• This documentation is written in SGML using DocBook , and may be processed into numerous formats including HTML, RTF, and PDF using tools in the DocBook Open Repository along with OpenJade.

• On Windows™ you will also need the same MinGW/Msys Toolset used to build PostgreSQL 8.0 and above. In addition you will need to install pthreads-win32 2.x.

Also check to make sure you have sufficient disk space. You will need approximately 5MB for the source tree during build and installation.

3.2. Getting Slony-I Source

You can get the Slony-I source from http://main.slony.info/downloads/

3.3. Database Encoding

PostgreSQL databases may be created in a number of language encodings, set up via the createdb --encoding=$ENCODING databasename option. Slony-I assumes that they use identical encodings.

If the encodings are "closely equivalent", you may be able to get away with them not being absolutely identical. For instance, if the origin system used LATIN1 and a subscriber used SQL_ASCII and another subscriber used UNICODE, and your application never challenges the boundary conditions between these variant encodings, you may never experience any problems.

In PostgreSQL 8.1, changes were made to the UNICODE encoding because earlier versions accepted some invalid encodings. This can lead to replication problems.

Note also that if the client encoding (configured assortedly in postgresql.conf, parameter client_encoding, or via the psql \encoding command, or the psql internal variable ENCODING) varies from the server encoding, this mismatch may lead to Slony-I being unable to replicate those characters supported by the client encoding but not by the server encoding.

3.4. Time Synchronization

All the servers used within the replication cluster need to have their Real Time Clocks in sync. This is to ensure that slon doesn't generate errors with messages indicating that a subscriber is already ahead of its provider during replication. Interpreting logs when servers have a different idea of what time it is leads to confusion and frustration. It is recommended that you have ntpd running on all nodes, where subscriber nodes using the "master" provider host as their time server.

It is possible for Slony-I itself to function even in the face of there being some time discrepancies, but having systems "in sync" is usually pretty important for distributed applications.

See www.ntp.org for more details about NTP (Network Time Protocol).

Some users have reported problems that have been traced to their locales indicating the use of some time zone that PostgreSQL did not recognize.

• On AIX, TZ=CUT0 was unrecognized, leading to timestamps pulled from system calls causing it to break.

  CUT0 is a variant way of describing UTC

• Some countries' timezones are not yet included in PostgreSQL.

In any case, what commonly seems to be the "best practice" with Slony-I (and, for that matter, PostgreSQL) is for the postmaster user and/or the user under which slon runs to use TZ=UTC or TZ=GMT. Those timezones are sure to be supported on any platform, and have the merit over "local" timezones that times never wind up leaping around due to Daylight Savings Time.

3.5. Network Connectivity

It is necessary that the hosts that are to replicate between one another have bidirectional network communications between the PostgreSQL instances. That is, if node B is replicating data from node A, it is necessary that there be a path from A to B and from B to A. It is recommended that, as much as possible, all nodes in a Slony-I cluster allow this sort of bidirection communications from any node in the cluster to any other node in the cluster.

For ease of configuration, network addresses should ideally be consistent across all of the nodes. SLONIK STORE PATH does allow them to vary, but down this road lies madness as you try to manage the multiplicity of paths pointing to the same server.

A possible workaround for this, in environments where firewall rules are particularly difficult to implement, may be to establish SSH Tunnels that are created on each host that allow remote access through a local IP address such as 127.0.0.1, using a different port for each destination.

Note that slonik and the slon instances need no special connections or protocols to communicate with one another; they merely need access to the PostgreSQL databases, connecting as a "superuser" that has the ability to update system tables.

An implication of this communications model is that the entire extended network in which a Slony-I cluster operates must be able to be treated as being secure. If there is a remote location where you cannot trust one of the databases that is a Slony-I node to be considered "secure," this represents a vulnerability that can adversely affect the security of the entire cluster. As a "peer-to-peer" system, any of the hosts is able to introduce replication events that will affect the entire cluster. Therefore, the security policies throughout the cluster can only be considered as stringent as those applied at the weakest link. Running a Slony-I node at a branch location that can't be kept secure compromises security for the cluster as a whole.

New in Slony-I version 1.1 is a feature whereby updates for a particular replication set may be serialized via a scheme called log shipping. The data stored in sl_log_1 and sl_log_2 is also written out to log files on disk. These files may then be transmitted in any manner desired, whether via scp, FTP, burning them onto DVD-ROMs and mailing them, or, at the frivolous end of the spectrum, by recording them on a USB "flash device" and attaching them to birds, allowing some equivalent to transmission of IP datagrams on avian carriers - RFC 1149. But whatever the transmission mechanism, this allows one way communications such that subscribers that use log shipping have no need of access to other Slony-I nodes.