Slony-I is a “master to multiple slaves” replication system for PostgreSQL supporting cascading (e.g. – a node can feed another node which feeds another node…) and failover.
The big picture for the development of Slony-I is that it is a master-slave replication system that includes all features and capabilities needed to replicate large databases to a reasonably limited number of slave systems.
Slony-I is a system designed for use at data centers and backup sites, where the normal mode of operation is that all nodes are available.
PostgreSQL 9.0 includes streaming replication, which, for a number of use cases, is likely to be simpler and more convenient than Slony-I.
There are, however, three characteristic kinds of cases where you’ll need something like Slony-I, where the built-in WAL-based replication won’t work:
- You need to interact between PostgreSQL versions. Slony (and similar systems like Londiste and Bucardo) can cope with having nodes running different versions of PostgreSQL.WAL-based replication requires that all databases use identical versions of PostgreSQL, running on identical architectures.
- You only want to replicate parts of the changes that are going on.WAL-based replication duplicates absolutely everything.
- You need for there to be extra behaviours taking place on subscribers, for instance, populating cache management information.WAL-based replication duplicates absolutely everything, and nothing extra that changes data can run on a WAL-based replica.
Steve Singer also discusses the matter in 9.0 Streaming Replication vs Slony .
As observed up front, the streaming replication built into PostgreSQL, which has progressed since its beginnings in version 8.1, can satisfy some users’ replication requirements. For those with requirements that are not compatible with its strictures, replication systems like Slony-I will continue to be useful.