Re: PostgreSQL in the press again
От | Andrew Sullivan |
---|---|
Тема | Re: PostgreSQL in the press again |
Дата | |
Msg-id | 20041109192448.GE17541@phlogiston.dyndns.org обсуждение исходный текст |
Ответ на | Re: PostgreSQL in the press again (Thomas Hallgren <thhal@mailblocks.com>) |
Ответы |
Re: PostgreSQL in the press again
|
Список | pgsql-advocacy |
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@crankycanuck.ca The plural of anecdote is not data. --Roger Brinner
В списке pgsql-advocacy по дате отправления: