From: Markus Schiltknecht <markus@bluegap.ch>
To: Bruce Momjian <bruce@momjian.us>
Cc: PostgreSQL-documentation <pgsql-docs@postgresql.org>
Subject: Re: High Availability, Load Balancing, and Replication Feature Matrix
Date: Fri, 16 Nov 2007 11:55:43 +0100
Message-ID: <473D772F.9030105@bluegap.ch> (raw)
In-Reply-To: <200711121756.lACHuuN08043@momjian.us>
References: <200711121756.lACHuuN08043@momjian.us>
Hello Bruce,
Bruce Momjian wrote:
> I think the point is that with middleware each server is as least
> working simultaneously while with multi-master they don't, at least in
> most current implementations, no?
Current implementations include PgCluster, which calls itself a
multi-master replication. I definitely also consider it that.
You are stating that PgCluster is a replication middleware and thus not
a multi-master replication suite. That's very confusing, IMO.
>> are single-master or no replication at all. When there's only one
>> master, it's pretty obvious that there can't be no inter-(master)-server
>> locking delay. (Well, it's also very obvious that a single master never
>> 'conflicts' with itself...)
>
> Totally agree. What I need is a negative for multi-master so it is
> clear why that option isn't used 100% of the time. The text above
> clearly describes the reason, but how to do that in a bullet?
Ah, I see where you are coming from. We certainly need a negative for
eager multi-master, even if it's my favorite discipline :-)
I'm fine with the current term ("no waiting for multiple servers"),
because it's a replication delay inherent to eager multi-master
replication - no matter if statement based or tuple based, or if it's
tightly woven into the database system or implemented in a middleware.
> I was thinking I could take "No master server overhead" and somehow make
> multi-master double-cost by using two bullets, but because it is a
> negative I can't. :-( We could just remove "No inter-server locking
> delay" and assume the "No master server overhead" represents the locking
> overhead but that kind of loses the distinction that the multi-master
> has much higher overhead. If you look at the chart it is kind of like
> we have two items "no overhead" and "no significant overhead". Would
> that be better?
I don't think that would be better, because it's even less clear.
"No master server overhead" and "No waiting for multiple servers" is
good enough, IMO.
> Agreed "statement-based replication" in a way offers multi-master
> capabilities, but as outlined above it has limitations as outlined in
> the doc details. What I have done is changed the text to "No waiting
> for multiple servers" and removed bullets from the appropriate
> solutions. Is this better?
Yup, that's fine with me.
> I had middleware in there because of the problem middleware has with
> sequences and current_timestamp, i.e. you need to adjust the application
> to deal with those sometimes.
..or let the middleware do some parsing and introducing logic into that.
AFAICT, that's what the Sequoia people are doing.
> My assumption is that the _shared_ disk is not part of the master
> itself. Of course if the shared disk fails you are out of luck, which
> is mentioned above.
Understood. However, please be aware that you are comparing parts of a
clustered database (in case of the NAS) to the full cluster (all other
cases).
>> A majority of servers rejecting or blocking the query? In case of a
>> minority, which blocks, the majority would win and apply the
>> transaction, while the minority would have to replay the transaction? I
>> don't know, probably most solutions do something simpler, like aborting
>> a transaction even if only one server fails. Much simpler, and
>> sufficient for most cases.
>
> Right, which I think we can call conflict resolution (abort on failure).
Yes.
Regards
Markus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-docs@postgresql.org
Cc: markus@bluegap.ch, bruce@momjian.us
Subject: Re: High Availability, Load Balancing, and Replication Feature Matrix
In-Reply-To: <473D772F.9030105@bluegap.ch>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox