Re: High Availability, Load Balancing, and Replication Feature Matrix - Mailing list pgsql-docs

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