Database Reference
In-Depth Information
These last abilities mean that we can have very complex cluster configurations if we need
them. Such clusters are well beyond the scope of this topic, regrettably.
Sounds very cool, and it definitely is. Please be very careful here: complexity is your enemy
when building robust and highly available solutions. If you definitely need some of the
preceding features, go with Slony. If you don't or you are unsure, use a simpler alternative:
streaming replication.
Next, consider which version of Slony to use. Version 1.2 is a very mature version of Slony with
many production installations. Many features have been enhanced in Version 2.0, and that
is now the recommended version for PostgreSQL 8.3 and above. Slony 2.0 offers somewhat
reduced locking and smoother, more efficient replication. Slony 2.0.5 has grown through many
of the teething problems in early releases, and is in use by many production systems.
How to do it...
As you might guess, Slony configuration is complex. There have been a few attempts to
simplify configuration, though there is no accepted standard there. Here, we choose to use a
project named Slony1-ctl available at the following URL:
http://pgfoundry.org/projects/slony1-ctl/
The benefits of using Slony1-ctl are that it allows:
F
Management of even complex replication with cascading, several sets of replication,
several Masters, and so on
F
Failover/switchover (even in cascading)
F
Add/drop objects (table, sequence) to replication in 1 script, very easily
F
Add/manage nodes and paths between nodes
F
Add replication sets
F
Upgrade Slony
Probably the key point is that all actions happen in two stages. Stage one is a create script,
stage two is an execution script. This gives the replication administrator the opportunity to edit
the scripts if necessary, or simply to stop and check things.
Scripts produced are autonomous: they don't need any Slony-ctl script or run-time component
to be executed. Some people just use these scripts to create the scripts and then deploy them
separately. The execution script also provides error handling as well.
Full replication process
This recipe will configure Slony replication from a single Master to a single Slave/Standby. Once
this process is mastered, you can think about further complexity. Carry out the following steps:
