Re: PostgreSQL in the press again

On Tue, Nov 09, 2004 at 07:54:14PM +0100, Thomas Hallgren wrote:

> I've seen this argument several times and it always prevents Slony and
> other replication solutions from being mentioned. My suggestion is that
> the scenarios are outlined (there can't be that many, 2-4 perhaps?)
> together with the corresponding preferred solution.

Well, see Josh's excellent response in this thread, also. I can
think of at least three scenarios:

1. Only one read-write database (or, more precisely, one per
table) with (possibly multiple) read-only copy(ies). Most of the
systems meet this need. Mammoth's Replicator, erserver, Slony-I,
dbmirror will all do this. Some of them do it with greater
flexibility than others: the BSD version of erserver is a fair pain
in the neck to administer, for instance. Each has some features
which may work for particular installations. Slony-I, for intstance,
currently requires superuser access on all nodes, and that all nodes
talk to one another. For connections to untrusted sites, then,
Slony-I would be an exceptionally bad choice. It also has pretty
awkward support for DDL, on the grounds that your code shouldn't add
and remove tables as a matter of course (because, as Jan argues,
that's akin to self-modifying code). If you have an application
which depends on the adding and removing of tables as part of regular
operation, some other approach will be better for you.

2. One read-write database (per table) with untrusted target
replicas. This is a nifty extension of dbmirror that came from the
bright folks at MusicBrainz.

3. Multi-master, with possible loss of transactions in one node
or another. Some applications can tolerate the odd lost transaction,
as long as there is _some_ system that has the data. Current
offerings of C-JDBC and pg_pool can provide this.

4. True multi-master, with transactional semantics across all
nodes. This one is currently planned, but not available anywhere.
Jan is working on an implementation; the Postgres-R project has a
proof of concept which currently doesn't offer all the features.

Does that help?

A

--
Andrew Sullivan | ajs(at)crankycanuck(dot)ca
The plural of anecdote is not data.
--Roger Brinner