Re: PostgreSQL in the press again

On 11/10/2004 12:02 AM, Christopher Browne wrote:

> Martha Stewart called it a Good Thing when peter_e(at)gmx(dot)net (Peter Eisentraut) wrote:
>> Thomas Hallgren wrote:
>>> Master + read-only slaves:
>>> - Slony-I when all sites are trusted
>>> - dbMirror for untrusted slaves and/or table based master slave
>>> assignment - Mammoth Replicator, proprietary ???
>>> - erServer ???
>>
>> That begs the question in turn why there are so many master/slave
>> replication solutions. I mean, I don't care, but this
>> categorization doesn't really answer the original question.
>
> I think there are multiple answers because of the combination of:
>
> a) Coding before thinking, where some of the systems have been
> "hacked together" without too much forethought;
>
> b) Greatly varying implementation strategies.
>
> For instance, one of the big problems we encountered with eRServer was
> in its use of memory. The "snapshot" notion it uses tends to lead to
> fairly spectacular RAM consumption. Had it gotten more design effort,
> earlier on, perhaps it could have been more modest in memory usage.
> That became one of the design requirements for Slony-I...

To be fair, that isn't really a fault of the initial design. The way it
was redone in JAVA moved the temporary files used by Vadim's Perl stuff
into the RAM. If the JAVA version would be able to spill to disk it
would be no issue at all.

>
> Part of the history has been that people in a rush to get some form of
> replication working looked at different "parts of the elephant," and,
> seeing different things, implemented different things.
>
> If a system can get a bit more "thoughtfulness" applied to it, it may
> well become forcibly preferable to the other options.
>
>>> Multi-master:
>>> - C-JDBC, Will be transaction safe once PostgreSQL has XA
>>> - pgPool, not transaction safe ???
>>
>> These are not multimaster solutions in the sense that you can write
>> to any one of multiple hosts. In a sense, they are really
>> master/slave solutions with the program components distributed
>> differently. To write, you always have to go through one host.
>
> The pgpool approach is somewhat ambiguous, but you're probably right.

Pgpool is no multimaster. It is an approach of query duplication done by
a connection proxy, which has next to no tolerance for a single server
aborting a transaction during commit. You would lose that node and have
to rebuild it from scratch during a downtime of the whole cluster.

The only "working" multimaster system I have seen so far is pgcluster. I
don't know if Mitani would be happy with us advertising it at this time
though.

>
> My expectation of a "multimaster" system is that I should be able to
> fire an update at any of the 'masters' and expect it to propagate to
> the rest of the databases more or less automatically. That's not what
> either XA or pgpool do.

... that among other things. I also expect that I can get a crashed or
otherwise lost node back into the group without interruption. And that I
can add new nodes from scratch without that as well. And, and, and.

The reason why we have so many replication solutions is that most of
them look like they have been developed like "let's not worry about all
the problems now ... get some data replicating first". And that is
almost a guarantee never to get all those "other features" implemented
at all, since the choices made early on don't inherit the capabilities
if you haven't considered them.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #