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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
