| Slony-I 2.1.4 Documentation | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Chapter 1. Preface | Fast Forward | Next |
1.2. System Requirements
To run Slony-I you will need
PostgreSQL 8.3 or above (this version of Slony-I is known to work with 8.3.x, 8.4.x , 9.0.x, 9.1.x and 9.2.x). Earlier versions of PostgreSQL require Slony-I 1.2.x
The Slony-I binary files either compiled from source or from a binary package
The following are recommended for running Slony-I
A method of keeping the clocks on your replicas reasonably in sync such as NTP
Also, it is preferable to use an consistent, stable time zone such as UTC or GMT.
Users have run into problems with slon functioning properly when their system uses a time zone that PostgreSQL was unable to recognize such as CUT0 or WST. It is necessary that you use a timezone that PostgreSQL can recognize correctly. It is furthermore preferable to use a time zone where times do not have discontinuities due to Daylight Savings Time.
Most of Slony-I does not directly reference or use times, but if clocks are out of sync between servers running Slony-I components, confusion may be expected in the following places:
The monitoring view sl_status uses timestamps sourced from multiple servers.
Monitoring table sl_components captures timestamps based on the clock time on the host running slon.
slon logs are likely to contain timestamps.
Figuring out what is going on is likely to be made rather confusing if the database servers and servers where slon instances run do not agree on what time it its.
A reliable network between nodes
slon processes should run in the same "network context" as the node that each is responsible for managing so that the connection to that node is a "local" one. Do not run such links across a WAN. Thus, if you have nodes in London and nodes in New York, the slons managing London nodes should run in London, and the slons managing New York nodes should run in New York.
A WAN outage (or flakiness of the WAN in general) can leave database connections "zombied", and typical TCP/IP behaviour will allow those connections to persist, preventing a slon restart for around two hours.
It is not difficult to remedy this; you need only kill SIGINT the offending backend connection. But by running the slon locally, you will generally not be vulnerable to this condition.
All of your databases should be using the same database encoding. (ie LATIN1 or UTF8). Replicating from a database in one encoding to a database with a different encoding might lead to replication errors.
1.2.1. Requirements for compiling Slony-I
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)
You need an ISO/ANSI C compiler. Recent versions of GCC work.
You also need a recent version of PostgreSQL including the server headers. You must have PostgreSQL version 8.3 or newer to be able to build and use Slony-I.
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.3 and above. In addition you will need to install pthreads-win32 2.x.