Markus Schiltknecht wrote:
> 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.
Uh, I think of PgCluster as multi-master, but in a way it is a hybrid
because there is a central server that gets all the queries.
> >> 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.
Good.
> > 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.
Good.
> > 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).
Yes, and the section above outlines those issues, I think.
> >> 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.
Good. Let me know if you think of other ideas.
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---------------------------(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
